MSPM0G3519: Getting Hard Fault error source (how to?)

Hi Eugene,

Hard faults will cause the program to enter the hard fault handler, but that won't tell you where it occurred. The best way to do this would be to use the micro trace buffer.

Debug section from CCS Academy

How to Debug an Application Crash Using Core Trace in CCS Theia

-Matthew

What if debugger is not connected and these do happen in the field (... and they do when there are millions of devices out there)? How do you suggest they are to be handled, and root cause identified?

Just to clarify. The issue is not where it has occurred but rather what caused it.

Hi Eugene,

There are limitations within the M0 architecture that prevent us from easily identifying the cause of a hard fault. Our usual recommendation is to reset when a hard fault occurs on M0. There are some possible workarounds, but they would involve getting into the assembly code.

What else can you tell me about the context of this question?

-Matthew

Hi Matthew,

I understand that there are some limitations with M0. I would like to know what is possible for hard fault.

At minimum, it would be helpful to identify that this is MPU violation rather than anything else. If we need to debug returns from the field any extra information on the root case will help. I already have assembly pre-handler to get stack frame and some of the CPU registers. Unfortunately, I can't find any other useful register for hard fault in TRM. What else can be done? Please share example if you have one.

Regards,

Eugene

Hi Eugene,

The best thing to do here is identify the PC value, and then use that to deduce the instruction that caused the fault. Unfortunately, M0+ is limited when it comes to triaging hard faults.

We don't have any other way to identify if a hard fault was a MPU violation.

-Matthew