Hard Fault exception STMF4

[sami]

Posted on February 23, 2013 at 13:50

Hello ;

I am getting Hard Fault exception  when excutting the function arm_cfft_radix4_f32(&S,testInput ); I set the FPU on  I tried to increase the heap and stack too but I could not solve it ; could you help me to fix this please? Regards Esat #fpu-memmanage-hard-fault

[Tesla DeLorean]

Posted on February 23, 2013 at 13:56

Look at the instruction that is faulting, and the registers when it faults. Install a proper HardFaultHandler if you need to, or dig the context out of the stack.

The general cause of faults is touching memory inappropriately, executing ARM code, or executing FPU or extended instructions when the FPU is not enabled in the core. The FPU is usually enabled in SystemInit() or ResetHandler, based on a define set by the compiler as a result of the user checking/selecting ''Use FPU'' in the target or code generation selection..

[sami]

Posted on February 23, 2013 at 14:29

Thank you Clive for your fast response , but that really drive my mind crazy

After digging in the assembly I found that the main FFT function calling othwer function at the end of the function when trying to POP the stack the fualt excute here is the code 0x08002BC6 D8A9      BHI           0x08002B1C 0x08002BC8 E8BD8FF0  POP           {r4-r11,pc} where R4=0x01 R11=0x100 R15(pc)=0x08002bc8 when excuting POP the fault happens.. so any suggestion .. it seems stack problem ,right?

[Tesla DeLorean]

Posted on February 23, 2013 at 15:12

Yes, it looks like a problem on the stack, but it might not be stack size related. May be you have a local variable on the stack that is corrupted when code writes beyond it's scope. You should look carefully at what you're passing in, and perhaps park a watch window over the stack so you can observe it as the subroutine enters, and just before it leaves.

For stack sizing you'll want to look at the current usage requirements, and if those are sufficient. I would base that on code analysis, and observation, rather than just keep making it bigger.

[sami]

Posted on February 24, 2013 at 13:24 Thank you Clive ; But I still dont know why that happened. I define my variables in the  global variables , I have  assigned big variables like  floats [1200] but it should be ok for memory .. so is there a standart solution for this? Regards

[sami]

Posted on February 24, 2013 at 13:41 By the way I get now MemManage_Handler ..

[Tesla DeLorean]

Posted on February 25, 2013 at 01:25

You'll need to dig into the stack, understand if LR/PC gets corrupt across the routine.

Look at how you're initializing the S structure, and field fftLen. Is it a length supported by the routines?''

size of the FFT supported are of the lengths

[

16

,

64

,

256

,

1024

]

'' ?

http://mazsola.iit.uni-miskolc.hu/DATA/segedletek/arm/cmsis/CMSIS/Documentation/DSP/html/arm_fft_bin_example_f32_8c-example.html

[sami]

Posted on February 25, 2013 at 10:15 Hi Clive .. My input signal is 1024 and also my FFT length is 1024 ; Also I noticed something wrong there in the FFT I excpect the result of the FFT to give me the highest energy at about 10Hz but it gives about 200Hz I will try more and I will tell the results ; but I still did not understand the Faults issue ; for example how the compiler need to write some routines over the other? or why the compiler need to put some variables over other defines variables ? I think the compiler must fix this for the programmer . I dont know the case of ARM I am really new ; but with PIC and PIC32 I never get these fualts before because the compiler manage this for us . And right now I am using a very expensive KEIL which must manage this too ; I think . Thank Clive . Regards

[Tesla DeLorean]

Posted on February 25, 2013 at 16:43

I can only see one line of your code. I'm going to suppose the problem is caused by how the structure is set up, and the crash is merely a result of the CPU doing what you've told it to do.

It doesn't matter if the compiler is free, or cost $10K+, they are equally capable of compiling bad code. If the code is syntactically correct you'll need to dig into why it's not functioning as you expect. Compilers are decidedly poor at identifying algorithmic failures.

[arnaljl2]

Posted on March 04, 2013 at 03:37

Interesting.

One of my collegues ran into a similar problem last week. The memory manager fault exception would fire as soon as his program encountered the first VPUSH opcode, from the only function existing which would declare floats as local variables. I wonder how he solved this though...if he did. We still haven't used the FPU in our other projects, so I cannot say. Still...