2020-10-30 09:07 PM
I have been experimenting with adding the USB DFU to firmware using the Stm32CubeMX. On both a "black pill" STM32F411 and a home made STM32F405 board, pulling boot0 high during reset, the device will show up as DFU and I can flash new firmware using something like:
dfu-util -a 0 -s 0x8000000 -D c13blink.bin
(from Linux. IF I include the DFU in the firmware, the USB device enumerate correctly and show up as:
Bus 001 Device 106: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
dfu-util -l reports:
Found DFU: [0483:df11] ver=0200, devnum=106, cfg=1, intf=0, path="1-14.5.3", alt
=0, name="@Internal Flash /0x08000000/03*016Ka,01*016Kg,01*064Kg,07*128Kg,04*0
16Kg,01*064Kg,07*128Kg", serial="387D326E3439"
But if I try to flash - the same which worked with the internal bootloader - the result is:
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08000000, size = 29432
dfu-util: Last page at 0x080072f7 is not writeable
What am I missing?
2020-10-31 12:36 AM
I mean idea DFU in app isnt good. You cant overwrite memory with runned code.
When you need DFU place it to custom bootloader on 0X8000000 and app place on other addr.0X8004000 ...
Or before DFU move code to RAM , but this is more complicated.
For this situation exist system bootloader.
2020-10-31 03:08 AM
Ok that does make sense - but I am somewhat baffled why the option is available in stm32cubemx.