В чём особенность программирования MK по JTAG? Опции

[NikP]

Отлаживаю однотипные модули на базе 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

[NikP]

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

[jcxz]

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

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

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

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

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

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

[Сергей Борщ]

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

Это будет очень медленно и печально. Поэтому в ОЗУ грузится некиая подпрограмма копирования блоков из ОЗУ во флешь, отладчик кладет в ОЗУ содержимое сразу большого блока (страницы) флешь, ставит точку останова на конец этой подпрограммы и запускает ее.

В составе IAR видел директорию с кучей *.ddf-файлов для каждого семейства поддерживаемых МК - возможно это оно и есть.

Нет, это device description file - файлы описания периферийных регистров и их битов. То, что я описал, у IAR называется (раньше называлось, сейчас - не знаю) flash loader и была отдельная галочка "use flash loader".

И написать такой скрипт будет проще, чем писать загрузчик, выполняющийся на самом МК.

В openocd реализованы оба варианта. Разность в скорости записи на порядки. "Лучше день потерять, потом долететь за пять минут!".

[jcxz]

Это будет очень медленно и печально. Поэтому в ОЗУ грузится некиая подпрограмма копирования блоков из ОЗУ во флешь, отладчик кладет в ОЗУ содержимое сразу большого блока (страницы) флешь, ставит точку останова на конец этой подпрограммы и запускает ее.

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

То, что я описал, у IAR называется (раньше называлось, сейчас - не знаю) flash loader и была отдельная галочка "use flash loader".
В openocd реализованы оба варианта. Разность в скорости записи на порядки. "Лучше день потерять, потом долететь за пять минут!".

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

[Сергей Борщ]

Программирование блока (страницы) флешь по времени - это несколько мсек. Чтобы стартовать запись такого блока в любом МК нужно выполнить считанное кол-во записей в регистры IO.

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

У меня нигде эта галка не установлена.

Сочувствую

[jcxz]

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

А зачем флешь писать побайтно??
В Infineon например сразу страница грузится и потом даётся команда на её запись.
Вобщем думаю: никакой заметной разницы по времени между записью напрямую через JTAG и через флешь-лоадер - нет. Тем более основное время занимает стирание, а не запись.