HardFault

[jaspervandenakker]

Posted on March 22, 2013 at 21:09

Hello,

I have a problem which i cannot resolve.

My first code, a DCF77 receiver which update my RTC once a day runs fine without any problems.

Now, i have added a new function to calculate the Sunrise or Sunset time for my location (Lat, Lon)

In that function, another function is called to calculate someting. The first time this function is called, this function will be executed and works fine. the second time, i get a HardFault and i can not find out how.

Sometimes, when it is running in Debugmode and i step slowly thru my code, it executes all my functions without any HardFault.

When i comment the function call my program works fine. Can anybody help me?

I have attached a screenshot of my debugger. As you can see it stuck at __Float64_mul

I guess that it has something to do with the float64. But this function is executed earlier and does not cause a hard fault

[Tesla DeLorean]

Posted on March 22, 2013 at 22:14

Get a decent Hard Fault handler and know what instruction is actually faulting. Joseph Yiu has published a good one, a while(1) loop is useless unless you want to dig through the stacks and core registers to determine the faulting context.

Using scanf/printf? do you have an adequate stack allocation?

[jaspervandenakker]

Posted on March 22, 2013 at 22:34

i've used a HardFault Handler. But it does not run the whole function. The result of ALL stacked registers is 0xfefefefe ???

And the strange thing is that when i set the optimization up to 3, the HardFault is gone :(

[Tesla DeLorean]

Posted on March 22, 2013 at 23:33

That doesn't sound right, but whatever.

The optimization issue suggests again that something there was muddling with the stack, now does so with registers instead. Look at what local/automatic variables you are using, if there is adequate space, or if they can be accessed beyond bounds. Again identifying the faulting instruction and the registers/state at the time narrows the issue.

[jaspervandenakker]

Posted on March 26, 2013 at 10:36

Still i did not get the hardfault handler working properly.

I think that the problem has something to do with the math library. Since I try to calculate the sunset and sunrise times (downloaded from internet) with some sin and cos functions the software gets into the hardfault handler. I've attached my code, it is a bit messy, but without the sunset call in the main, my code works fine. :(

It would be nice if someone can tell me what i'm doing wrong.

(code is in temperature template of the firmware pack/projects)

________________

Attachments :

STM32L_Discovery_Firmware_Pack_V1.0.2.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0qF&d=%2Fa%2F0X0000000bjW%2FOiXuadBIqCnTM3o3OdX0XSMb.z6cwY6m3ag97252LDM&asPdf=false

[frankmeyer9]

Posted on March 26, 2013 at 14:47

Guessing from the access dates of the project files, I would say you use CrossWorks.

That  leads me to assume that you have a stacksize problem. Crossworks is notorious for having a really small default stack of 128 byte. With your generous usage of double variables, that could easily explain your hardfaults.

[jaspervandenakker]

Posted on March 26, 2013 at 16:58

Thank you for your reply. And yes, I am using Crossworks. I was forgotten to tell....

The Crossworks issue about the stack size is also what I have found, These are my stack settings:

Heap Size: 1024 bytes

Stack Size (Abort Mode) : 0 bytes

Stack Size (FIQ Mode): 0 bytes

Stack Size (IRQ Mode): 0 bytes

Stack Size (Supervisor Mode): 0 bytes

Stack Size (Undefined Mode): 0 bytes

Stack Size (User/System Mode): 1024 bytes

What do I have to change in these settings. It seems to be enough, right?

I also tested the same code in the Keil for ARM uVision, and without any hardfault error.

[frankmeyer9]

Posted on March 26, 2013 at 19:53

Heap Size: 1024 bytes

 

Stack Size (Abort Mode) : 0 bytes

 

Stack Size (FIQ Mode): 0 bytes

 

Stack Size (IRQ Mode): 0 bytes

 

Stack Size (Supervisor Mode): 0 bytes

 

Stack Size (Undefined Mode): 0 bytes

 

Stack Size (User/System Mode): 1024 bytes

 

Are you having the right target ? I'm seeing just:

    Heap Size: 128 bytes

    Main Stack Size : 1024 bytes

    Process Stack Size : 0 bytes

(for a STM32F4 project as example).

Did you try to single step to the point of failure ?

I did not yet have any floating point related issues with Crossworks.

However, I only tried floating point with the F4, and then only float (no double).

Although your double-spiked code is a resource hog, it should work nonetheless, using the ''soft'' version of the math lib. That even works on 8-bit MCU's.

[jaspervandenakker]

Posted on March 26, 2013 at 20:09

I use the STM32L-Discovery board. The target processor is set to STM32L152RB in my Crossworks project settings. So that should be ok, right?

Yes, i dit tried the single step to the point of failure, but there is no reason that is should go wrong. When I comment the part where it's going wrong and do the single step again, it's going to fail again in another part of the code. So it still look like stack problems.

How can i use the soft math lib? Or do i have to set the soft FP flags for the compiler as you should do in eclipse...?

[jaspervandenakker]

Posted on March 26, 2013 at 20:54

OOPS!!!

I have found another set of stack options and those settings are the same as you describe.

And only 3 parameters instead of 7.....

Now I have changed these into 1024 and 2048 and it runs without any error :)

Many thanks for helping me...

[Tesla DeLorean]

Posted on March 26, 2013 at 20:54

FPU instructions can hard fault on the STM32F4 if the math unit isn't enabled, this should not be an issue for you.

Commenting out code isn't going to help here. You need to clearly identify the failing assembler instructions, and the registers at the fault. Depending on the type of failure may also want to dig into the stack. If the printf() code doesn't have support in you tool chain you could always break point the hard fault handler and walk through it.