The STM32 system memory bootloader, a ROM bootloader programmed to STM32 devices, is an essential tool—it can easily update devices in the field and “unbrick” boards in some situations. However, there are a few things to consider about the STM32 system memory bootloader before deciding to incorporate this feature into your design. Here are some of the most important considerations I’ve found.
Interfaces
There are a couple of interfaces you must be aware of when using the system memory bootloader. First, most microcontrollers (MCU) will have a BOOT0 pin. Depending on the package, some will also have a BOOT1/nBOOT1 pin. The table below shows how the pins should be set to enter the system memory bootloader:
Once the MCU is in the system memory bootloader, it will enable various serial interfaces depending on the MCU’s part number. To see the available interface options, I recommend checking out AN2606, a document by the electronics manufacturer ST. This comprehensive guide covers the supported peripherals, hardware requirements, and possible configurations when using the bootloader.
I‘ve found the easiest solution is to use a USART interface since ST has a demonstration tool for updating firmware over USART. However, I would highly recommend double-checking the pinout for the system memory bootloader with the MCUs datasheet. Though AN2606 is great, it's very generic—which means you can easily miss which pins need to be exposed.
Security
When I first read about the system memory bootloader, I thought, “ Great! My STM32 MCU already includes a bootloader, why bother writing my own?” Well, there are a few reasons. First and foremost, there is no security. To use the system memory bootloader, you cannot enable read/write protection on the flash memory. Therefore, anyone with physical access to the device could read, write, or erase the flash memory contents. This needs to be considered if you are planning to expose the system memory bootloader interfaces in your project.
Connectivity
Lastly, I’ve seen instances where an STM32 MCU cannot connect to a J-Link. This is typically caused by the device crashing within the first few milliseconds after booting. This may cause an endless loop of resetting the device because the device can’t run long enough for the GDB server to connect to it. To resolve this, I’ve taken advantage of the system memory bootloader. You can use the correct orientation of the BOOT0/1 pins to boot the MCU into the system memory bootloader instead of the user flash. This should allow the GDB server enough time to connect and allow you to flash a new, bug-free firmware.
I hope this overview of the system memory bootloader helps you make an informed decision of whether to incorporate the system memory bootloader into your design. Good luck tinkering!
Learn more about DMC’s Custom Software and Hardware Services.