S32K116 Hardfault reset

[joseponc]

Hi.

I'm woking on a project in which I use UART to communicate with an LMM on the S32K116. I have an interface which translates a defined structure (that contains LMM-specific commands) to an array which is sent to the Uart_Send function from the S32DS driver examples.

While debugging, it seems like the software, when it receives the structure with the data, performs the memcpy function, I don't know why.

At some point, after we succesfully send a couple of messages correctly, the microcontroller resets. I tried to debug what reset was triggered, and found out it was a hardfault reset.

Checking the EmbSys Registers, I could confirm in the Reset Control Module that this reset was software-caused.

Trying to debug further, I got the following message after calling my function which parses the structure into the array that is sent by the Uart_Send function. Keep in mind that, by this point, the software has successfully sent ~100 messages without any issues:

It was thanks to this message that I could see how memcpy was somehow called everytime I called my structure parser function, and it becomes harder to understand how come this error didn't show up when sending the previous ~100 messages but this specific one triggers the error. 

Keep in mind that every message is the same. I don't even use different variables. The only thing that distinguishes one message from another is the data field. They have the same message length and same LMM-specific fields. (total message length is 21 bytes)

How can I know/debug the root cause of a hardfault error that ends up resetting my microcontroller?

Why is memcpy being called by no apparent reason (since it's not called anywhere in the code) and, even stranger, why is it "not being found" after ~100 messages have been succesfully sent?

[Alexis_A]

Hello [email protected]‌,

Would it be possible to share a code where I could reproduce this issue? 

Best Regards,

Alexis Andalon

[joseponc]

Hi nxf46116,

I found the bug in my code which was causing the issue, but I left the question open since I thought I would be useful to know if there was a way to track which memory address was overflowing and causing a hardfault reset.

So, I believe there is not a way to directly know that information, right?

Thank you for your time

Regards, Jose.

[Alexis_A · Accepted solution]

Hello [email protected]‌,

The best way to track where the code got stuck is to check the debug tab and see where the hard fault was triggered following the execution in the thread.

Best Regards,

Alexis Andalon