STRANGE HardFault_Handler in STM32F407

[sami]

Posted on October 31, 2013 at 20:49

Hi ;

I have been trying to solve it with 4 days but I could not ! I have an old Project that I need to fix some bugs I have a bufffer defined as : float volt[1125]; in the new version I have to add pace_volt[18000]// 4khz sample. when I write to volt any value ;   to all buffer all some of it in my code I have to update volt by :

   for(i=0;i<1123;i++)

   {       volt[i]=pace_volt[i];

   }

the function   /* Process the data through the CFFT/CIFFT module */  arm_cfft_radix4_f32(&S, testInput); give an handfualt_handler !! when I dont write to volt it is ok .. but I need to write to volt !! Could you guide me please to solve it? Note: FPU is enabled 100% . Thank you in advanced

[sami]

Posted on October 31, 2013 at 20:59

I noticed that its not related to the buffer volt[]; after I added the big buffer pace_volt[] the function 

 /* Process the data through the CFFT/CIFFT module */  arm_cfft_radix4_f32(&S, testInput); gives the HardFault_Handler issue .

[chen]

Posted on November 01, 2013 at 12:07

Hi

You have not said what hard fault it is - which suggests you have not investigated it properly. The ST data sheets will not tell you anything about the Hardfaults - you need to download the ARM core data sheets (from ARM). Once you have these - you can work out which hard fault it is. This will give you a clue as to what is causing the fault. By the way, do you realise the 2 arrays you have created takes 11-12Kbyte? Also, if the arrays are local variables in a function - they only exist when the function is running. That requires a stack of at least 11-12Kbyte - quite large for an embedded application! If you want the circular buffers to be there outside of the function running - they have to be declared as static

[sami]

Posted on November 01, 2013 at 13:49

Thank you ;

the buffers are globale variables ; and they are more much that 12kbyte . so is there a restriction for that ? still not work .

[frankmeyer9]

Posted on November 01, 2013 at 13:50

Also, if the arrays are local variables in a function - they only exist when the function is running.

That requires a stack of at least 11-12Kbyte - quite large for an embedded application! I hope you didn't do that ... You can inspect the map file, and check which variables are neighboring the stack. If they are the ones affected, that would be indicative of stack size issues. Generally, seemingly 'random' crashes are often caused by stack overflows. But that's rather easy to find out, and correct. Another common source of random trouble are runtime-calculated array indices which are out-of-bound.

[Tesla DeLorean]

Posted on November 01, 2013 at 14:37

''Let's assume your problems are like most others, hard faults tend to catch gross errors, not subtle ones of logic or algorithms. As such  they should be a lot easier to pin down and resolve. You need to understand where in your code they occurred, and what you were doing at the time. The predominant cause of hard faults are broken/invalid pointers, out of scope accesses, stack corruption, and the stack and heap colliding with each other. These can be tracked with asserts, or validation of structures at key points or periodically, adding guard zones and checking them. Expect the points of failure to be similar, either occurring at the same places (ie use of particular subroutines, or code), or while doing the same things (ie returning from a subroutine, use of particular pointers).''

Identify SPECIFICALLY where the code is failing, so far you've identified a subroutine, the processor is no doubt pointing at a specific instruction, and register context. I'd assume based on the single line, that either the structure is not set up correctly, or the parameters are incorrect. Does the FFT expect a power-of-two size table? Check the documentation more thoroughly to understand the limits/constraints of the functions being called.