Миландр

При включенном checker для CPU_CLK при возникновении события флаги загораются, но переключения на HSI не происходит (фраза "Для FCLK аварийное переключение не предусмотрено" означает, что для CPU_CLK аварийное переключение не предусмотрено).
Если подобную проверку производить для непосредственно источника частоты, например HSE, то помимо зажигания флагов, происходит переключение на HSI (поэтому фраза про аварийное переключение отсутствует).
Таблица 23 не верная (k может принимать значения от 0 до 15), тикет на исправление зарегистрирован. Спасибо!

_________________
Отдел технической поддержки support@milandr.ru

Снимаю свое замечание относительно переключения на HSI для FCLK. При имитации пропадания FCLK (выключение внешнего генератора) происходит плавное снижение частоты при котором успевает произойти обработка прерывания FT_IF2 с формированием программного сброса и соответственно переход на HSI.

Регистры PER0_CLK, PER1_CLK отвечают за тактирование блоков, расположенных в пространстве периферии, находящейся за AHB-APB мостом (0x4008_0000 -0x400F_FFFF). Остальные блоки (EBC, OTP, RAM, ...) тактируются всегда.

_________________
Отдел технической поддержки support@milandr.ru

Это прерывание от CLOCK_CNTR, по событиям ошибок в регистрах. Маскируется на уровне NVIC.
Для 1923ВК014 аналогично. Будет добавлено в следующие ревизии спецификаций.

_________________
Отдел технической поддержки support@milandr.ru

страница 470 таблица 115 - регистр IMSC

бит RXIM - маска прерывания по заполнению на 50% и менее буфера FIFO приемника. Наверное должно быть более ?

по факту прерывание срабатывает когда в буфере 4 байта данных и более.

Да, спасибо за замечание, в описании бита RXIM должно быть указано "маска прерывания по заполнению на 50% и более буфера FIFO приемника", как это указано в пункте 7.19.4 Прерывания, 7.19.4.1 SSPRXINTR, стр. 463. В bugzilla заведён тикет на исправление спецификации.

_________________
Отдел технической поддержки support@milandr.ru

Добрый день ! Ответ не понятен.
Непонятно, почему нужно переходить в режим EXTBUS8_ECC, если людям нужен режим EXTBUS_CFG+JA(JB) например без ECC (а он действительно чаще не нужен).
1. При установке CFG1 в "1" в ячейках CFG2-CFG9 может размещаться все что угодно ?
2. Почему шина адреса в момент проведения конфигурирования начинается с PD:1, а не с начального, нулевого, адреса. Но если это действительно так, то каким образом тогда производится запуск программы из внешней памяти, которая представляет собой одну и ту же микросхему на тех же самых выводах микроконтроллера. Можно здесь подробнее и, по возможности, со схемой включения и алгоритмом работы, т.к. спецификация не раскрывает деталей реализации этого режима.
3. Как осуществляется запуск после конфигурирования, нужно делать внешний сброс?
Спасибо.

По поиску в интернете есть интересная ссылка по использованию отладочной платы в разных режимах:

https://ic.milandr.ru/upload/iblock/9bb ... a176da.pdf

но она, почему-то не работает... Можно обновить документ, чтобы его можно было почитать ?

Да. CFG1 = "1" - режим без ЕСС.



Начальный загрузчик, обнаружив на выводах MODE режим запуска ПО с внешней памяти с конфигурированием, сначала настраивает внешнюю шину для считывания конфигурационных настроек - CFG0-CFG9. Регистры CFG располагаются по адресам CFG0[0x10000400], CFG1[0x10000408], CFG2[0x10000410] и т.д., поэтому для адресации младшие 3 бита адреса не используются. После чтения с внешней памяти регистров CFG1-CFG9 происходит перенастройка шины в соответствии с этими регистрами. ... см ниже п 3.


После перестройки шины исполнение переходит на ResetHandle[0x10000004] программы во внешней памяти с предварительной подготовкой. Сброс не нужен. В спецификации описано подробнее - стр 39.


Во вложении, если речь об этом.

_________________
Отдел технической поддержки support@milandr.ru

По режимам загрузки лучше разбираться по коду

_________________
Отдел технической поддержки support@milandr.ru

Большое спасибо за расширенный ответ !

Добрый день, коллеги, вопрос по ExtBus. В спецификации версии 2.10 на стр. 209 описан регистр SPORT_PDn , настраивающий подтяжки линий ExtBus.
Активирую подтяжки на линиях DATA[15..0], провожу попеременную тестовую запись значений 1 и 0 в регион 0, и наблюдаю осциллограмму - см. вложение.
Зеленый график - это DATA[0]. Как видим, он в моменты записи становится то 1, то 0 - как и должно быть, но в промежутках между операциями записи линия сохраняет свое последнее состояние.
Вопрос - кто держит линию? Явно это не остаточный заряд на паразитных емкостях, иначе через подтяжку 50 кОм он быстро стекал бы на землю.
Если на линиях данных удерживается какой-то определенный уровень, зачем тогда вообще нужна подтяжка?

ВЕ9х тоже удерживает линии шин в последнем состоянии - надо понимать так устроен контроллер ExtBus.
А подтяжки, очевидно, рассчитаны для работы в режиме входа или в режиме открытых стоков/истоков.
Видимо, Вам бы хотелось третье состояние на шинах в паузах? Так это другая философия шины должна быть, МК такую не поддерживает. Хотя, может обратить внимание на 1923ВК014?

_________________
сочувствующий…

Спасибо, это много объясняет.


Не могу сказать, что нам мешает текущая логика работы ExtBus, просто исследуем спонтанные сбросы процессора при чтении по шине.
Ну а процессор в целом устраивает.

По вопросу зависаний, думаю, надо открыть новую тему.