How to debug hard fault handler exceptions?

[danielblesener9]

Posted on March 26, 2013 at 02:34

Hey all - thanks for taking your time to help

I have no idea how to track down whats going on. Opening debug explore seems logical - but I have no idea what to do with the address faults. I am not sure what they mean.

Is there a systematic way to solve these problems, or is it just experience? I have no clue what to do with any hard faults/mem faults/bus faults. 

If you don't mind taking a moment, could you explain how to methodically solve these problems? I am fairly new to the programming world. 

Last address in the hard fault status register was = 0x40000000

The call stack reads SP: 2000FD08h

Attached is a file showing the fault reporting window

Any advice?

[flyer31]

Posted on March 26, 2013 at 11:32

If you mean STM32F4: You should include a stm32f4xx_it_traps.c in oyur application (as you find the trap interrupts in all the common examples for STM32F4 ... . In the traps you should place a breakpoint instruction.

Then you need to have a look at the programming manual (or ARM V7 TRM) and the registers in SCB - there you get hints what happend. Mostly it is memory alignment stuff. Take special care that you best DO NOT allow your compiler to use 32bit access at 16 bit addresses - this can be activated by some SCB bit to work, but anyway it is not efficient to do this in the core. In Keil you need to specify ''--no_unaligned_access'' under ''Misc Controls'' on Target page ''C/C++''. Further hints you will find, if you look for ''align'' in the ARM TRM or the STM32F4 Programming manual.

[danielblesener9]

Posted on March 26, 2013 at 13:14

Sorry, should have mentioned but I am using a STM32F103ZET6. 

[Tesla DeLorean]

Posted on March 26, 2013 at 13:27

Well the processor stacks some of it's context, other data remains in current registers, and within the core. When it faults it does very specific things, and in order to determine what was going on you need to wind that back. Knowing where the code faulted, and the registers at the time you can make some educated guess about why that might have occurred. If you don't understand the flow of your code you can add checkpoints to confirm addresses or variables. A grasp of assembler will be helpful.

You need to review the TRM (Technical Reference Manual) for the core, along with Joseph Yiu's book on the Cortex-M3. Look at some of his Hard Fault Handler code examples.

[danielblesener9]

Posted on March 28, 2013 at 00:16

Ok, I bought the book you mentioned, did some reading and debugging. I found that the error is coming not when I add certain functions to my main loop, but when I add any after a certain amount. It seems like my stack is filling up?

I know there is a way to expand the stack space, can anyone explain how this is done? I do not see it in a setting and did not get a straight answer searching online. Thanks. (I am not use the discovery)

[Tesla DeLorean]

Posted on March 28, 2013 at 00:25

With Keil the stack size is specified toward the front of the startup_stm32f1xx_xx.s files, it's usually pretty small. If you have large local/auto variable allocations this can push the stack pointer down to the point where it punches into the heap or static allocations.

Other things which hog the stack are printf/scanf. With GNU/GCC the stack tends to be parked high in memory, so somewhat less of an issue than Keil where it floats just above the heap. A technique commonly used to determine stack utilisation is the fill it with a marker character (your initials, whatever) and then observe it in a memory watch window, or have a routine to probed it's current maximal depth.

[danielblesener9]

Posted on March 28, 2013 at 19:54

Thanks for the input. I will try to reduce the load to the stack later, for now I just need to increase its size. I use Ride7, not Keil. Any ideas how to increase stack size on here? I have been looking and do not see a simply solution provided, though it has to be somewhere.

I see the file startup_stm32f10x_xx.s, but cannot seem to open it to change anything. When searching online at looking thru this file, I do not see.Does anybody know how to change the stack size for the stm32F1 using Ride7????

[danielblesener9]

Posted on March 28, 2013 at 22:27

I found these pieces of code...would they work to change the stack size??? Anyone used these before?

/* ###################  Compiler specific Intrinsics  ########################### */#if defined ( __CC_ARM   ) /*------------------RealView Compiler -----------------*//* ARM armcc specific functions *//** * @brief  Return the Process Stack Pointer * * @return ProcessStackPointer * * Return the actual process stack pointer */__ASM uint32_t __get_PSP(void){  mrs r0, psp  bx lr}/** * @brief  Set the Process Stack Pointer * * @param  topOfProcStack  Process Stack Pointer * * Assign the value ProcessStackPointer to the MSP  * (process stack pointer) Cortex processor register */__ASM void __set_PSP(uint32_t topOfProcStack){  msr psp, r0  bx lr}/** * @brief  Return the Main Stack Pointer * * @return Main Stack Pointer * * Return the current value of the MSP (main stack pointer) * Cortex processor register */__ASM uint32_t __get_MSP(void){  mrs r0, msp  bx lr}/** * @brief  Set the Main Stack Pointer * * @param  topOfMainStack  Main Stack Pointer * * Assign the value mainStackPointer to the MSP  * (main stack pointer) Cortex processor register */__ASM void __set_MSP(uint32_t mainStackPointer){  msr msp, r0  bx lr}

[Tesla DeLorean]

Posted on March 29, 2013 at 01:27

Those are more to change the current register settings, and for Keil/RealView

I suspect the place to look on GNU/GCC chains would be the linker scripts (.ld) or equivalents built by the IDE.

[Fristedt.Jan]

Posted on March 31, 2013 at 15:14

In CoIDE the stack is defined in startup_stm32f4xx.s for STM32F4. For Atollic (also GCC based) it used to be done in the same way. I don't know it it's still the same.

You should also be aware that byte variables on the stack are 32 bits using four times as much memory than expected Similar with 16 bit variables.