hard fault exception

[satyajit]

Posted on June 09, 2014 at 11:57

I am generating optimsed code using simulink coder for LMS filter using stm32f4VG407 discovery board,KEIL MDK-ARM, but upon single conversion of signal through ADC , it is stopping at hardfault handler. fault report:

MM_FAULT_STAT:0x00BUS_FAULT_STAT:0x04 i.e. IMPRECISERR IS HIGHUSG_FAULT_STAT:0x000HARD_FAULT_STAT:0x4000000 i.e.FORCED IS HIGHDBG_FAULT_STAT:0x00000001 i.e. HALTED IS HIGH

I am using Matlab 2013b & MDK_ARM 4.74

please help me how to get rid of this. #discovery #stm32f4 #hard-fault-exception #simulink-code-generate

[Tesla DeLorean]

Posted on June 09, 2014 at 20:57

Like most Hard Faults you're going to want to start by looking at the assembler code around the faulting instruction, and the register contents.You'd want to review the stack content and be confident it's big enough. Joseph Yiu has published some very good examples of a Hard Fault handler that provides a lot of information you can use to pin point the failure.

[frankmeyer9]

Posted on June 10, 2014 at 11:35

I agree with clive, try to dissect the fault case.

Looking at the errors, it seems you got a imprecise bus fault followed by a hardfault (probably because the former exception is not handled). My guess: your problem is a stack overflow, caused by the ressource-wasting code emanated by Matlab (as seen in several similiar threads here before).

[satyajit]

Posted on June 19, 2014 at 10:22

I am still struck in hard fault exception

after running 36 times(i.e 36 adc conversions & hence 36 outputs at dac) the program is getting into hard fault exception from within this for loop:

/* Update weights for the next input sample

*/ j_0 = 0; for (j = (int32_T)*startIdx; j < wLen; j++) { prodMuErrX = accWtU * xBuf[j]; prodMuErrX += mul_s32_s32_s32_sr30(leakFac, wBuf[j_0]); wBuf[j_0] = prodMuErrX; j_0++; }

I even checked changing stack size but the number of conversions (i.e 36 ) was independent of change in stack size.

please find attachment

Can somebody please help me regarding this?

________________ Attachments : Untitled.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1Aj&d=%2Fa%2F0X0000000bjg%2FxGI_iglFpqyrpExOVtthJPYlqw20GQ.YCCfZnAwQTJs&asPdf=false

[frankmeyer9]

Posted on June 19, 2014 at 12:10

Check your memory usage, especially in interrupt handlers and in regard to DMA.

Using stack allocated memory for any of this purposes does not work out well, even if the stack is not overflowing.

[Tesla DeLorean]

Posted on June 19, 2014 at 14:22

You haven't really refined the search much. Again you might want to get a fault handler to point at a specific instruction.

You also haven't provided much context, I would look at the indexes into the arrays, as you are likely exceeding the bounds. Step the assembler code, and review the instruction, and registers at the fault. If you have a serial port or debug channel, you could print out diagnostic information in and around the loop rather than breakpointing it.

[Danish1]

Posted on June 19, 2014 at 18:59

I am always suspicious when I see casts.

What type of pointer is startIdx? How strongly do you know that its value, and what it points to are sensible? If startIdx is pointing to something that is not int32_T then what precisely do you expect to happen? If *startIdx evaluates negative then you will access before the start of xBuf, and loop more than wLen times. You might want to use a circular buffer for some of this code - but I don't see anything that will cause your pointer to wrap when it goes off the end of the buffer. Hope this helps, Danish