STM32 bootloader DFU mode с использованием CubeMX. Инструкция пошаговая, step by step

[Ryppka]

А такое число звездочек и приведений типа типично для embedded? И еще вопрос: выравнивание там чем-то гарантируется или это счастливое совпадение звезд?

[rstepanov]

Для HAL это «нормально», там вообще код в стиле Java EE, если выкинуть лишнее — внезапно становится в три-четыре раза компактнее. Cortex M3 выравнивание не критично.

[sami777]

Прикрепить исходники религия не позволяет?

[roma_turkin]

А основной программе осталось 64-48 = 16 кб

Это если не знать фокуса этой серии. А фокус в том, что флешка там, где она должна закончиться, не заканчивается. Контроллеры серии F103C8 точно имеют (по крайней мере все те, с которыми я работал) 128 кБ флеша (хотя по спеке — всего 64). Такой же фокус у меня прошел на L152C8, по крайней мере приложение из региона ~70-80k вполне себе успешно работает.
Внешний пруфлинк вот тут.

[sami777]

В кейле этот камень определяется, как 128кб флэша.

[Ksiw]

128кб это камень СВ. С8 имеет 64кб. Те страницы, что за 64кб, их работа не гарантируется, ST их не тестит.

[im_stD]

del

[Ksiw]

Чет не понял, зачем все это нужно. В чем профит, использования dfu?

[Sergey78]

Я честно говоря тоже не понял, но предположу, что профит в том, что для прошивки st-link или uart не нужен. Если в устройстве есть usb, можно через него прошивать. Но 48кб это перебор. И необходимость специальной программы, тоже как-то не серьезно. Можно же эмулировать usb флэшку и прошивку на нее просто копировать. St-link v2.1 по-моему так умеет.

[vasimv]

Делаете девайс с USB, но без UART-а (выводы нужны подо что-то другое, например, или просто неудобно их выводить), прошиваете через него. Сейчас это многие используют, например в некоторых контроллерах для коптеров — USB является основным портом, для прошивки и настройки, нет необходимости тыкаться по разъемам UART-ов, которые могут еще и на других GPIO оказаться (не на тех, где ждет загрузчик).

[sami777]

Более мощные, например 4хх серия по дефолту имеют встроенный dfu загрузчик, как по типу уартовского.

[rstepanov]

s/мощные/новые/, например в f042 dfu есть в системном загрузчике.

[VioletGiraffe]

полным отсутствием пошаговой инструкции

4 слова, полностью описывающие всю линейку STM32.

[r1000ru]

Области памяти, доступные для чтения/записи/удаления, определяются в файле USB_Device/App/usbd_dfu_if.c — описании дескриптора интерфейса. Пример строки описания:

#define FLASH_DESC_STR      "@Internal Flash   /0x08000000/03*016Ka,01*016Kg,01*064Kg,07*128Kg,04*016Kg,01*064Kg,07*128Kg"

Подробнее о формировании строки дескриптора можно прочесть в разделе DFU mode interface descriptor документа UM0424.

В целом следует понимать, что протокол USB-DFU следует — это именно USB протокол. Он имеет несколько функций (записать блок, считать блок, уничтожить блок, считать состояние, считать статус, очистить статус, отключиться). При взаимодействии по DFU, контроллер должен выполнить какие-то действия, в простейшем случае — это записать данные во флэш или считать их. Но валидация адресов — лежит на плечах разработчика в коде микроконтроллера. ПО с компьютера ничто не мешает сгенерировать запись в область RO (где обычно располагается бутлоадер), и контроллер должен это проверить и вернуть ошибку. Для того чтобы демо-утилита от STM знала, куда она может писать, и что может читать — и передается эта строка.

[Tsvetik]

У меня данный standalone-dfu не определяется с помощью известной dfu-util.
Кто-то сталкивался с этой проблемой?

[yeswolf]

Что значит «не определяется»? Если сразу после заливки бута не видно USB-устройства, то это так обычно происходит. Надо переткнуть.

[Tsvetik]

Dfu-util не видит совместимых устройств.

[Tsvetik]

Как USB устройство плата определяется. С подтяжками все в порядке. На форумах я читал, что STM-вский DFU какой-то нестандартный. Поэтому в DeFuse его видит, а dfu-util нет.

[yeswolf]

О, тогда я знаю, в чем ваша боль. Значит по шагам:

1. Если у вас DFU определяется через DFuse utility, значит у вас стоит STMовский драйвер, который не будет работать с dfu-util. И наоборот — если вы поставите драйвер, который будет работать с dfu-util, у вас DFuse не будет видеть устройства. В обоих случаях девайс будет в Device Manager на Windows.
2. Если надо использовать DFuse, то без шансов — dfu-util при этом работать не будет.
3. Если надо использовать dfu-util, то надо удалить и устройство, и его драйвер из Device Manager, а потом сделать так, как говорят вот тут, то есть накатить драйвер через Zadig. После этого dfu-util начнет видеть устройство и работать, проверено.

[yeswolf]

Обычно нет. Такое обычно только на перешитых в ST-LINK v2-1. И вообще, конечно, если кто-то увидит это комментарий — не мучайтесь вы с этим ST-LINK, перешивайтесь вот прямо сразу в J-LINK. Настолько, блин, проще. Дрова под любой системой — просто работают, GDB Server — тоже просто работает, не косячит, USART для отладки не нужен, потому что RTT. До кучи еще и пачка утилит полезных, которые тоже — внезапно, просто работают. Я уже не говорю о скорости заливки прошивки — то, что st-link лил секунд 30, j-link вливает тупо за пару-тройку секунд.

[yeswolf]

Можно. Там надо закинуть бут от 2.0, обновиться через Update Utility строго до варианта STM32, после этого Reflash от J-LINK должен увидеть и перешить. Если не видит — попробовать бут от 2.0, только разлоченный. Либо один, либо другой сработает. Я так два свистка перешил. ST-LINK 2.1 Reflash не увидит, к слову.

[IgorPie]

Спасибо большое, отличная методичка получилась