Pull to refresh

Comments 29

А такое число звездочек и приведений типа типично для embedded? И еще вопрос: выравнивание там чем-то гарантируется или это счастливое совпадение звезд?
Для HAL это «нормально», там вообще код в стиле Java EE, если выкинуть лишнее — внезапно становится в три-четыре раза компактнее. Cortex M3 выравнивание не критично.
Прикрепить исходники религия не позволяет?
UFO just landed and posted this here
А основной программе осталось 64-48 = 16 кб

Это если не знать фокуса этой серии. А фокус в том, что флешка там, где она должна закончиться, не заканчивается. Контроллеры серии F103C8 точно имеют (по крайней мере все те, с которыми я работал) 128 кБ флеша (хотя по спеке — всего 64). Такой же фокус у меня прошел на L152C8, по крайней мере приложение из региона ~70-80k вполне себе успешно работает.
Внешний пруфлинк вот тут.
UFO just landed and posted this here
В кейле этот камень определяется, как 128кб флэша.
128кб это камень СВ. С8 имеет 64кб. Те страницы, что за 64кб, их работа не гарантируется, ST их не тестит.
Чет не понял, зачем все это нужно. В чем профит, использования dfu?

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

Делаете девайс с USB, но без UART-а (выводы нужны подо что-то другое, например, или просто неудобно их выводить), прошиваете через него. Сейчас это многие используют, например в некоторых контроллерах для коптеров — USB является основным портом, для прошивки и настройки, нет необходимости тыкаться по разъемам UART-ов, которые могут еще и на других GPIO оказаться (не на тех, где ждет загрузчик).
Более мощные, например 4хх серия по дефолту имеют встроенный dfu загрузчик, как по типу уартовского.
s/мощные/новые/, например в f042 dfu есть в системном загрузчике.
UFO just landed and posted this here

Области памяти, доступные для чтения/записи/удаления, определяются в файле 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 знала, куда она может писать, и что может читать — и передается эта строка.

У меня данный standalone-dfu не определяется с помощью известной dfu-util.
Кто-то сталкивался с этой проблемой?
Что значит «не определяется»? Если сразу после заливки бута не видно USB-устройства, то это так обычно происходит. Надо переткнуть.
Dfu-util не видит совместимых устройств.
UFO just landed and posted this here
Как USB устройство плата определяется. С подтяжками все в порядке. На форумах я читал, что STM-вский DFU какой-то нестандартный. Поэтому в DeFuse его видит, а dfu-util нет.
UFO just landed and posted this here
О, тогда я знаю, в чем ваша боль. Значит по шагам:

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 начнет видеть устройство и работать, проверено.
UFO just landed and posted this here
Обычно нет. Такое обычно только на перешитых в ST-LINK v2-1. И вообще, конечно, если кто-то увидит это комментарий — не мучайтесь вы с этим ST-LINK, перешивайтесь вот прямо сразу в J-LINK. Настолько, блин, проще. Дрова под любой системой — просто работают, GDB Server — тоже просто работает, не косячит, USART для отладки не нужен, потому что RTT. До кучи еще и пачка утилит полезных, которые тоже — внезапно, просто работают. Я уже не говорю о скорости заливки прошивки — то, что st-link лил секунд 30, j-link вливает тупо за пару-тройку секунд.
UFO just landed and posted this here
Можно. Там надо закинуть бут от 2.0, обновиться через Update Utility строго до варианта STM32, после этого Reflash от J-LINK должен увидеть и перешить. Если не видит — попробовать бут от 2.0, только разлоченный. Либо один, либо другой сработает. Я так два свистка перешил. ST-LINK 2.1 Reflash не увидит, к слову.
Спасибо большое, отличная методичка получилась
Sign up to leave a comment.

Articles