Hard fault on waking from stop mode while debugging on U073

[tkern]

I've been getting some weird hard faults on an STM32U073RCT, which I've tracked down to the following conditions
- In stop mode, waiting on an interrupt.
- Debugging, with debug in stop mode enabled.
- Interrupts are disabled.
- An RTC interrupt occurs.
When this happens, I get a hard fault a few instructions after the WFI - the exact distance seems to vary based on the instruction's offset. Single stepping though them does not cause a fault.

I've attached a minimal cube ide demo project to replicate the issue. It requires a board with a crystal to run the RTC.

Set two breakpoints, one at stm32u0xx_it.c:85 (for hard faults), one at main.c:126 (on success). Only the hard fault gets hit. Examining the stack shows the previous program counter was 0x8000248, which points to one of the NOPs.

A few things I've found which avoid the issue, and hit the other breakpoint:
- Uncomment the "DBGMCU->CR = 0" line - assuming your debugger doesn't time out
- Commenting out setting sleep deep
- Commenting out disabling the irqs
- Setting a breakpoint at address 0x8000246, single stepping a few times, and then continuing

This seems similar to the following issue, which now appears in the U5 eratta, though I have yet to find anyone reporting the same on a U0.
https://community.st.com/t5/stm32-mcus-products/waking-from-stop-mode-causes-hard-fault-but-only-when-debugging/m-p/105048

[Sarra.S]

Hello @tkern, welcome to ST Community, 

I was able to replicate the behavior using a NUCLEO-U083, I'm reporting this internally for further investigation (Ticket number: 199758) 

[sshaw]

I have run into the same issue on an stm32u031. Has there been any further investigation on this?

[tkern]

A workaround appears to be moving the WFI into a ram function, and adding an ISB after it.

static void __attribute__((noinline, section(".RamFunc"))) wait_for_interrupt(void)
{
	__WFI();
	__ISB();
}