[NikP 0]

Отлаживаю однотипные модули на базе 1986ВЕ1Т (Миландр). В устройстве имеется FLASH 1636РР2АУ (тоже Миландр).

Модуль должен перепрограммироваться по шине CAN. Процесс идёт так: новая прошивка записывается в 1636РР2АУ,

проверяется контрольная сумма, после чего контроллер копирует её из 1636РР2АУ во внутреннюю FLASH, перезагружается

командой NVIC_SystemReset() и далее работает.

Проблемы возникли с одним из 5 модулей: после перепрошивки по CAN он намертво зависает, хотя если прошивать его через программатор

по JTAG, то работает нормально.

Пробовал проводить перепрошивку под отладчиком: новая программа записывается во FLASH контроллера без дефектов, происходит перезагрузка,

программа запускается, но после выполнения нескольких операций уходит в HardFault.

Вопрос: в чём особенность программирования по JTAG по сравнению с перепрошивкой контроллером?

В чём может быть причина такого сбоя ?

Изменено 6 декабря, 2017 пользователем NikP

[x893 35]

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

Почему нельзя посмотреть информацию по HardFault ?

[Obam 30]

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

[jcxz 184]

В чём может быть причина такого сбоя ?

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

[gerber 7]

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

[HardEgor 63]

Вопрос: в чём особенность программирования по JTAG по сравнению с перепрошивкой контроллером?

В чём может быть причина такого сбоя ?

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

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

[GenaSPB 11]

по JTAG вы напрямую, минуя контроллер, заливаете прошивку во флэш

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

Изменено 7 декабря, 2017 пользователем Genadi Zawidowski

[mantech 34]

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

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

[VladislavS 29]

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

[NikP 0]

Всем спасибо за обсуждение.

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

 

 

[jcxz 184]

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

Да уж.... "разработчик".... :smile3009:

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

 

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

А зачем? Если JTAG имеет доступ ко всему адресному пространству МК, значит он имеет доступ и к регистрам отвечающим за интерфейс программирования FLASH.

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

 

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

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

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

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

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

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

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

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

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

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

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

[VladislavS 29]

"Лучше день потерять, потом долететь за пять минут!".

 

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

[jcxz 184]

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

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

Неужто длительность этих записей такая большая, что занимает хотя-бы миллисекунды??

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

 

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

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

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

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

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

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

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

Сочувствую :)