How to perform runtime error checking on Cortex-M devices

Posted by Magnus Unemyr on Dec 18, 2015 9:17:47 AM

Embedded development is difficult, and embedded debugging may be even more so. Thus it is important to use the best tools in your toolbox. It appears to me that many Cortex-M developers are not fully aware of the powerful debug capabilities included in their Cortex-M based microcontrollers, like STM32, Kinetis, LPC or EFM32. This is valid for the super-useful Serial Wire Viewer (SWV) real-time event and data tracing capabilities, but perhaps even more so, the hard fault crash analyzis capabilities integrated in the Cortex-M core.

For example, our Atollic TrueSTUDIO debugger includes a hard fault crash analyzer, which detects hard-to-find runtime errors during full-speed target execution. Perhaps your system crashes a couple of times every week due to a sensor reading out-of-range values, causing a pointer error to bring the CPU to a hard fault due to accessing illegal memory or on misaligned address  boundaries.  Or your code performs a division by zero, once a week. These types of problems can be really hard to find and solve.


The hard fault crash analyzer can find these types of problems in a couple of seconds with no work on your part. It is non-intrusive and works without code instrumentation in order to preserve real-time behavior, which is also important because the compiler do not generate different machine code during the bug hunting session. Furthermore, the hard fault crash analyzer is a standard feature of TrueSTUDIO Pro, and works with ARM Cortex-M devices from any vendor. In terms of JTAG probes, it works with both the SEGGER J-Link and ST-LINK from STMicroelectronics.

Typical problems detected by the hard fault crash analyzer are division by zero errors, accessing invalid memory locations or accessing memory locations on misaligned boundaries. The hard fault crash analyzer significantly aids embedded developers to quickly understand why the system has crashed, thus improving productivity. The crash analyzer not only tells you WHY the CPU crashed, but also WHERE in the code, and under WHAT circumstances.

When a hard fault has occurred - say a division by zero -  the code line where the system crash appeared can be displayed in the source code editor and the disassembly view with just a mouse-click. Faults are categorized broadly into bus, usage and memory faults. Bus faults occurs when an invalid access attempt is made across the bus, either of a peripheral or memory location. Usage faults are the result of illegal instructions or other program errors. Memory errors can include attempts to access an illegal location or rule violations of the memory protection unit (MPU).

To further aid fault analysis, an exception stack frame visualization option provides a snapshot of MCU register values at the time of the crash. Isolating the fault to an individual instruction allows the developer to reconstruct the MCU registers to the condition they were when the faulty instruction was executed.

By using the hard fault crash analyzis capabilities of your Cortex-M device, you can easily detect and locate many hard-to-find runtime errors. In case you want to learn more, read our whitepaper on Cortex-M hard fault crash analyzis here:

Read our hard fault crash analysis whitepaper

Unless you already use Serial Wire Viewer event- and data tracing, I strongly recommend you study these powerful and time saving debug techniques too. You can learn more on SWV event- and data tracing here:

Read our SWV event and data tracing whitepaper!


Topics: ARM Cortex, Debugging, Atollic TrueSTUDIO, SEGGER J-Link, ST-LINK