STM32L Hard fault after waking up from EXTI

[shotaro]

Posted on December 18, 2012 at 03:22

I'm programming for an STM32L152xx and ran into the part hard faulting when it goes to sleep but wakes up from an external interrupt.

Since I need the lower power sleep mode, I'm doing the necessary steps to get there (enabling the right flags in PWR->CR, switching the clock to MSI, calling WFI). When I wake up the part with an external interrupt, right after it's done handling the interrupt, it hard faults. I can break at the last line and hit ''Step Over'' and the processor jumps to the hard fault handler. The reason being the processor was in an invalid state at some point. I can't find anything obvious in the stack and Joseph Yui's hard fault handler hangs at the first line (R4 is always 0) The catch is though, this only happens if I enable optimizations. If I take it off, the software runs just fine. The IDE is Rowley CrossStudio, which is using GCC. I'm sure the optimization it performs is the -O flag. If this something GCC related, I can wait until I transfer over to IAR (I'm waiting for a license) assuming they don't use GCC. Some other oddities if it interests people:

• It happens if the processor goes to sleep. If I take out the WFI call, it doesn't hard fault
• If I don't clear the EXTI pending flag for the EXTI interrupt, it will hang in the interrupt and the hard fault will never happen.

[Tesla DeLorean]

Posted on December 18, 2012 at 04:15

I'm not sure GCC generates bad code, but there have been a couple of forum members who've tickled specific critical path issues in ST's prefetch circuit on the F2 and F4 chips using the GCC code generator.

I guess it would look at what the SRAM and Flash wait state and prefetch were doing. Look at the system/process stack state and the return address for the *interrupt*, and try and unwind that, rather the waiting for the Hard Fault and postmortem that. If the stack state doesn't make sense then the return is going to fail. I'd look at DBGMCU_CR (DBG_STOP and DBG_SLEEP), and also RCC_AHBLPENR (SRAMLPEN and FLITFLPEN)

[shotaro]

Posted on December 18, 2012 at 19:38

Thanks for getting back to me Clive.

I checked out what you mentioned and the only thing that came up odd is the context being pushed on the stack. In the optimized build, xPSR and PC aren't being saved for some reason. EDIT: Would optimizations break debugging? Out of curiosity I slurped the hex file into the MCU using the ST-Link utility and it doesn't hard fault.