Easily solve runtime errors using the hard fault crash analyzis capabilities of Cortex-M

Posted by Magnus Unemyr on Jan 29, 2015 11:06:00 AM



I think 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 boundaries. This type 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, works without code instrumentation in order to preserve real-time behavior, is a standard feature of TrueSTUDIO Pro, and works with ARM Cortex-M devices from any vendor. It works with both SEGGER J-Link and ST-LINK from STMicroelectronics.

Typical problems detected by the fault 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, 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 of 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

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