HardFault Exception: Why oh why??!

Posted on May 17, 2011 at 12:55

Dear Joseph,

I'm facing an issue with Usage Fault, I have implemented your method posted in our forum and also described in your Book : which is really very helpful and better than ARM Cortex-M3 Manuals for describing theses kind Issues { comments already escalated to your colleagues @ ARM :) }

The issue is happening after 5/6 hours of code run using RVCT Compiler, linker -O1 from Keil which are the same as RVDS/ARM. Here attached a screen-shot, could you please give some pointers, what is going wrong ? Moving the Compiler options to -02 , the problem disappears. It seems it to me a Corrupted stack in an IRQ event. I've used SWV but it can not help since the asynchronous trace is not efficient, Next step, I will use a real Trace with SignumJtrace-Cortex-M3. Are you aware of such issues with RVCT/Keil ?

Thank you a lot in advance.

Cheers,

STOne-32.

Posted on May 17, 2011 at 12:55

Usually, a HardFault Exception is caused by access to non-exist memory area.

To debug it, you may put a breakpoint at exception handler and exam the stack to check where it comes from when the exception triggered. Know the fault location will help you find out the root cause.

;)

Posted on May 17, 2011 at 12:55

Your registers seem... wrong? Seems like you're printing addresses instead of contents or what?

I debug this like this:

- check PC for code that caused the fault (and hope it's not ''inexact'', then PC might not be exactly at the instruction).

- check BFAR (if valid, meaning not containing its address) for address that was read/written and caused the fault.

Posted on May 17, 2011 at 12:55

Dear All,

i know it's a quite old thread, but i encountered similar problems so i will proceed with it.

I also have problems with hard fault exception on an STM32F103VET6. I extended the hard fault exception handler like described by joseph.yiu and relaxe. Now I have some results at the exception handler:

[Hard fault handler]

R0 = 200003f8

R1 = 200003f8

R2 = 20000400

R3 = 20000400

R12 = 20000408

LR = 20000408

PC = 20000410

PSR = 20000410

BFAR = e000ed38

CFSR = 400

HFSR = 40000000

DFSR = b

AFSR = 0

But what this means to me? How can i locate the cause for the fault?

I'm new with the STM32 and would appreciate your assistance.

Best regards

Tom

Posted on September 14, 2012 at 16:17

Hi,

I had exactly the same problem. Hard faultoccurredwhen I at the same time declared and initialized local variable in a function. If I used a global variable or declare the local variable as static everything was ok.

The hard fault was caused at local variable initialization by unknown instruction.

I found the solution in

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/DispForm.aspx?ID=2593

thread.

After I added the flags

cortex-m4 -mthumb to LDFLAGS varialbe (linker flags) there were no more hard faults. I am using stm32f407xxmicro-controllerand arm-none-eabi toolchain.

Regards,

Matic

Posted on August 22, 2013 at 16:13

Hi Joseph

I have a big problem with the hard fault STM32F103RTB7

I made a lot of PCIs, five works well and seventeen don't work always with hard fault, but all PCI go to hardfault in differents moments.

I read this topic and I included the hard fault code, see bellow

R0 = 0x7261485B

R1 = 0x61662064

R2 = 0x20746C75

R3 = 0x646E6168

R12 = 0x5D72656C

LR = 0x62363400

PC = 0x386638

PSR = 0x305247C0

BFAR = 0x42993B01

MMSR = 0x0

HFSR = 0x40000000

DFSR = 0xB

AFSR = 0x0

BFSR = 0x82

UFSR = 0x0

Posted on August 22, 2013 at 16:46

The date on the thread is deceptive, the May date is when the forum melted down and was reconstructed, the thread is from 2010, or perhaps 2008. We don't see Joseph here that often, but his books are certainly recommended reading.

Looks like the register data is full of ASCII? Review the stack, or have the debugger fired up to look at the actual system in failure.

The PC looks bogus, as does LR. It's going to be hard to pin-point the faulting instruction here, which is critical. As a first step you're going to want to validate that your fault routine works properly, as I'm not convinced it is. ie generate a fault at a known address.

Your Hard Faults likely occur for the same reasons everyone elses do, namely

Stack Corruption, or inadequate stack size, causing immediate or latent failure.

Read/Writes to inappropriate memory addresses.

Executing 32-bit instructions.