Hard Fault-> INVALID STATE when calling WFI() STM32L

ioannis2 · ‎2014-07-31

Posted on July 31, 2014 at 10:46

I hit an issue with our STM32L project that is giving meheadaches.

We have recently upgraded from STM32L151VB to STM32L151VC as we needed the extra RAM.

Migrating the code though, has started triggering HARDfaults with the Invalid state flag set in the CFSR. It just so happens when calling the _WFI() instruction to go to sleep.

(using IAR 7.10.3). The problemdisappears if I put a breakpoint before or on the WFI operation ( see addr 0x800bc1e in disassembly dump ). The problem occurs again in a different location if I modify the code and the binary moves around.

I have implemented a hard fault handler as suggested by joseph yiu, but the contents of the recovered stack do not tell me much as it looks to be coming from some other interrupt or fault (LR), the PC is invalid (EVEN)

[Hard fault handler - all numbers in hex]

R0 = 0x0

R1 = 0xe000ed10

R2 = 0x1000

R3 = 0x66000000

R12 = 0xe5ffffff

LR [R14] = 0xfffffff9 subroutine call return address

PC [R15] = 0x7000 program counter

PSR = 0x6000002a

BFAR = 0xe000ed38

CFSR = 0x00020000

HFSR = 0x40000000

DFSR = 0x1

AFSR = 0x0

SHCSR = 0x0

Forced Hard Fault

Usage fault: INV STATE

I have examined all the interrupt vector entries, they all seem to be on an odd address as expected�

Do anybody have any ideas at all?

I have implemented a hard fault handler as suggested by joseph yiu, but the contents of the recovered stack do not tell me much as it looks to be coming from some other interrupt or fault (LR), the PC is invalid (EVEN)

[Hard fault handler - all numbers in hex]

R0 = 0x0

R1 = 0xe000ed10

R2 = 0x1000

R3 = 0x66000000

R12 = 0xe5ffffff

LR [R14] = 0xfffffff9 subroutine call return address

PC [R15] = 0x7000 program counter

PSR = 0x6000002a

BFAR = 0xe000ed38

CFSR = 0x00020000

HFSR = 0x40000000

DFSR = 0x1

AFSR = 0x0

SHCSR = 0x0

Forced Hard Fault

Usage fault: INV STATE

I have implemented a hard fault handler as suggested by joseph yiu, but the contents of the recovered stack do not tell me much as it looks to be coming from some other interrupt or fault (LR), the PC is invalid (EVEN)

[Hard fault handler - all numbers in hex]

R0 = 0x0

R1 = 0xe000ed10

R2 = 0x1000

R3 = 0x66000000

R12 = 0xe5ffffff

LR [R14] = 0xfffffff9 subroutine call return address

PC [R15] = 0x7000 program counter

PSR = 0x6000002a

BFAR = 0xe000ed38

CFSR = 0x00020000

HFSR = 0x40000000

DFSR = 0x1

AFSR = 0x0

SHCSR = 0x0

Forced Hard Fault

Usage fault: INV STATE

I have implemented a hard fault handler as suggested by joseph yiu, but the contents of the recovered stack do not tell me much as it looks to be coming from some other interrupt or fault (LR), the PC is invalid (EVEN)

[Hard fault handler - all numbers in hex]

R0 = 0x0

R1 = 0xe000ed10

R2 = 0x1000

R3 = 0x66000000

R12 = 0xe5ffffff

LR [R14] = 0xfffffff9 subroutine call return address

PC [R15] = 0x7000 program counter

PSR = 0x6000002a

BFAR = 0xe000ed38

CFSR = 0x00020000

HFSR = 0x40000000

DFSR = 0x1

AFSR = 0x0

SHCSR = 0x0

Forced Hard Fault

Usage fault: INV STATE

#hard-fault-stm32l

Tesla DeLorean · ‎2015-02-20

Posted on February 20, 2015 at 19:39

I seem to recall some EVENT related errata.

Consider if the new part has a different M3 Core revision, if there are additional vector entries for the ST peripheral side. Things like the flash and prefetch might impact how it behaves out of low power.

As far as I'm aware it's going to execute the interrupt code, before getting to your WFI loop. Perhaps someone with more insight into the core can give some thoughts?

You could GPIO pins to confirm IRQ entry/exit, and WFI loop iterations, and fault entry.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

cemer · ‎2015-02-22

Posted on February 22, 2015 at 20:07

Ok, here is some more information:

I did several tests under different conditions. Not finished yet. Sor far, it seems that the problem only occurs in debug mode. When there is no debugger attached to the device, the cpu runs just fine - hopefully! :)

I went through both erratas of L151VB and L151VC. There is no item which is related with WFI. There is indeed a debug-sleep related event issue, hoever, it is associated with WFE. According to erratas both CPU have the same CM3 core.

According to the debugger, the first instruction following the WFI, whether it is a NOP or something else, is causing the hard fault. Putting NOP's or Breakpoints around the WFI line did not change the result. Please note that, DBGMCU_Config sleep mode is enabled. For test purposes, I also lowered the os tick frequency to 100 tics/sec and 10ticks/sec, however, the result is always the same. I also tried __DSB(), __ISB() as recommended above but it did not make any difference either.

I also did further googling and came accross the STM32 Circle forum with a very similar looking problem: http://www.stm32circle.com/forum/viewtopic.php?id=19 . Looks like they had to take the WFI completely out of the main loop..

There is something more interesting with that thread: It shows that ST people is already aware of such a problem since quite a while. However, they did not provide any input to that thread. I hope they provide to this one...

Tesla DeLorean · ‎2015-02-22

Posted on February 23, 2015 at 03:21

What JTAG/SWD debugger and tool chain is being used here?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

damh · ‎2015-02-22

Posted on February 23, 2015 at 06:43

Are the optionbytes especially the flags nRST_STDBY and nRST_STOP, ... set to default?

What are the first 8 bytes after 0x8000000?

cemer · ‎2015-02-23

Posted on February 23, 2015 at 09:26

I am using GCC 4.7.3 + GDB 7.4.50 + JLink.

Here is the first 8 bytes: 00 80 00 20 85 8B 01 08.

nRST_STDBY = OB_STDBY_NoRST

nRST_STOP = OB_STOP_NoRST