Post-mortem trace analysis
Post-mortem analysis is the investigation of an embedded system after a crash, reset, or other failure has already happened. Its purpose is to reconstruct the sequence of events that led to the failure and to reduce the time needed to find the root cause.
Off-chip hardware instruction tracing is particularly valuable when the problem is hard to reproduce, happens too quickly for intrusive debugging, or leaves the target in a state where normal interaction is no longer possible. By capturing executed instructions outside the device, it can provide a reliable view of the final control flow before the failure.
Debug and Trace Units
The debug unit is the processor's hardware interface for active debugging. It allows a debugger to connect to the target, halt and resume execution, set breakpoints and watchpoints, and inspect or modify processor registers and memory.
The trace unit records information about the processor's execution, such as the instructions, branches, and exceptions that occurred. When connected to an external trace capture system, it can continuously record a history of program execution with no impact on the target. Unlike the debug unit, the trace unit can preserve information about what happened immediately before a failure, even when the target can no longer be halted or accessed by a debugger.
Use Cases
J-Trace supports the investigation of all the scenarios described below. It combines standard debugging capabilities via the debug unit, such as breakpoints, data watchpoints, and single-stepping, with continuous off-chip instruction trace capture via the trace unit. This makes it possible to analyze failures even when the target can no longer be accessed through its debug interface.
| Failure scenario | Target inspection after the event | Previously captured off-chip trace |
|---|---|---|
| HardFault | Available | Available |
| Target reset | Available after reconnecting | Available |
| Catastrophic lockup | Possibly unavailable | Available |
| Target power loss | Unavailable | Available |
HardFault
A HardFault can occur when the target executes an invalid or otherwise unsupported operation. In this situation, the processor normally remains powered and the debug connection is still available.
A traditional debugging approach can therefore be used to inspect the target after the fault. Registers, the current program counter, the stack, and other memory contents can be examined to determine what led to the HardFault.
Instruction trace provides additional information by showing the execution history leading up to the fault. This makes it possible to analyze the sequence of instructions that was executed immediately before the failure, even when the current processor state alone does not provide enough information.
Target Reset
A target reset interrupts the current execution and initializes the processor again. Depending on the reset source and target configuration, the debug connection may be temporarily interrupted and subsequently re-established.
After reconnecting to the target, the current processor state can be inspected using conventional debugging methods. However, this state represents the target after the reset and may no longer contain information about the execution that caused it.
Previously captured instruction trace can provide this missing history. By analyzing the trace data from before the reset, it is possible to determine which code was executed immediately before the reset occurred.
This is particularly useful for resets that are difficult to reproduce or for which the target state after the reset does not contain sufficient information to identify the cause.
Target Power Loss
When power is lost unexpectedly, the system may not have time to flush logs or save state to nonvolatile memory. In that case, the latest recorded trace data becomes the most valuable evidence. Off-chip tracing can preserve the final executed instructions up to the moment the power disappeared, allowing the analysis to focus on the immediate pre-failure behavior.
This makes it possible to identify whether the system was executing normal application code, handling an interrupt, waiting in a loop, or entering a shutdown sequence when power was removed.
Catastrophic lockup
In a catastrophic crash, the system may become completely unresponsive and no longer accept debugger connections or produce useful output. In such cases, the only available evidence may be the last recorded trace data. That trace can still reveal the last known control flow, the active execution context, and the point where behavior diverged from normal operation.
Even if the target can no longer be controlled, the trace may show whether the crash was preceded by a bad branch, an unexpected exception, stack corruption, or an endless loop.
Limitations
Post-mortem analysis with off-chip tracing is powerful, but it has limits.
The limitations described in this section apply specifically to the power-loss and catastrophic-crash use cases, where the debug unit is unavailable and the analysis depends on trace data that was recorded before the failure.
Some data may still be buffered on the device and never reach the trace sink if the system loses power too quickly or crashes before the trace hardware can drain its internal buffers. In addition, trace data typically shows execution flow, not full application state, so variables, registers, or memory contents may still be unavailable unless they were captured separately.
Example with Ozone
TBD