Отлаживаю однотипные модули на базе 1986ВЕ1Т (Миландр). В устройстве имеется FLASH 1636РР2АУ (тоже Миландр).
Модуль должен перепрограммироваться по шине CAN. Процесс идёт так: новая прошивка записывается в 1636РР2АУ,
проверяется контрольная сумма, после чего контроллер копирует её из 1636РР2АУ во внутреннюю FLASH, перезагружается
командой NVIC_SystemReset() и далее работает.
Проблемы возникли с одним из 5 модулей: после перепрошивки по CAN он намертво зависает, хотя если прошивать его через программатор
по JTAG, то работает нормально.
Пробовал проводить перепрошивку под отладчиком: новая программа записывается во FLASH контроллера без дефектов, происходит перезагрузка,
программа запускается, но после выполнения нескольких операций уходит в HardFault.
Вопрос: в чём особенность программирования по JTAG по сравнению с перепрошивкой контроллером?
В чём может быть причина такого сбоя ?

Сообщение отредактировал NikP - Dec 6 2017, 07:36

Почему нельзя посмотреть по шагам после перепрошивки и System Reset?
Почему нельзя посмотреть информацию по HardFault ?

Если один блок из пяти "дурИт", мож там косяк монтажа? А вы "system reset", "особенность по JTAG"… (;

Например: в ошибке в новой прошивке. Или в куче других причин.

Копайте в сторону flash wait states.

Особенность в том, что по JTAG вы напрямую, минуя контроллер, заливаете прошивку во флэш.
А при прошивке по любому интерфейсу у вас на контроллере выполняется программа, которая принимает байты от компьютера и заливает во флэш.

не-а... Для ускорения процесса все-таки обычно работой с FLASH занимается flash loader, который да, напрямую, помещается в память программируемого девайса. Хотя это не SEGGER...

Сообщение отредактировал Genadi Zawidowski - Dec 7 2017, 11:21

Странно, всегда думал, что в блоке JTAG используется свой, аппаратный блок программирования. Что там ускорять - непонятно...

Не ускорять, а унифицировать. Флэшек и способов их подключения в природе несметное количество, а протокол с флэшлоадером строго определён.

Всем спасибо за обсуждение.
С проблемой разобрался. Когда стал проходить прошивку после перезагрузки по шагам, то выяснилось, что затык происходит при обращении к флэш при старте программы. Сделал пару задержек в этом куске программы, и всё заработало. Вероятно, после перезагрузки перепрошитой программы эта часть отрабатывается быстрее, чем при записи программы в МК по JTAG.

Да уж.... "разработчик"....
Вставил пару костылей и "решил проблему". До следующего костыля.


А зачем? Если JTAG имеет доступ ко всему адресному пространству МК, значит он имеет доступ и к регистрам отвечающим за интерфейс программирования FLASH.
А значит он (имея доступ к ОЗУ) может загрузить туда содержимое очередного прошиваемого блока и (имея доступ к регистрам управления прошивкой) - стартовать через эти регистры операцию записи во флешь.


Унифицировать можно написав скрипт для каждого МК, выполняющийся на компе и знающий адреса и номера битов в регистрах программирования флешь, находящихся в области периферийных регистров МК. А доступ ко всему ОЗУ и всем регистрам отлаживаемого МК эмулятор имеет.
В составе IAR видел директорию с кучей *.ddf-файлов для каждого семейства поддерживаемых МК - возможно это оно и есть.
И написать такой скрипт будет проще, чем писать загрузчик, выполняющийся на самом МК.

Это будет очень медленно и печально. Поэтому в ОЗУ грузится некиая подпрограмма копирования блоков из ОЗУ во флешь, отладчик кладет в ОЗУ содержимое сразу большого блока (страницы) флешь, ставит точку останова на конец этой подпрограммы и запускает ее.
Нет, это device description file - файлы описания периферийных регистров и их битов. То, что я описал, у IAR называется (раньше называлось, сейчас - не знаю) flash loader и была отдельная галочка "use flash loader".
В openocd реализованы оба варианта. Разность в скорости записи на порядки. "Лучше день потерять, потом долететь за пять минут!".

Самое прикольное, что даже этот принцип тут не работает. Чуть нестандартный случай и скрипт написать/отладить занимает на порядок больше времени чем флэшлоадер. Год назад поимел много секаса вычитавая данные по SPI через скрипт. Уж очень тормозно всё работает и времянку выдерживать тот ещё геморрой. К тому же, попадаются чипы у которых функции работы с флэш есть во внутреннем ПЗУ, тогда флэшлоадер совсем простой получается по сравнению со скриптом.

Программирование блока (страницы) флешь по времени - это несколько мсек. Чтобы стартовать запись такого блока в любом МК нужно выполнить считанное кол-во записей в регистры IO.
Неужто длительность этих записей такая большая, что занимает хотя-бы миллисекунды??
Очевидно что нет: в одном из моих текущих проектов я отлаживаю ПО в SDRAM (подключенной к МК). Перед загрузкой программирую регистры контроллера внешней шины для чего написал соответствующий .mac-файл и подсунул IAR. В этом файле написан срипт настройки контроллера внешней шины МК в несколько десятков записей в регистры IO. И времени его выполнения я на глаз не замечаю - грузится примерно как во внутреннюю ОЗУ.


У меня нигде эта галка не установлена. Скорость записи какая? Она в первую очередь определяется временем стирания блоков флешь. Типичное время стирания одного блока в текущем МК == 5 секунд! На фоне этого даже миллисекунды незаметны, не говоря уже о микросекундах, которые очевидно занимают операции записи регистров через JTAG.

Кроме NXP бывают и другие процессоры. и там надо почитать регистр в ожидании готовности, потом записать другой для запуска процесса записи, после этого положить собственно записываемый байт/слово и дождаться окончания записи (почитывая регистр). Каждое это действие через отладочный интерфейс достаточно медленно. В NXP это все делает прошитая изготовителем в системную память функция.
Сочувствую