FAQ STM32 boot process
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
on 2021-04-28 3:57 AM
What is the STM32 boot process and the system bootloader?
Summary
Please note that the STM32MP1 isn’t covered by this FAQ. For more information, see the dedicated wiki page.
1. STM32 boot process overview
- main flash memory, usually where your firmware is located: at the default value address 0x80000000 or a value define in option byte (if possible).
- ST embedded bootloader located in the system flash memory: a code flashed at production and which can’t be modified in any manner.
- SRAM: usually used for debugging purpose, or a specific action needing high performance or no-access to flash.
For the STM32, these are the only three possible boot targets.
According to the STM32 selected, this configuration will depend on a combination of:
- Pin values:
BOOT0 and BOOT1 pins level, if available on your package - Option bytes:
nBoot0/nBoot1/nBoot0_SW
BOOT_ADD0/BOOT_ADD1/nBOOT0_SEL
nDBANK/BFB2
BOOT_LOCK
TZen/NSBOOTADD0/NSBOOTADD1
RSSCMD/SECBOOTADD0/SECBOOTADD1
RDP - Content of the user flash
2. STM32 system bootloader
- Activation pattern
- Information about bootloader version and limitation
- Hardware connection recommendation
- Many "Notes" to be read carefully (all the known limitations are listed in this application note)
- How to jump in bootloader from user application.
- AN3154: CAN protocol used in the STM32 bootloader.
- AN3155: USART protocol used in the STM32 bootloader.
- AN3156: USB DFU protocol used in the STM32 bootloader.
- AN4221: I²C protocol used in the STM32 bootloader.
- AN4286: SPI protocol used in the STM32 bootloader.
- AN5405: FDCAN protocol used in the STM32 bootloader.
- STM32CubeProgrammer: UART/USB DFU and with STLinkV3: I²C, SPI, and CAN.
- DFuse demo: (USB DFU) considered in maintenance.
- Flash loader demonstrator: (UART) considered in maintenance.
3. STM32 startup from main flash memory
-
Take the initial value of the MSP from the address 0x0000_0000.
-
Take the value of the PC from the address 0x0000_0004.
-
Continue execution from the address corresponding to this value.
Keep in mind, the first 32bits word of your binary is the Main stack pointer location and the second 32bits word is the address or the reset handler.
The reset handler implementation could be found in an assembly file named for example startup_stm32g071xx.s (naming depends on the targeted device).
This one should be present in your STM32 project.
Depending on your IDE, you can find the implementation in the CMSIS package include in the STM32CubeFirmware.
For example in a STM32CubeIDE project, you can set a breakpoint in the file startup_stm32g071xx.s at those lines:
Reset_Handler: ldr r0, =_estack mov sp, r0 /* set stack pointer */And then debugging the startup of the target.
Conclusion
This article provides you information about the STM32 booting process. It gave you an overview of:
- the different boot modes possible
- information about the embedded bootloader
- basic information about STM32 boot from internal flash mechanism
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Email to a Friend
- Report Inappropriate Content
Good article.
Consider changing "Depending on you IDE" to "Depending on your IDE".
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Email to a Friend
- Report Inappropriate Content
I have question about SPI interfaces and the boot selection. I am not using SPI and I don't want it selected.
Issue 1: AN2606 says that to prevent SPI from being selected, SPI_MOSI should be at a known state (high or low) at the start of the selection process. I'm wondering if keeping SCK at a known, unchanging state (high or low) would also prevent the interface from being selected. It also seems that keeping NSS high would also prevent that interface from being selected.
Issue 2: I have a design where I use an STM32 analog input, which is connected to an op-amp output. That pin also happens to be SPI_MISO of one of the possible bootloader SPI interfaces. AN2606 says that SPI_MISO during boot mode selection is an output, which in my case would imply that the SPI_MISO pin is driving out into my op-amp output. I put a 1K resistor between the pins to prevent contention. I'm wondering if SPI_MISO is actually tri-stated, and would only drive out if NSS and SCK performed an SPI data transaction.