Не могу разобраться с DFU-загрузчиком в STM32. Плата видна на USB-шине, но dfu-util ее не видит.

На stm c полноценным usb надо какой-то пин зажать при втыкании, чтобы загрузчик активировался. Иначе грузится как обычное устройство.

Как 103 с софтовым костылем - не знаю.

Как 103 с софтовым костылем - не знаю.

Всё так же.

На BluePill же перемычки есть - Boot0 и Boot1. Boot0 = 1, Boot1 = 0 и получаешь DFU. Ну если загрузчик типовой, а не что-то самописное.

Осталось выяснить, какой пин имеется в виду.

При перемычках boot0=1 boot1=0 загрузка идет из системного загрузчика, расположенного в ROM. Его никак изменить невозможно.

DFU грузится просто как обычная программа при пинах 00 из FLASH. И это видно из dmesg: устройство определяется как USB-устройство. А это значит что DFU-загрузчик работает.

Если же прошить устройство каким-нибудь Led Blink, то как USB-устройство плата не определяется. Это говорит о том, что DFU-прошивка действительно превращает плату в софтварное USB-устройство.

Осталось ответить на вопрос, заданный в топике: почему dfu-util не видит плату с DFU-загрузчиком.

Ты же ссылку на репозиторий со своим бутлоадером дал. Создай там issue!

Там issue открыты в 19-м и 20-м году и никто на них не отвечает.

Но я написал, мало ли.

При перемычках boot0=1 boot1=0 загрузка идет из системного загрузчика, расположенного в ROM. Его никак изменить невозможно.

Да, точно, это SystemROM с UART. Значит наоборот, boot0=0, boot1=1. boot1 это какой-то GPIO (PB? вроде). Твой DFU загрузчик должен его проверять при загрузке.

А вообще - посмотри в сырцах бутлоадера, там всё очевидно должно быть.

Значит наоборот, boot0=0, boot1=1. boot1 это какой-то GPIO (PB? вроде). Твой DFU загрузчик должен его проверять при загрузке.

По ссылке в изысканиях написано, что значит каждая комбинация boot0/boot1. Нет там никакой активации DFU-загрузчика

При boot0=0 и любом состоянии boot1 грузится из флеша. В флеше DFU-бутлоадер с 0x00000000. Он проверяет boot1 который какой-то PB2 что-ли. Если он 0 - то перекидывает на залитый код, который после загрузчика, если 1 - то запускает DFU. Ну я бы так сделал. Как конкретно в этом бутлоадере сделано - я фиг знаю, надо сырцы смотреть. Кстати, чтобы бутлоадер не затирался при прошивке возможно при сборке заливаемой софтины надо указать другой начальный адрес и другой адрес векторов прерывания. Чтобы софтина заливалась после бутлоадера. Конкретнее - надо сырцы бутлоадера смотреть. Я особо не разбирался c DFU для STM32F103, просто китайский ST-Link v2 тыкал в BluePill и не парился.

В RISC-V GD32VF103 как-то проще - там в DFU в System ROM искаропки, кнопку boot держишь при включении да и всё.

Да, логика в твоих словах есть, похоже стало получаться.

В закрытом issue один товарищ написал почти то же самое и просил добавить в документацию:

https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues/90

If a button pin is high (e.g. button pressed) at startup, the bootloader also waits for an upload indefinitely (even for fastboot). This can be used to force bootloader mode, even when the main application is broken and fastboot is enabled. The «button» pin varies per config (see config.h), but the led-on-PC13 variant that is typically used for the Blue Pill boards ahs the «button» pin configured to PB2, aka BOOT1, which is available on a pin header. The BOOT1 pin is normally used by the hardware to decide between system flash and RAM, but only when BOOT0 is 1. When BOOT0 is 0, it always boots from main flash, ignoring the value of BOOT1, so it can be used by the bootloader.

Но документации в проекте так и не появилось, а задачу закрыли немного потрындев.

Значит, ситуация следующая. Если пины выставлены «по нулям» (boot0=0 boot1=0), то устройство представляется как некое USB-устройство, причем оно совсем не DFU:

[25760.232130] usb 2-2: new full-speed USB device number 7 using xhci_hcd
[25760.385437] usb 2-2: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[25760.385444] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[25760.385447] usb 2-2: Product: Maple
[25760.385449] usb 2-2: Manufacturer: LeafLabs
[25760.424009] cdc_acm 2-2:1.0: ttyACM0: USB ACM device
[25760.424307] usbcore: registered new interface driver cdc_acm
[25760.424310] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

[ 4304.984940] usb 2-2: new full-speed USB device number 35 using xhci_hcd
[ 4305.133726] usb 2-2: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[ 4305.133733] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4305.133735] usb 2-2: Product: Maple 003
[ 4305.133738] usb 2-2: Manufacturer: LeafLabs
[ 4305.133739] usb 2-2: SerialNumber: LLM 003

> dfu-util --list
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path="2-2", alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path="2-2", alt=1, name="UNKNOWN", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path="2-2", alt=0, name="STM32duino bootloader v1.0  ERROR. Upload to RAM not supported.", serial="LLM 003"

Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path="2-2", alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path="2-2", alt=1, name="STM32duino bootloader v1.0  Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path="2-2", alt=0, name="UNKNOWN", serial="UNKNOWN"

В флеше DFU-бутлоадер с 0x00000000.

И не могу тебя не поправить. В STM32F103C8T6 память FLASH начинается с адреса 0x08000000. И DFU-бутлоадер прошивается начиная с адреса 0x08000000.

DFU заработало.

Однако далее возникает проблема. Длина DFU-загрузчика 0x56fc, значит, если он прописывается во FLASH с адреса 0x8000000, то он будет занимать область вплоть до 0x80056fc.

И при этом сам DFU-загрузчик предоставляет возможность прошивать, начиная с адреса 0x8005000. Вот это как понимать? Получается, что сам себе затрет хвост. Или я чего-то не догоняю?