STM32H503: random ECC/NMI on flash read after bootloader jump

[JonathanTecmotion]

Hi,

I have a bootloader (0x08000000) jumping to an application (0x0800C000) on an STM32H503CB, everything at 32 MHz HSI, VOS3. The bootloader runs at 1WS flash latency, disables the ICACHE and jumps.

 

About 1 boot in 5, the app dies in the NMI handler right after the jump: FLASH_ECCDETR shows a double ECC error on the very flash line being fetched, at a different address every time. The flash content is intact when read back over SWD - the read just fails transiently. It also depends on the chip: 2 of my 3 boards reproduce it, one never does.

If I restore the latency to 3WS (the reset value) in the bootloader just before jumping, the problem disappears completely (200+ reset campaigns, zero failure).

 

My question: why is the H5 sensitive to flash wait states in this situation? 1WS at 32 MHz / VOS3 should be enough on paper, and the bootloader itself runs fine with it. Is there something specific about executing uncached from flash right after a bootloader handover that requires more margin, and is restoring the reset latency before jumping the recommended practice?

 

Jonathan
 

[waclawek.jan]

> disables the ICACHE 

Why? How?

JW

[STOne-32]

Dear ​@JonathanTecmotion ,

the case seems hitting this Errata :

 

2.2.13 Read from flash memory may fail in VOS2 and VOS1 range

https://www.st.com/resource/en/errata_sheet/es0561-stm32h503cbebkbrb-device-errata-stmicroelectronics.pdf

Can you double check if after jumping from bootloader you are in VOS3 ? And not VOS2 or 1 .

Let us know to debug further .

Regards,

STOne-32

 

[JonathanTecmotion]

Thank you - I agree the signature matches erratum 2.2.13 exactly (transient read failure, double ECC error, NMI, content intact). But I can confirm we are in VOS3, checked at register level over SWD:

- PWR_VOSCR = 0x00000000 (VOS = 0b00 = VOS3)
- PWR_VOSSR = 0x2008 (VOSRDY = 1, ACTVOSRDY = 1, ACTVOS = 0b00 = VOS3)

Both the bootloader and the application explicitly configure VOS3 in SystemClock_Config, and no code path ever selects VOS1 or VOS2, so there is no VOS transition around the jump either - the regulator stays in VOS3 from reset onwards.

So the observed behavior is 2.2.13's failure mode occurring in VOS3, at 1WS/32 MHz, only during the uncached startup window right after the bootloader handover, and only on some chips (2 of 3 boards). Restoring 3WS before the jump fully cures it.

Regards

[STOne-32]

Dear ​@JonathanTecmotion ,

Thank you for the follow-up and details given, my recommendation at this level is to check VCAP values and all around power supply. Then to log a Ticket with our Online Support to engage with my regional FAEs to debug the case .

Regards,

STOne-32

[waclawek.jan]

What happens if you place some delay - perhaps a couple of _DSB() or something other time wasting method - between disabling the cache and the jump?

Also, try to measure voltage at VCAP pin(s), if you have a good enough oscilloscope/probing at hand - I’d look if it won’t drop above or below the specified range for VOS3 for a couple of cycles.

JW