STM32U5A5 instruction fault after WFI

[kamnxt]

Struggling with a really weird issue here.

I'm working on a project using Zephyr on an STM32U5A5ZJT6Q. We are using an LSE-clocked LPTIM as the tick source, PM enabled with STOP0 and STOP1 modes.

At some point, we started noticing random crashes, which seemed to occur sporadically, more often on some boards than others. These would usually be in the `idle` zephyr thread, specifically after a `wfi` instruction.

Digging around, I found some errata (specifically 2.2.26 for STM32U575xx STM32U585xx, related to flash prefetch, and now also 2.2.6 for STM32U59xxx STM32U5Axxx, related to wake-up from stop mode).

HardFault on wake-up from Stop mode may occur in debug mode
Description
A HardFault may occur at wake-up from Stop mode when the following conditions are met:
• Device is in debug mode.
• DBG_STOP bit is set in DBGMCU_CR.
• A wake-up event/interrupt from an SRD peripheral (except EXTI) occurs in a timing window of four clock
cycles during Stop mode entry sequence. SRD peripherals are the ones connected to AHB3 and APB3.
Workaround
None.

Usually what happens here is that we get a UsageFault / undefined instruction fault (not HardFault) at an ISB after the WFI. We suspected this was related to flash prefetching, but it also happens (although less often?) when putting the idle function in RAM:

Disassembly of section .ramfunc:

20000000 <arch_cpu_idle>:
20000000: b508 push {r3, lr}
20000002: f000 f80d bl 20000020 <__sys_trace_idle_veneer>
20000006: b672 cpsid i
20000008: 2300 movs r3, #0
2000000a: f383 8811 msr BASEPRI, r3
2000000e: f3bf 8f6f isb sy
20000012: f3bf 8f4f dsb sy
20000016: bf30 wfi
20000018: b662 cpsie i
2000001a: f3bf 8f6f isb sy
2000001e: bd08 pop {r3, pc}

20000020 <__sys_trace_idle_veneer>:
20000020: f85f f000 ldr.w pc, [pc] ; 20000024 <__sys_trace_idle_veneer+0x4>
20000024: 080d9dc7 .word 0x080d9dc7
...

With this code, the fault always happens at 2000001a, and checking from our fault handler, we see a pending interrupt from the LPTIM timer.
However, this also seems to happen without a debugger connected and a full power cycle, which means we shouldn't be in debug mode?

Could you either confirm that this is erratum 2.2.6, or if this might be something else? I tried adding an extra ISB between `wfi` and `cpsie i`:

Disassembly of section .ramfunc:

20000000 <arch_cpu_idle>:
20000000: b508 push {r3, lr}
20000002: f000 f811 bl 20000028 <__sys_trace_idle_veneer>
20000006: b672 cpsid i
20000008: 2300 movs r3, #0
2000000a: f383 8811 msr BASEPRI, r3
2000000e: f3bf 8f6f isb sy
20000012: f3bf 8f4f dsb sy
20000016: bf30 wfi
20000018: f3bf 8f6f isb sy
2000001c: b662 cpsie i
2000001e: f3bf 8f6f isb sy
20000022: bd08 pop {r3, pc}
20000024: 0000 movs r0, r0

And this made the fault PC point to 0x20000020, and fail with a HardFault this time, with bit 30 (FORCED) set in HFSR.

Maybe there's a way to figure out what gets corrupted, and find a workaround for this issue?

[Matt001k]

Bump:
Any update on this, I am also experiencing this exact issue.

Can provide more information if necessary and workarounds I have been working on.

[Matt001k]

For all the cool cats out there that might need a fix for this. Our team’s fix for this issue is located here, albeit on an STM32U575.
It also seems maybe slightly related to other forum posts such as this post or this post in relation to other chipsets.

[T_Hamdi]

Hello ​@kamnxt 

This does not look like a faulty WFI instruction itself. It looks more like a problem during the STOP -> wake-up -> interrupt entry sequence, when the pending LPTIM interrupt is taken immediately after wake-up.

 

The PC pointing to the ISB after WFI is not enough to conclude that ISB is the failing instruction. On Cortex-M, that is often just the last visible instruction before exception entry begins.

Also, moving only arch_cpu_idle() to SRAM does not remove flash from the critical path, because the vector table and the LPTIM ISR are usually still in flash. The fact that adding one more ISB changes the observed fault from UsageFault/UNDEFINSTR to HardFault/FORCED also looks more like a timing shift than a real fix.

So I would be careful about concluding immediately that this is exactly erratum 2.2.6. That erratum only applies if the device is really in debug mode, DBG_STOP is set, and the wake-up event occurs in the specific timing window described by ST. If you can reproduce the issue after a real power cycle with no debugger attached, then that erratum alone probably does not fully explain it.

My interpretation would be: not a bad WFI, not really a bad ISB, but a wake-up/exception-entry fault path, possibly involving flash, vector fetch, or ISR fetch timing after STOP exit.

 

A very useful test would also be to try the same setup without STOP mode(sleep), or move both the vector table and the LPTIM ISR to SRAM. If the fault disappears, that would strongly point to the STOP wake-up / exception-entry path rather than the idle function itself.

 

Best regards,

Hamdi

[Matt001k]

​@T_Hamdi I have run this test without a debugger and without stop mode.

• I still experienced the crash without the debugger.

• I did not experience the crash when stop mode is disabled.

What you are saying about flash fetching seems correct (to note other things I tried were disabling pre-fetch, placing the function calling WFI into RAM, but still experienced the fault). But when the crash was occurring, interrupts were disabled.

I did not attempt to move the vector table and ISR into SRAM as that is a bit riskier of a solution than what I had come up with,
which was adding a _NOP() after the WFI call and before ISB.

Is this a potential known issue/quirk with stop modes on ST processors?