HardFault_Handler : how to capture them and debug the faults in SCB->CFSR

[karthikainala]

Posted on March 22, 2014 at 19:06

how can we capture the faults? i read that these memmanage,bus and usage faults can be captured from SCB->CFSR(configurable fault status register) 

are there any sample pgms to deal with them and also do they occur due to the fault in the circuitry in which stm32 is connected ie due to short and voltage fluctuations etc. 

i am facing such faults during usart comm, but i dont get the faults consistently.

the chip is stm32l152xb

Thanks

#stm32l #memmanage-hard-fault #luck-not-design #stml #hard-fault #cfsr #stm32-scb #handler-hardfault #handler-hardfault

[Tesla DeLorean]

Posted on March 23, 2014 at 00:21

Google : Joseph Yiu Hard Fault Handler

Faults are almost always because the programmer screwed up.

Programmed the clocks, flash wait states wrong. Inadequate stack size. Read/Writing to invalid pointers.

[Andrew Neil]

Posted on March 23, 2014 at 01:09

http://community.arm.com/thread/5414

[karthikainala]

Posted on March 23, 2014 at 11:15

thank you for your replies,

but i have a specific problem, I have two similar st boards and the code runs successfully on one board and it shows faults ie goes to hardfault when tested on the 2nd board, i read that hardfaults has nothing to do with hardware its only due to some mem corruptions and bad pointers etc..

Does hardfault bring up any hardware related faults like unstable clock or voltage fluctuations etc?

[Tesla DeLorean]

Posted on March 23, 2014 at 12:57

I'm sure it's possible for external issues to cause Hard Faults, mainly as secondary effects.

If you think it's a supply issue, put it on a bench supply.

Either way Hard Faults tend to show up gross failures, you need to get a handle on what assembler instructions are faulting, what the registers are when this occurs, and the conditions that precipitated them. Look for patterns with the failures.

So far you've told me twice you think it's power or clocks, but really offered no information or experimental test data or processes by which you've determined or proved that.

If you think it's shorts on your board, inspect it better, and get a larger sample.

[Andrew Neil]

Posted on March 23, 2014 at 20:10

''I have two similar st boards and the code runs successfully on one board and it shows faults ie goes to hardfault when tested on the 2nd board''

So look carefully at the difference between the 2 boards!

As clive1 says, it's rather unlikely that hardware problems are directly causing Hard Faults.

More likely, your have some thing(s) marginal - which you just manage to get away with on one board, but get bitten by on the other.

To put it another way, your code is working by luck rather than design on the one board, and your luck runs out on the other...

Possibitlities could include marginal stack size, uninitialised variables, bad pointers, etc, etc.

Use the links I cited to help you find out where exactly in your code the Hard Fault(s) is/are occuring - then work back to see what's causing them...

[karthikainala]

Posted on March 25, 2014 at 11:23

i am using freertos and created 3 tasks, but i get hardfaults inconsistently but i cant capture them always as in the fig above i got memmanang and busfault but i cant get them in the handlers even though i set breakpoints to debug the source of the fault.

[stm322399]

Posted on March 25, 2014 at 11:55

Let me try a guess: you got IBUSERR because of the MCU jumping somewhere to run code but there is no memory ?

How could this happen ? Easy: you corrupted stack and some function return (reading LR from stack) simply returns somewhere where there is no memory.

This guess is based on my experience with FreeRTOS, that definitively set default stack size too small (256 or 512). A simple call to a printf may require up to 2Ko of stack (GNU eabi from codeSourcery). I guess IAR have better (say smaller) implementation of printf, try to use the smallest version of library compatible with your need (example: no float, no wide char).

[karthikainala]

Posted on March 25, 2014 at 18:04

but the execution doesnt stop at breakpoints of the respective handlers is it because the fault address of the above errors is not written in BFAR and MMAR.

about stack, while creating tasks i am multiplying the configMINIMAL_STACK_SIZE with the num, to allocate stack to tasks. also sometimes the execution stops @ prvTaskExitError() do you know how to debug this?

[stm322399]

Posted on March 25, 2014 at 18:20

I guess that there is no chance that MemManage and BusFault handler trigger if they haven't been activated properly (show us SHCSR value).

HFSR says it has forced to HardFault, it's certainly because other handler are simply not activated.

Then we finally end in HardFault, with IACCVIOL and IBUSERR set, it clearly that code had jumped in the void.

The breakpoint in HardFault handler is set at the end, it is possible that the very own code of this handler escalate for more errors. Place the breakpoint at the entry of that handler (and pray for IAR debugger to set the breakpoint at the very first instruction and not after any stack accessing instruction or whatever other instruction).