Document how the bootloader is started

[matthijskooijman]

I just tried this bootloader and found it a bit unclear how it is started exactly. I think I've managed to puzzle it together from various sources, but I might be missing pieces. Here's what I found:

• The bootloader lives at 0x0, so it always starts first. Normally, it starts by enumerating as a DFU device and waits 6 seconds loops which is roughly 1 second it seems (or 30 if the button is disabled) for an upload to start. If no upload starts, it starts the main application.
• For the "fastboot" variants, it skips this wait and starts the main application right away (though it does seem to enable USB as a DFU device, but maybe this happens to quickly to actually enumerate in practice).
• If the RTC register RTC_BKP_DR10 contains the magic value 0x424C, the bootloader waits for an upload indefinitely (even for fastboot). This can be used to start the bootloader from within the main application.
• 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.
• In normal operation (at least that's how Arduino_Core_STM32 now implements it, but the sequence will probably change), the bootloader is started by a magic sequence on the serial port, that main the application must be programmed to understand (e.g. the STM32 Arduino core used must understand it). This sequence is opening the serial port, setting RTS off, toggling DTR (on-off-on-off), sending a magic string 1EAF and closing the port. The device should then write the appropriate magic value to the RTC backup register and reset, so the bootloader starts.
• When RTC_BKP_DR10 contains the magic value 0x424D, the wait at startup is also skipped and the main application is started right away. This is used by the bootloader itself to be able to reset after a succesful upload and jump straight to the main application, but could also be used by the main application to do a fast reset, I guess.

I think it would be valuable to document this somehow. Maybe a little less detailed version for users might be also useful, but these details help Arduino core devs to better understand how this all fits together.

[matthijskooijman]

From writing this, I wonder if it might be a bug that currently all the USB (and other subsystem) initialization happens early in main. Even with fastboot, or the 0x424D magic value, now all kinds of stuff is initialized before jumping to the main application, while it would be cleaner if the main application was started in an as-clean-as-possible scenario (at least when nowait is set, so in fastboot mode or with the 424D value)?

[iddq]

Why is this bootloader needed to program STM32 far as I know STM32 has an internal DFU bootloader?

[matthijskooijman]

You can use the internal bootloader, but not all chips have it (at least not with DFU support, I think), it might not do exactly what you need (maybe it's too slow, or initalizes pins like SPI, UART or I²C in a way that conflicts with other hardware), it does not allow reconfiguring the USB vidpid, to name a few reasons you might want to use a different bootloader.

[iddq]

Thank you. It is interesting this doc says all these chips below have DFU:

STM32F0 Series STM32F1 Series STM32F2 Series STM32F3 Series STM32F4 Series STM32F7 Series STM32G0 Series STM32G4 Series STM32H7 Series STM32L0 Series STM32L1 Series STM32L4 Series STM32L5 Series STM32WB Series

https://www.st.com/resource/en/application_note/cd00264379-usb-dfu-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

https://www.st.com/resource/en/programming_manual/cd00283419-stm32f10xxx-flash-memory-microcontrollers-stmicroelectronics.pdf

[rogerclarkmelbourne]

@iddq

STM32F103 only has Serial UART DFU not USB DFU

I think he others including STM32F0 may all have USB DFU, but unfortunatly the F1 doesn't have USB DFU, hence the need for USB bootloaders for this series of MCU's

This is not the only open source USB DFU for the F1. There are many others, including USB HID, USB Mass storage etc.