[Enhancement] Soft-DFU upload protocol tested to work on STM32F072B-DISCO

[ekawahyu]

The current built-in STM32 DFU upload requires user to pull BOOT0 pin to 3.3V and perform system reset. With this enhancement, users do not require to press reset button nor pulling BOOT0 pin to 3.3V to upload new binary. The protocol is based on reading magic number over USBCDC (same magic number as Maple board '1EAF') and then it jumps to built-in DFU mode and ready to accept binary from there.

This enhancement has been tested to work on STM32F072B Discovery board with softdfu_upload from here:

https://github.com/SnapBloks/Arduino_Tools/tree/feature/softdfu_upload

Uploading with Soft-DFU on STM32F072B-DISCO requires dependency of upload tool from here:

https://github.com/stm32duino/Arduino_Tools/pull/69

Please review and comment. Thank you.

[ekawahyu]

@fpistm I think we can keep the variant.cpp as it were by moving all of those changes out as a new file, somewhere not in each variant folders. And then all 3 macro definitions are defined as compiler flags in boards.txt

The second option, we may be able to merge the code, like with bootloader.c maybe? SInce it uses the same magic word 1EAF

The last thing about the startup code, it is basically the exact same copy from CMSIS, but I added one liner in there: bl __initialize_hardware_early(). I don't know what would be the best thing to do to make it generic, maybe a simple patch will do? I need to dig deep about how I got this one liner added in the past. I thought it was the STM32CubeMX that generated this one liner.

[fpistm]

Honestly, modifying only one variant for this stuff is not the proper way. From my point of view your change is more a user customization and should be used like this: https://github.com/stm32duino/wiki/wiki/Custom-board-based-on-a-core

I will soon works on this PR: #710 which I guess is more generic to achieve the same goal.

[fpistm]

Just a quick though, as it seems __initialize_hardware_early doesn't exists anymore (as I can see it was available on old SPL drivers) maybe it can simply check at the beginning of SystemInit?

[ekawahyu]

Just a quick though, as it seems __initialize_hardware_early doesn't exists anymore (as I can see it was available on old SPL drivers) maybe it can simply check at the beginning of SystemInit?

It is not gonna work, because dfu_reset_to_bootloader_magic variable will get initialized when we do it in SystemInit (or maybe not? I have to try this)

EDIT: confirmed that it does not work when I put it at the beginning of SystemInit()

[ekawahyu]

Honestly, modifying only one variant for this stuff is not the proper way. From my point of view your change is more a user customization and should be used like this: https://github.com/stm32duino/wiki/wiki/Custom-board-based-on-a-core

I will soon works on this PR: #710 which I guess is more generic to achieve the same goal.

I have SnapBloks specific variants that use F072C8T6, and those will reside in Arduino/hardware as customized boards. This pull request, however, is an enhancement on STM32F072B-DISCOVERY. If you guys can implement this somehow and become mainline, then the rest of Discovery kits may get the same benefit of Soft-DFU upload protocol. I can help to work on the rest of Discovery kits out there. But you are right, it needs to be generic. First thing we need to figure out, is how we can replace __initialize_hardware_early in there. Because this has dependency on older SPL.

The startup codes do not change at all, and look the same from when I compared it to my old work with HALMX. In the old HALMX startups, there are additional two liners that allows user to insert C code very early and right before SystemInit():

• __initialize_hardware_early()
• __initialize_hardware()

Not sure if it is a good idea to bring it back. There must be a good reason of removing these in the past. But in order to jump into any built-in bootloader, bl __initialize_hardware_early is required in there.