heap and stack crash issue.

[mrandreas]

Hi,

I’m currently troubleshooting a crash - hardfault that occurs after a day runtime.  I have a communication interface and a SPI interface reading continually an external device. When only the communication is activated the runtime is longer.

-I have debugged the issue with ETM trace and the last executed code is not doing anything “illegal”. 
-I have increased heap to 0x2000. I’m however not doing “new” objects onto the heap runtime (only during init) and I’m not using malloc. I cannot be sure what’s done in third party library.

-I have increased the stack to 0x1800. The build htm output states maximum stack size 1048 + untraceable function pointers.

I’m using Keil Ui with ulink pro.

1) a) If it's an heap issue could this cause an hardfault or only memfault?

    b) How can I debug heap issues?

    c) Is there a way to monitor the methods pushing to heap?

    d) Is it possible to clear the heap safe way?

2) b) Could stack issue cause an hardfault?

    a) How can I debug stack issues?

    c) I didn’t think that the stack could go full in this way, after a day work with the same chain being called, correct?

3 What other things can cause hardfault when the last executed code is totally ok?

thanks

Andreas

[mrandreas]

Hi Thomas,

The Fault Report states that it is an IBUSERR, the hard fault is forced and Debug fault states BKPT.

  The reson for an IBUSERR is;

a) Branch to invalid memory regions for example caused by incorrect function pointers.

b) Invalid return due to corrupted stack pointer or stack content.

c) Incorrect entry in the exception vector table.

Hm... how can fix it?

thanks!

Andreas

[thomasgrieger]

Hi Andreas,

do you know at which adress (PC) the exception occurs?

To succeed in hardfault debugging we had to add a hardfault handler in which the exception frame from the stack is read (examples for this can be found via google, search for "ARM cortex hardfault debug"). From this we got the fault address and started debugging on asm level.

I learned that it is better to set the breakpoint some asm instructions in front of the reported address as sometimes the reported address is up to four instructions after the real problem.

Best regards,

Thomas

[thomasgrieger]

Hi Andreas,

did you check the registers in the system control block? They contain much information regarding exceptions like the hardfault.

Their position and content is described in a generic used guide from ARM.

It is most likely that the hardfault is a "forced" hardfault which means it is called because the real fault (bus fault, memory manage fault, ...) cannot be serviced.

Hope this helps to track it down,

Thomas