2025-01-06 03:12 PM
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
2025-01-07 06:43 AM
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)
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-01-07 02:15 PM
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();
}