And here it is again: a Hard Fault exception raised by the ARM Cortex-M0+ on my Freedom board:
A reason for hard faults are for example dereferencing a NULL pointer. The issue with the ARM Cortex hard fault exception stack is: it is not easy to find out where in the code the problem is.I have created a Processor Expert component to help me to find the location of such an exception. With the Eclipse based CodeWarrior for MCU10.3 there is another way: Trace with the MTB (Micro Trace Buffer)!
💡 The Trace functionality was not part of the MCU10.3 beta, but is present in the final 10.3 release.
Micro Trace Buffer
The name MTB (Micro Trace Buffer) already indicates what is behind this tracing method: ARM has added support in the silicon which logs trace information in a memory buffer in RAM. If configured properly, a tool (like CodeWarrior debugger) will read that buffer in RAM and processes the information. The good thing with MTB is: the location in RAM and the size is user configurable: it is simply a buffer somewhere in the RAM. Using MTB Trace does not need any special hardware: a normal debug connection like OpenSDA is good enough. Of course anything faster than OpenSDA helps speeding up things, so using a higher performance run control device makes a lot of sense (not only for Trace).
While the Processor Expert HardFault component needs Processor Expert, using Trace works of course for any project.
💡 If you are migrating a MCU10.3 beta project to MCU10.3 final for Trace, you need to do the steps outlined in Migrating Kinetis-L Projects.
Trace is configured in the ‘Trace and Profile’ tab inside the Debug/Launch configuration. It is enabled with the ‘Enable Trace and Profile’ check box:
This will a reminder dialog that I need to rebuild my project:
What happens with enabling trace
Wondering what is behind enabling that trace option, and why I need to rebuild my project?
Rebuild is necessary because it has added/changed a define in my preprocessor settings:
This symbol is used in the sa_mbt.c file within my project:
This mtb_buf is added to the m_data section in my linker file:
I do not need to do anything for the things above: it is configured automatically by CodeWarrior.
Tracing with Debug
After rebuilding my application, I start debugging as usual. The difference is that there are two more buttons in my Debug view:
The first button is to start/stop trace collection, and the other is to reset the trace data.
Additionally there is an extra view: the Software Analysis view:
💡 The view is added with the menu Window > Show View > Other > Software Analysis
After I have run into my Hard_Fault Exception, I click on the ‘Trace’ link:
This opens the a view showing the trace collected:
To see what happened last, I need to go to the end of the list:
The MTB trace does not record every instruction: it records ‘change of flow’ to reduce the memory needed.
Linked with Source
While the ‘raw’ trace data already gives an idea what happened in my application, there is a nice feature which might not be obvious the first time: I can click into the trace data or use the buttons in the trace view to go to the next or previous trace item in the list. The cool thing is that it links to the source file and puts a marker there:
💡 To go back and forward in trace and have it follow in the source, it is best to have the two views side by side arranged as in my above screen shot.
Ok, now I clearly see what has caused my exception: the pointer ‘p’ in my code has not been initialized properly. Finding the issue was not that easy, but the fix for it is :-).
Happy Tracing 🙂