Secondary Bootloader works on STM32U575 REV.X; fails on REV.U

[MishKa59]

Are there differences between STM32U575 REV.U vs REV.X? I have two boards manufactured with a 1-year gap, with STM32U575 REV.X and REV.U. On the first board (REV.X), my Secondary bootloader runs the FW successfully, but not on the second board(REV.U). Why?

[AScha.3]

from Ai .

The differences between the STM32U575 silicon revisions (Rev U vs. Rev X) primarily relate to bug fixes and low-power drive mode optimizations. [1, 2]

• Drive Levels: Revision X (and newer) unlocks all specific power drive levels, including Low-Drive and Medium-Low Drive. Older revisions (like W or U) often lacked support for these specific reduced drive features. [1]
• Errata Fixes: Rev U was introduced as an updated silicon revision that resolves several device limitations present in older revisions (such as Rev X and Rev W), including various issues with low-power mode transitions and clock synchronization. [1, 2, 3]
• Flash/Memory & Debug: Rev U addresses stability issues with memory access and hard faults that previously occurred upon waking from certain low-power/sleep modes. [1]

So U is more recent and should work more "correct" , as given in ds.

Gemini says about your problem:

When a secondary bootloader works perfectly on Revision X but fails on Revision U of the STM32U575, the root cause is almost always related to stricter timing enforcement, clock stability fixes, caching behaviors, or power-drive settings that STMicroelectronics corrected in the newer Rev U silicon.

Because Rev X was an early, bug-heavy engineering/production silicon, developers often unknowingly wrote code that worked around (or relied upon) unintended hardware behavior.

The most likely reasons for a bootloader failure on Rev U include:

1. Instruction Cache (ICACHE) and Data Cache (DCACHE) Management

• The Difference: Rev U features critical hardware timing fixes for the ICACHE and flash prefetch buffers. Rev X was sluggish and forgiving regarding cache coherency during firmware jumps. [1]
• The Failure: If your bootloader initializes MX_ICACHE_Init(), copies/downloads new code into flash, and jumps to the application without explicitly invalidating and disabling the cache, the CPU on Rev U will attempt to execute stale instructions from the cache instead of the newly written flash. [1]
• The Fix: Right before jumping from the bootloader to the main application, completely disable and invalidate both the ICACHE and DCACHE:

  HAL_ICACHE_Disable();
  HAL_DCACHE_Disable();

  [1]

2. Missing Clock and Peripheral De-initialization

• The Difference: Rev U enforces strict clock gating and state verification. If a peripheral is left running or an interrupt is active during the jump, Rev U's revised hardware matrix will likely trigger a HardFault or Lockup.
• The Failure: Rev X might have quietly ignored active interrupts or active DMA transfers during a manual Program Counter (PC) jump. Rev U will crash immediately if an interrupt fires mid-jump and vectors to a bootloader address that no longer handles it.
• The Fix: You must reset the MCU state to default before jumping. The absolute safest method is using a software-generated reset via the Application Interrupt and Reset Control Register (AIRCR). If performing a direct jump, manually de-initialize everything:

  HAL_RCC_DeInit();
  HAL_DeInit();
  __disable_irq();// Clear any pending interrupts in NVIC
  for (int i = 0; i < 8; i++) NVIC->ICER[i] = 0xFFFFFFFF;for (int i = 0; i < 8; i++) NVIC->ICPR[i] = 0xFFFFFFFF;

  [2]

3. Flash Memory Wait States (Latency)

• The Difference: Rev U fixed internal core timing and low-power drive levels. Because the core now fetches and runs instructions exactly at the intended efficiency, the Flash Access Latency (Wait States) settings are strictly enforced.
• The Failure: If your bootloader alters system clocks (e.g., boosts the MSI or HSI to 160MHz) but sets the flash wait states incorrectly for that speed, Rev X might have slid by due to its looser timings, whereas Rev U will instantly encounter flash read errors or hard faults.
• The Fix: Double-check that your FLASH_ACR (Flash Access Control Register) latency settings exactly match the clock frequency requirements outlined in the STM32U5 Reference Manual.

4. Low-Power Drive Level Adjustments (VCORE Range)

• The Difference: One of the biggest changes from Rev X to Rev U is the stabilization of VCORE Power Drive levels (Range 1 through Range 4).
• The Failure: If your bootloader modifies the power voltage scaling (HAL_PWREx_ControlVoltageScaling) to save power or bump speeds, the power supply state machine behavior is different on Rev U. If the bootloader jumps before the Voltage Regulator is fully stable (Ready flag checking), the device will lock up on Rev U.
• The Fix: Ensure your code strictly polls the VOSRDY (Voltage Scaling Ready) flag after any power range transition before executing further code or triggering a jump.

How to diagnose:

1. Attach a debugger to the Rev U board.
2. In your IDE (e.g., STM32CubeIDE), set a breakpoint at the exact line where the bootloader sets the Stack Pointer (SP) and jumps to the application.
3. Step into the instruction. If it faults immediately, check the HFSR (HardFault Status Register). If it flags an IACCVIOL (Instruction Access Violation) or STKERR, it confirms that the cache is dirty or an interrupt vector was left unhandled. [3, 4]

Are you using a custom jump routine, or are you utilizing a framework like MCUBoot? If you can share the lines of code handling the jump and peripheral shutdown, I can look for specific incompatibilities. [5]

[1] https://community.st.com

[2] https://community.st.com

[3] https://community.st.com

[4] Solved: How to tell if interrupts are enabled - STMicroelectronics Community

[5] https://community.st.com

[MishKa59]

Thanks for the answer, my code:

void RunFw()
{
 HAL_DeInit();

 /* Initialize user application's Stack Pointer */
 __set_MSP(((uint32_t*)FW_IMG_FLASH_ADDR)[0]);

 /* Jump to user application */
 ((void(*)(void))((uint32_t*)FW_IMG_FLASH_ADDR)[1])();
}

---

Edited to apply proper source code formatting - please see How to insert source code for future reference.

[AScha.3]

Did you try all recommended measures?

...

HAL_ICACHE_Disable();
HAL_DCACHE_Disable();

HAL_RCC_DeInit();
HAL_DeInit();
__disable_irq();// Clear any pending interrupts in NVIC
for (int i = 0; i < 8; i++) NVIC->ICER[i] = 0xFFFFFFFF;for (int i = 0; i < 8; i++) NVIC->ICPR[i] = 0xFFFFFFFF;

+

1. Attach a debugger to the Rev U board.
2. In your IDE (e.g., STM32CubeIDE), set a breakpoint at the exact line where the bootloader sets the Stack Pointer (SP) and jumps to the application.
3. Step into the instruction. If it faults immediately, check the HFSR (HardFault Status Register). If it flags an IACCVIOL (Instruction Access Violation) or STKERR, it confirms that the cache is dirty or an interrupt vector was left unhandled. [3, 4]