RTC Autowake Up & Hard Faults

[shotaro]

Posted on April 30, 2012 at 19:54

I'm running into a strange issue where if I have the RTC auto-wakeup enabled, I intermittently get hard faults when I run the software through the debugger, break, then step through the code. Seems to happen more frequently if I break after sleep. The hard fault reason is either INVPC or INVSTATE, and some preliminary digging through I find that the LR register has some bogus value (last time this happened, value is at 0xFFFFFFF1). I don't see anything unusual in my stack either. If I take off the RTC auto-wakeup, the processor doesn't hard fault.

I'll implement the Joseph Yui hard fault handler if the above isn't enough to go by. EDIT: the CPU state at the hard fault is as follows r0 = 0x00000000 r1 = 0x0000000b r2 = 0x00000007 r3 = 0x00000000 r4 = 0x080085a8 <- Am looking at what this is r5, r6 = 0x00000000 r7 = 0x42470000 r8-r11 = 0x00000000 r12 = 0x20001608 sp = 0x20001588 lr = 0xFFFFFFF1 pc = 0x08000350 xPSR = 0x81000003 SP_main = 0x20001588 SP_process, CFBP = 0x00000000 Also the code is compiled with the -fpic flag on (this is a requirement so I can't change it EDIT2: I went ahead and implemented the hard fault handler and got this: [Hard fault handler - all numbers in hex] R0 = 0 R1 = b R2 = 7 R3 = 0 R12 = 20001608 LR [R14] = 8000319  subroutine call return address PC [R15] = 8008800  program counter PSR = 80000013 BFAR = e000ed38 CFSR = 20000 HFSR = 40000000 DFSR = 8 AFSR = 0 SCB_SHCSR = 0

[Tesla DeLorean]

Posted on April 30, 2012 at 20:05

If it only occurs when using a debugger, then consider that the debugger isn't handling the core properly. What are you using?

What's the code at/around the faulting PC look like? I don't see mention of the part being used, if reading from flash you need to ensure that the wait states are set appropriately for the speed the core is running. The LR value in the Hard Fault handler reflects a magic value the core uses to restart the code at the faulting address/state stored on the stack.

[shotaro]

Posted on April 30, 2012 at 20:13

It's an STM32L-Discovery. The IDE I'm using is Rowley Cross Studio

Actually come to think of it, the clock speed goes down before speed and there's nothing after WFI to bring it up to speed (my external interrupts do this though). EDIT: I added the function to bring the clock speed back up after WFI. It looks more or less stable, knock on wood. Thanks for pointing the flash wait-states.