Find out where and why a system crashed
- Automatic detection of exceptions
- Useful information on reasons of a crash
- Fault analysis debugging features
During development of an embedded application, crashes of the firmware can happen. Illegal memory writes, access of unpowered peripherals, execution of invalid instructions, division by zero, ... in all cases the execution ends up in a HardFault handler. What can be done next?
Ozone does not only enable automatic detection of when a fault happens. It provides further tools and information for analysis of why a crash happened, what could have caused it, and what happened before.
For more information on faults on cortex-M, refer to: Cortex-M Faults
For technical details on fault analysis with Ozone, refer to: Analyzing Cortex-M Faults with Ozone
Ozone makes use of the Vector Catches on Arm devices.
In addition to regular breakpoints, Arm devices can break execution on fetch of an exception vector, just before the exception handler is executed. This feature enables automatic break on exception without the use of hardware breakpoints.
With a vector catch on HardFault, a system crash can be immediately detected and further analyzed in the debugger.
In Ozone vector catches can be enabled or disabled in the Breakpoints Window.
On a system crash, Arm Cortex-M microcontrollers provide information about the crash in different registers. Manually gathering all information to get the reason for the crash can be cumbersome.
When Ozone detects a fault, it automatically analyzes the related registers and presents a popup with the reason for the crash and further information, such as where the crash happened or which address could not be accessed.
Once the reason for a crash is detected, the next step is to identify where it happened.
In addition to the fault status registers, Ozone provides all regular debug information windows, even in exception state. The Call Stack window shows where the exception has been raised. With the Registers Window and the Locals Window the faulty state can be inspected.
Bus fault exceptions might be raised later than the illegal access, usually a few instructions later. In these cases Ozone's instruction trace can help to identify which instructions have been executed before.