on - edited on by
Laurids_PETERSE
Summary
This article provides information about the STM32 boot process. In the first part, it gives you an overview of this process and it presents the different boot modes. In the second part, it details the STM32 system bootloader and the STM32 boot from internal user flash memory.
Note that the STM32 microprocessors are not covered by this FAQ. For more information, see the dedicated wiki page.
1. STM32 boot process overview
All the STM32 microcontrollers are able to boot from the following:
- Main flash memory, usually where your firmware is located, at the default value address 0x0800_0000 or a value defined in option byte (if possible).
- ST embedded bootloader, located in the system flash memory, a code flashed at production, and which cannot be modified in any manner.
- SRAM, usually used for debugging purposes, or a specific action needing high performance or no-access to flash.
For STM32 microcontrollers, 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".
Below is an example of a boot configuration definition for a STM32G071:
See section 2.5 page 68 of RM0444 Reference Manual STM32G0x1.
According to the STM32 selected, this configuration depends 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 the 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 cannot be accessed. The values on the BOOT pin are latched on the fourth rising edge of SYSCLK after reset release. Afterwards, 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, I²C, or SPI.
2.2 The reference application note: AN2606
This application note, 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 to bootloader from the user application.
Note: on some STM32 microcontrollers with flash empty check mechanism, it is not possible to jump in the bootloader from your application running in the user flash. All the details are described in this application note.
To check if you properly activated the bootloader, or to investigate any communication issue with the bootloader, you could follow our related MOOC: STM32 boot and startup tips MOOC
2.3 Protocols 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 the embedded bootloader
- STM32CubeProgrammer: UART/USB DFU and with STLinkV3: I²C, SPI, and CAN.
- DFuse demo (USB DFU): considered not recommended for new designs.
- Flash loader demonstrator (UART): considered not recommended for new designs.
3. STM32 startup from main flash memory
All STM32 microcontrollers are based on the Arm Cortex®-M core. The boot process of this core is:
- 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.
On many STM32 families, the boot address in the internal flash is 0x0800_0000. This address is remapped to address 0x0000_0000 by the boot mode mechanism. The address located at 0x0000_0004 will point on the reset handler.
On some families like the STM32H7 or STM32L5, the boot address could be different and specified thanks to the option bytes.
Keep in mind, the first 32-bit word of your binary is the main stack pointer location and the second 32-bit word is the address of the reset handler.
The reset handler implementation can be found in an assembly file named for example startup_stm32g071xx.s (naming depends on the targeted device).
This file 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 provided 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 the internal flash mechanism.
