cancel
Showing results for 
Search instead for 
Did you mean: 

FAQ STM32 boot process

Frantz LEFRERE
ST Employee

What is the STM32 boot process and the system bootloader?

Summary

This article provides information about the STM32 boot process. In a first part, it gives you an overview of this process and it presents the different boot modes. In a second part, it details you the STM32 system bootloader and the STM32 boot from internal user flash memory.
Please note that the STM32MP1 isn’t covered by this FAQ. For more information, see the dedicated
wiki page.  

 

1. STM32 boot process overview

All the STM32 microcontrollers have the capability to boot from:
 
  • 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.

 
1.1 How to select the boot target?
 
The answer is available in the reference manual of your STM32 in the chapter Boot configuration.
Example of boot configuration definition for a STM32G071:

            114.jpg
 
See section 2.5 page 66 of RM0444 Reference Manual STM32G0x1.
​​​

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
Warning: in RDP level 2, the device can only boot from main flash memory
 
    1.2 Details about boot process
 
When an STM32 is powered on, the embedded flash memory automatically loads the option bytes. During the option bytes loading sequence, the device remains under reset and the embedded flash memory can’t be accessed. The values on the BOOT pin are latched on the 4th rising edge of SYSCLK after reset release and then the boot mode configuration is resolved.

 

 

2. STM32 system bootloader

2.1 Definition
 
The bootloader is stored in the internal boot ROM (system memory part of the flash) of any STM32 device, and is programmed by ST during production. Its main task is to download the application program to the internal flash memory through one of the available serial peripherals, such as USART, CAN, USB, I2C, or SPI.
 
2.2 THE reference document: AN2606
 
This document, AN2606 STM32 microcontroller system memory boot mode, gives all the details about:
  • 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.
Remark: on some STM32 with flash empty check mechanism, it's not possible to jump in the bootloader from your application running in the user flash. All the details are described in this AN2606.
To check if you properly activated the bootloader, or to investigate any communication issue with the bootloader, we can propose you also to follow our related MOOC:   STM32 boot and startup tips MOOC
 
2.3 Protocol used in the STM32 bootloader.
 
For each communication interface (CAN/USART/USB/I2C/SPI/FDCAN), a dedicated application note describes the protocol:
  •  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.
 
2.4 PC tools to communicate with embedded 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

 
All STM32 are based on Arm Cortex-M core. The boot process of this core is:
  1. Take the initial value of the MSP from the address 0x0000_0000.
  2. Take the value of the PC from the address 0x0000_0004.
  3. Continue execution from the address corresponding to this value. 
On many STM32 families, the boot address in the internal flash is 0x8000000. This address is remapped to address 0x00000000 by boot mode mechanism. The address located at 0x0000_0004 will point on the reset handler.
On some families like STM32H7 or STM32L5, the boot address could be different and specified thanks to the option bytes.
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.
STM32Cube_FW_G0_VX.Y.Z\Drivers\CMSIS\Device\ST\STM32F0xx\Source\Templates\iar
STM32Cube_FW_G0_VX.Y.Z\Drivers\CMSIS\Device\ST\STM32F0xx\Source\Templates\gcc
STM32Cube_FW_G0_VX.Y.Z\Drivers\CMSIS\Device\ST\STM32F0xx\Source\Templates\arm

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

    
 
Comments
JMerk.1
Associate

Good article.

Consider changing "Depending on you IDE" to "Depending on your IDE".

hwsw
Associate II

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.

Version history
Last update:
‎2021-04-28 03:57 AM
Updated by: