Introduction
The STM32H5 microcontroller series has been observed to exhibit issues when using the GO command to start user code after entering the bootloader via a hardware reset. This article aims to explain the problem in detail and provide possible solutions to ensure that the GO command works correctly when booting from system memory.
1. Problem description
When using the STM32H5 microcontroller, we can encounter an issue where the user code does not start running after issuing the GO command to the bootloader. The problem occurs specifically when the bootloader is entered via a hardware reset with the BOOT0 pin set high. The user code runs correctly only after a subsequent hardware reset.
1.1. Observations
1.1.1. Bootloader entry methods
- Jumping from user code: The GO command works correctly.
- Hardware reset with BOOT0 high: The GO command does not start the user code.
1.1.2. Debugging results
- After issuing the GO command, the debugger breaks at address 0x0.
- The user code does not reach the startup code.
- A hardware reset is required to start the user code.
2. Technical explanation
The STM32H5 family boots on the RSS (Root Secure Services) during Open/Provisioning life cycles. The RSS then jump to the bootloader. This process is secure, and only the resources needed by the bootloader are opened to the nonsecure world.
In fact, in STM32H5 series boot is not depending on TrustZone® value and goes through SFSP first, then jumps to the bootloader. In this model, some constraints are added to the bootloader functionalities on both TZEN states.
Boot timing includes SFSP timing. Before jumping to the bootloader, the SFSP maps all the needed resources by the bootloader to the nonsecure domain. A jump from the bootloader (“GO” command) to an application using other resources does not work.
Some secure option bytes are not accessible by the bootloader as it is nonsecure. Some APIs are added on the SFSP to ensure that the bootloader can modify them in open products states. Refer to AN2606 Table 115. STM32H562xx/563xx/573xx special commands for more information.
Some parts of the SRAM are used by the SFSP and remain on secure domain when jumping to the bootloader, consequently they are not accessible by the user through the bootloader.
2.1. Key points
- RSS boot: The boot process is secure, and only the necessary resources are opened.
- GO command: When the GO command is issued, it attempts to jump to the user application.
However, since only the resources needed by the bootloader are opened, any additional resources required by the user application are not available, leading to a crash.
3. Possible solutions
To ensure that the GO command works correctly when booting from system memory, consider the following solutions:
3.1. Hardware reset
After programming the user code, perform a hardware reset to start the user code. This method ensures that all necessary resources are available for the user application.
3.2. Modify boot OB then execute the rest command from the bootloader
Users can write their firmware in the user flash and then change the boot from system memory to user flash. Do so by changing the option bytes and then perform a reset using the reset command available in the bootloader (special command).
3.3. Use jump from user code
When TZEN = 0 instead of entering the bootloader via a hardware reset, jump to the bootloader from the user code. This method has been observed to work correctly with the GO command. For instructions on how to enter the bootloader from a user application, refer to this article: How to jump to system bootloader from application code on STM32 microcontrollers.
Conclusion
The issue with the GO command on the STM32H5 microcontroller family is related to the secure boot process and the resources opened by the RSS. By understanding the boot process and ensuring all necessary resources are available, you can replicate the same effect of a go command from the bootloader. The recommended solutions are to perform a hardware reset after programming the user code to ensure it starts running correctly. Also, to reprogram option bytes in the bootloader to boot from user flash followed by reset special command.
For further assistance regarding this issue, or any similar issue related to bootloader on STM32H5, feel free to create a post in the community under
