2025-06-02 5:08 AM - edited 2025-06-02 5:15 AM
Hello everyone,
MCU in use: STM32H745XI (dual-core, Bootloader v9.1, CubeIDE 1.16.1, HAL v1.11.3, CubeProgrammer v2.17.0)
Hardware status: BOOT0 HIGH works perfectly, I can access the system bootloader over USART1 (PA9/PA10), and program via UART. Hardware is validated and all connections are good. PB15/PB14 pins are floating, not connected anywhere.
My need:
I want to jump from user application (C code only, no BOOT0 pin) to the internal ROM system bootloader for firmware update purposes, so that I can upload new firmware over UART (using CubeProgrammer or similar), and then return to normal application on the next reset.
Here are the methods I have tried (none worked):
Set MSP to 0x1FF09800, jump to 0x1FF09804 (function pointer), disable all interrupts (NVIC->ICER), set PRIMASK/FAULTMASK, disable and invalidate caches (SCB), disable SysTick, deinit all peripherals (HAL_DeInit, RCC_DeInit, etc.).
Disable MPU/SAU regions (including secure/privileged regions).
Put all GPIOs (including used UART pins) in analog input (to avoid interference).
Set all memory barriers (DSB/ISB) and do multiple dummy memory accesses before jump.
Used both CM7 and CM4 cores for jump (with CM4 in low power/stop or held in reset).
Verified that all Option Bytes are in default state except BOOT_CM7_ADD1 = 0x1FF0 (0x1FF00000).
Result:
MCU freezes (hard fault or lockup) and system bootloader never responds on UART.
BUT, if I use BOOT0 HIGH and reset the MCU, bootloader always works (handshakes over UART as expected).
My questions:
Has anyone successfully jumped to the system bootloader on STM32H745XI purely by C code (no BOOT0/OB change), and if so, how?
Is there any undocumented, low-level trick (register hack, RAM/stack/clock/secure config, etc.) to force bootloader entry, or is it silicon-level blocked?
Why exactly does the function pointer jump method (as used in STM32F4/F7/L4, and sometimes H747) fail on H745XI? Is there an internal hardware barrier at reset/boot?
Are there any real-world solutions beyond changing Option Bytes (which I can do, but would like to avoid for safety reasons)?
Notes:
PB15/PB14 pins are floating and not connected, so no TX damage risk.
If I brick the MCU, I can recover via SWD/JTAG or CubeProgrammer, so I am open to any risky/experimental ideas.
Any direct practical experience from someone who actually achieved this on STM32H745XI (not just theory or F4/F7 tricks) would be extremely valuable.
References:
Reference Manual Table 123 and Table 124 (bootloader address 0x1FF00000, entry 0x1FF09800, V9.1 limitations).
Datasheet: "Jump issue" and "boot mode is only checked at reset."
Thank you in advance!
Solved! Go to Solution.
2025-06-08 5:21 AM - edited 2025-06-12 4:52 AM
Dear @Ahmet Yasin CİVAN ,
Thank you very much for the detailed post and also valuable contribution to our STCommunity on how to jump in safe mode to system memory.
Thank you again
STOne-32
2025-06-10 6:21 AM - edited 2025-06-10 6:21 AM
Thank you so much for the kind words! I'm glad I could share some insights and help out in the STCommunity. If there’s ever any other tricky STM32H7 issue you’d like to chat about or if you’d like more details on my approach, just let me know — always happy to discuss!