Unfortunately for me I was trying to understand how the bootloader worked and really struggled.
So I thought I would write up what I have discovered.
There are a few issue threads on GitHub which discuss this:
https://github.com/Serasidis/STM32_HID_ ... /issues/29
https://github.com/Serasidis/STM32_HID_ ... /issues/13
Reading through the Reset_Handler() function we find the following commment:
Code: Select all
/* If: * - PB2 (BOOT 1 pin) is HIGH or * - no User Code is uploaded to the MCU or * - a magic word was stored in the battery-backed RAM * registers from the Arduino IDE * then enter HID bootloader... */
1) If the user application space is blank (e.g. Check if the stack pointer in the vector table points somewhere in SRAM : true/false)
2) If Boot0 is low (e.g. Boot Main Flash Memory) the state of BOOT1 is checked by the bootloader, if it is high the bootloader will start and wait for commands, if it is low it will jump to the main application address. (FLASH_BASE + 2KB for F1xx or +4KB for F4xx)
3) If the register RTC_BKP_DR4 is written with the value 0x424C by the user application (and the user has a battery attached to the RTC or is a "soft reset") and the device restarts the bootloader will enter and wait.
3a) Arduino Mode?? I am new to the STM32duino space, but there appears to be a built in mode which is included by the STM32Core on all user compiled applications (in the USB serial driver), this will transparently (to the user) write the RTC_BKP_DR4 with the magic word (0x424C) when given some command over the USB Serial interface. Additionally there is some code which will force a chip reset on a DTR toggle on USBSerial. There are some comments regarding this implementation in github but its not super clear to me yet (it appears to be legacy from maplecore?)
Either way, this is how the Arduino IDE utilises entry mode three to put the chip into bootloader mode.
NB: if you have the USB port disabled (or in HID mode??) - 3a) wont work and the IDE will spit an error when trying to enter the bootloader.
In each of these situations there is no timeout for the bootloader, it will wait for a user upload before jumping to the user application space.
To return back to the application in each of these relative cases:
Generic: upload an application via the bootloader. The bootloader will then automatically jump to the user application.
2) remove the BOOT1 high condition (e.g. set the jumper of BOOT1 to low) and reset the chip.
3) RTC_BKP_DR4 is reset to 0x0000 as soon as it it read by the bootloader, so simply resetting the chip once will jump back into the user application (assuming no other conditions exist).
The LED1 variable is hard coded and the pin number is appended to filenames of the precompiled binaries available from github.
e.g. hid_generic_pc13.bin selects PC13 and the LED1 pin
When the bootloader has entered and is waiting for an upload the led will rapidly flash
When code is being uploaded, the led will flash at a slightly lower rate.
At exit the bootloader will turn off this LED and the user application can take control of the port registers. (NB: the user application will likely have to reset the port configuration as the bootloader does not do this).
I hope someone finds this information useful.