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

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

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

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

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

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

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

Странно, всегда думал, что в блоке 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 это все делает прошитая изготовителем в системную память функция.
Сочувствую

Насчёт своего уровня как программиста и разработчика я особых иллюзий не питаю ))). Ну тут уж как в мультике : когда закончились даже худшие из лучших, в дело идут лучшие из худших ))
Что касается конкретного прибора, то в реальных условиях доступ к нему будет только по CAN, и отлаживать прибор приходится только включая его в условиях, близких к реальным рабочим.
Если кто умеет проводить отладку, используя эмулятор на компе, и при этом находить косяки, которые возникают в реальной работе, то , честно говоря, я ему завидую.
Так что ... В пианиста просьба не стрелять

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

Всё так и есть, ничего не изменилось. И галочка есть и разницы особой нет (по времени). Только с галочкой можно ещё и просто стереть контроллер.

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


Это пока вы не столкнулись с чем-нибудь "интереcным". Хотелось бы посмотреть как вы по SPI или I2C флэшку без флэшлоадера будете писать.


Не берите в голову. Не ошибается тот кто ничего не делает. В реальной жизни подвохи случаются там где их совсем не ждешь...

Напугали (; ежа... (ну дальше, надеюсь, понятно)
Тема про микроконтроллеры, но уверяю вас, JTAG стараюсь применять по назначению (;

Запишите в STM32/MSP430/AT91 (на выбор) страницу одним махом. Мужики-то не знают...

Так и я про них. Поделитесь, как будете через J-TAG шить программу в микроконтроллер с SPI-флэшкой.

Не сталкивался с чем? С прошивкой МК? Да уж, сколько уже лет (или десятилетий?) "не сталкиваюсь"... почти каждый день "не сталкиваюсь"
Насчёт STM8: наличие собственного работающего проекта с хранением данных во внутренней EEPROM - это уже нельзя считать "веским основанием"?
Так что насчёт "категоричным не имея для того веских оснований" - это Вы думаю о себе говорите


Точно так же, как это делал бы флешь-лоадер - обращаясь к регистрам IO этих самых SPI и I2C.
А в чём сложность-то?


Про эти МК я не говорил. Но тем не менее всё равно - длительность стирания любого МК будет гораздо больше его записи через JTAG. Так что на фоне стирания каких-то незначительных замедлений не будет заметно.

Пробовали или опять чисто теоретически?

Нет, не пробовал. Но не вижу причин "против". А вы пробовали или опять чисто теоретически?

Пробовал и опять чисто практически. Так что, рекомендую не подставляться снова.

Незначительных заметно не будет. Будут очень заметны значительные. По той простой причине, что между JTAG и скриптом еще некая коробочка, которая втыкается почти всегда в USB, а там "записать байт-прочитать байт-записать байт-прочитать байт" происходит значитально медленее, чем "записать много-много байтов". Если у вас это не так - расскажите мужикам. А то у нас стирание 64К секунд 5 занимает, а запись без загрузчика почти минуту.

И...?


"У нас" это где?
Вот у меня IAR, прошиваю МК, без галки использовать лоадер(!), только "verify download". Весь процесс длится время примерно равное времени стирания - т.е. секунд 5.
Вот другой МК (STM32F4). Опять IAR. Опять нет галки. Время - примерно пара секунд.
ЧЯДНТ??
Как вам удалось добиться такого медленного программирования? Расскажите мужикам!

Вот вы вы что подразумевали... а то SPI, I2C... т.е. у контроллера на борту энергонезависимой памяти программ нет (это уже медиапроцессор - чуть более другая область). Тут да: или по JTAGу flashloader (только правильнее назвать его будет SerialWriter)в наботрное ОЗУ заливать и там исполнять, или уже в ROM он (loader) есть (к примеру 'C6747 DSPшник, но это опять пример не контроллера).
Более того, раздел про ARM.

Ещё когда Земля была чуть тёплая, ARM грузились с внешних флэшек параллельных или последовательных. А сейчас и подавно. Почему вы решили, что все ARM должны иметь набортную флэш? Избаловала вас STM

Да-да, не уж-то мне надо вспоминать, как они были 26-разрядными процессорами общего назначения?
Идея микроконтроллера всё же: программная и оперативная память на кристалле с ядром и периферией. Вспомните, как только 7TDMI стали с флэшом, тут то "всё и заверте..."
1830ве31 - это от отсталости, в '96 - атмел выкатил mcs51 с флэшом и мир заиграл другими красками (;

А расширительное толкование слов собеседника (тем более письменных), ну согласитесь, не достойно благородного дона (;

Не знаю что у вас там завертелось, но ARM без набортной флэш сейчас обычное явление.

Тут Вы зря.... Если какой-то МК Cortex-M (к примеру) не имеет встроенной флешь, он что после этого - перестаёт быть Cortex-M?
Я вообще считаю, что производители зря делают CM-ы с частотами от ~144 МГц и выше со встроенной флешь. Одни только проблемы: шины выборки широкие надо делать, wait-state-ы, кеши и т.п.
Лучше-бы взамен встроенной флешь ставили аналогичный объём ОЗУ и возможность загрузки (и исполнения) по quad-SPI извне.

Ядро - это ядро (впишите любое на свой выбор), тут разговоров нет.
Или не помните (в профиля смотреть не пойду) или прикидываетесь, что не знаете, как выглядело типичное управляющее устройство, пока не интегрировали оба вида памяти и периферию с ядром на кристалле и как и что это изменило.

По топику: что решили? "В чём особенность программирования МК по JTAG?" (;


Что зря? Разве после пояснения, про каким боком SPI, I2C, не сказал, что либо свой загрузчик в ОЗУ, либо наличествующий штатный в ПЗУ.

Надо полагать, что если адаптер JTAG "родной" для данного вида МК (что означает, что прошивка адаптера знает систему команд Boundary Scan для данного вида МК), то прошивка флэшки будет происходить быстро, как и предусмотрено производителем МК и адаптера JTAG. Если адаптер "левый", то прошивкой флэшки уже будет заниматься среда программирования, если у неё есть соответствующие скрипты - а это и будет в духе "запиши в регистр байт, почитай регистр статуса", что по USB и вправду довольно медленно. Неким "консенсусом" выглядит в этом ракурсе идея закинуть в SRAM кусок кода, который примет сразу блок прошивки и сам на борту запишет его во флэшь.

"Зря" - не о том. А о том, что отсутствие встроенной энергонезависимой памяти программ, не делает микроконтроллер не микроконтроллером.

В Cortex на архитектуре ARM®v7-M есть такая вещь как CoreSight™ DAP, там прямой доступ на шину и шаманства с Boundary Scan уже не нужны.