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.