[jcxz 216]

Нужно описание протокола DFU (Device Firmware Upgrade) для LPC43xx по USB. Хочется встроить возможность обновления прошивки в своё ПО на PC.

Нашёл только какие-то обрывки в реф.мануале и общую схему в AN4370.

Интересует алгоритм загрузки образа прошивки и алгоритм парсинга загруженного образа. И формат его.

Если у кого есть инфа - напишите пожалуйста.

Спасибо заранее!

Изменено 26 декабря, 2022 пользователем haker_fox
Уточнил название темы, добавил теги, переместил в нужный раздел.

[Kabdim 0]

Протокол DFU общий - http://www.usb.org/developers/docs/devclass_docs/DFU_1.1.pdf , алгоритмы там. Парсинга нет, файл состоит из прошивки в чистом виде, а затем суффикс с crc, vid, pid, etc. - довольно бесполезно как на мой взгляд. Реализация в исходниках от NXP на диске есть, откуда брал уже не вспомню, кстати довольна кривая. В lpcopen_2_12_lpcxpresso_nxp_lpclink2_4370 есть пример с использование USBROM.

Имхо овчинка не стоит выделки. Для того что бы стандартными средствами загонять в режим DFU придется городить композитное устройство, а потом объяснять "блондинкам" почему оно композитное. Драйвер для DFU придется всё равно ставить. Причем NXPшная реалзация DFU и опен-сорсные прошивальщики не очень-то дружат. Если вдруг понадобится двухсторонний обмен (запрос-ответ), то придется его делать немного через 1 место.

Если бы выбор протокола обновления делался бы сейчас я бы выбрал что-то другое.

[jcxz 216]

Протокол DFU общий - http://www.usb.org/developers/docs/devclass_docs/DFU_1.1.pdf , алгоритмы там. Парсинга нет, файл состоит из прошивки в чистом виде, а затем суффикс с crc, vid, pid, etc. - довольно бесполезно как на мой взгляд.

Спасибо! Буду изучать.

Если верить Application Note AN4370 из раздела документации LPC4370, то (как я понимаю из приведённой там диаграммы "USB DFU bootloader sequence") после загрузки образа прошивки там указана фаза "Parse buffer", после которой следующая фаза - запись во флешь. Возможно они под этим понимали просто проверку CRC или формата прошивки.

Загруженный образ прошивки как я понимаю - один-в-один пишется во флешь?

 

Реализация в исходниках от NXP на диске есть, откуда брал уже не вспомню, кстати довольна кривая. В lpcopen_2_12_lpcxpresso_nxp_lpclink2_4370 есть пример с использование USBROM.

У меня в устройстве я использую свой стек, а не из USBROM. Описание этих вызовов USBROM для DFU я видел.

 

Имхо овчинка не стоит выделки. Для того что бы стандартными средствами загонять в режим DFU придется городить композитное устройство, а потом объяснять "блондинкам" почему оно композитное. Драйвер для DFU придется всё равно ставить. Причем NXPшная реалзация DFU и опен-сорсные прошивальщики не очень-то дружат.

Мне не обязательно поднимать DFU на своём стеке в своём встроенном ПО.

Я весь процесс вижу так:

1. Если устройство только изготовлено (FLASH чистая) или прошивка во FLASH неработоспособна, то BOOT-джампером переключаем его в режим DFU. Моё ПО на PC через драйвер CyUSB видит его и работает с ним (прошивает, проверяет прошивку и т.п.) посредством протокола DFU.

2. Если устройство уже имеет исправную прошивку, то BOOT-джампером (дефолтное положение) переводим его в режим исполнения кода из FLASH. Запускается мой стек в устройстве. Моё ПО на PC видит его через CyUSB и работает с устройством по моему протоколу. В своём протоколе я реализую подкласс API для обновления прошивки. Хотя была мысль: сэмулировать DFU в своём протоколе. Но раз там так сложно, то наверное не надо.

 

Просто сейчас, для заливки прошивки в чистое устройство, приходится пользоваться сторонним ПО, которое неудобное и малофункциональное (или JTAG-ом). Если протокол DFU несложный, то лучше реализовать его в своём ПО, тем более что оно всё равно есть.

[Kabdim 0]

Гугление Application Note AN4370 выдает пдфки для экс-фрискейлов...

Образ может прошиваться напрямую во флеш. С точки зрения протокола это просто набор блоков с индексами. С 43хх не работал, но судя по ЮМ образ шифруется АЕСом.

Протокол сам по себе простой. Сложности возникают если попытаться навесить на него чуть больше чем задумано. Удобства использования не хватает. Если бы в винде были встроены драйверы которые подхватывались бы по классу - было бы больше смысла использовать именно DFU. А сейчас что в инструкции писать "установите драйвер DFU" что "драйвер Х" - одинаково неудобно для обновления у конечных пользователей.

[jcxz 216]

А сейчас что в инструкции писать "установите драйвер DFU" что "драйвер Х" - одинаково неудобно для обновления у конечных пользователей.

Я просто в свой общий inf-файл описателя драйвера добавлю запись про VID/PID для DFU. Чтобы он видел и DFU и уже прошитое устройство с моими VID/PID.

Но конечным пользователям может понадобиться только обновление прошивки, а не начальная заливка ПО. Так что им DFU не нужен - будут обновлять через мой протокол. А для него так и так драйвер ставить нужно.

 

То что образ должен прошиваться напрямую во флешь - вполне резонно, хоть ОЗУ и много, но мало-ли - может понадобиться прошивка больше ОЗУ.

Как-то я писал USB-загрузчик для встроенного BOOT-ROM для OMAP L-137. Там тоже что-то вроде DFU было. Только заливаемый образ там сложный: он не просто единым массивом шьётся во FLASH, а состоит из отдельных секций, которые могут лежать в несмежных областях памяти. Такой парсинг на регионы вполне логичен.