HardFault_Handler headache

[ASSAAD.ASSAAD]

Posted on July 30, 2015 at 10:36

Hello all ;

I have an old working project that we use  the function : arm_cfft_radix4_f32(&S, testInput); where testInput is a float array in the RAM . we need to add some function for the project we added more extra errays to the RAM ; where the RAM of this processor stm32f407 is up to 192k ; we only use 84k byte  but the software is start to stuck in the HardFault_Handler! we increased the heap and the stack for 0x0000 fff8  but no way still stuck ; when I delete the new defined arrays it work but I need to add this big array . I have been debugging for 3 days we noticed the program get fault in the routine arm_cfft_radix4_f32(&S, testInput); could you suggest a solution for this problem , Thank you in advanced

[stm32forum]

Posted on July 30, 2015 at 12:39

Add Joseph Yiu his hard fault handler to get some more info about the fault.

http://blog.frankvh.com/2011/12/07/cortex-m3-m4-hard-fault-handler/

[Tesla DeLorean]

Posted on July 30, 2015 at 19:20

A Hard Fault Handler should be able to tell you where the fault is occurring and the processor registers when it fails.

Increasing stack and heap sizes fixes a specific class of problems, yours seems to relate to the structure/configuration of what you're passing into the function, and perhaps a miss-interpretation on your part of the size/dimension fields. ie physical sizes of the input/output structures.You'd want to carefully review the documentation for the functions being used, along with any examples where the functions are being used successfully.It's going to be hard to debug remotely unless you provide a significantly better context for which the function being called.

[jpeacock]

Posted on July 30, 2015 at 22:14

Chances are you are exceeding a memory boundary when you add the extra arrays.  Look at the differences in your linker map between working and non-working images, especially near the end of flash and RAM boundaries.

Do you reference those new arrays with pointers?  Are the pointers valid in all cases? Are you allocating memory from the heap?  Your code may statically fit with the new memory requirements but after starting it can overflow in a call to malloc(), not directly but by returning an invalid pointer used later on.  Do you always check for errors after every malloc() call?   Jack Peacock

[ASSAAD.ASSAAD]

Posted on July 31, 2015 at 14:33

Thank you all for support ;

The prototype of the routine that cause the problem is

void arm_cfft_radix4_f32 ( const

http://my-arm-lib.googlecode.com/hg-history/227673ec8f5963989280e867ece373fbdf170c55/CMSIS/Documentation/DSP_Lib/html/structarm__cfft__radix4__instance__f32.html

*  S,

http://my-arm-lib.googlecode.com/hg-history/227673ec8f5963989280e867ece373fbdf170c55/CMSIS/Documentation/DSP_Lib/html/arm__math_8h.html#a4611b605e45ab401f02cab15c5e38715

*  pSrc 

)

I use it like this : arm_cfft_radix4_f32(&S, testInput); where testInput is  : float testInput[1024] ; for malloc() ; I don't use it ; where do you suggest is to do that ? noting that more than half of the RAM is not used . Thank you

[Tesla DeLorean]

Posted on July 31, 2015 at 15:34

Ok, but how do you configure and initialize ''S''

You need to step back and look at what's occurring before you call the function, and if what you're handing it is suitable. You need to look at exactly what the Hard Fault is telling you about the offending memory, registers and instructions.

[ASSAAD.ASSAAD]

Posted on July 31, 2015 at 17:14

Hi Clive ;

here the code before I call the routine ;

  status = ARM_MATH_SUCCESS; 

 /* Initialize the CFFT/CIFFT module */   status = arm_cfft_radix4_init_f32(&S, fftSize,             ifftFlag, doBitReverse);    /* Process the data through the CFFT/CIFFT module */  arm_cfft_radix4_f32(&S, testInput);   where S is

*S points to an instance of the floating-point CFFT/CIFFT structure.

and I can not access it

[Tesla DeLorean]

Posted on July 31, 2015 at 18:16

You're going to be spending days on this unless you get a lot more detailed in the memory locations, and sizes, of the parameters and buffer, and how those related to the registers/state when it faults...

The debugger should give you sufficient visibility into what's going on in memory and with the processor. You can perhaps help that process by printing out to the debug console various data points you can extract during the initialization, and prior to calling the function. And in situations it doesn't Hard Fault, what comes back.