Как стать автором
Обновить

Комментарии 29

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

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

Области памяти, доступные для чтения/записи/удаления, определяются в файле 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 не видит совместимых устройств.
НЛО прилетело и опубликовало эту надпись здесь
Как USB устройство плата определяется. С подтяжками все в порядке. На форумах я читал, что STM-вский DFU какой-то нестандартный. Поэтому в DeFuse его видит, а dfu-util нет.
НЛО прилетело и опубликовало эту надпись здесь
О, тогда я знаю, в чем ваша боль. Значит по шагам:

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

Публикации

Истории