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
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?