1
The need
When the failure happens, the debugger is not there, or it changes the outcome.
Intermittent faults
It shows up after hours or days of operation, rarely on the bench. By the time someone looks, the state that caused it is gone.
Timing-dependent bugs
Add a breakpoint or a printf and the bug moves or vanishes, because you changed the timing that triggered it.
Multi-core interactions
Two cores, one shared variable, a missing barrier. Each core is correct alone; the failure is in the interleaving.
Failures on the real target only
In its enclosure, with its real traffic and clocks. No trace connector on the production board, often no one watching.
A crash dump shows where the CPU stopped.
The trace shows the path that led there.
2
Why the usual tools fall short
Each one trades visibility against disturbance, or against hardware on the board.
| Approach | Changes timing? | History before the failure? | Extra hardware |
|---|---|---|---|
| Breakpoint, halt-mode debug | Yes, the core stops | No, only the current state | JTAG/DAP probe |
| printf, logging | Yes, cycles and I/O | Partly, what you chose to log | None |
| External trace probe (TPIU) | No | Yes, streamed live | Trace port pins, connector and trace probe, during the run |
| ChipTrace, on-chip sink | No, no code runs | Yes, the last buffer window | Nothing during the run. An NVM buffer, read over Ethernet or JTAG afterwards. |
An external trace probe gives the longest history and live streaming. ChipTrace targets the boards and situations where that probe cannot be connected.
3
Use cases
Six situations, and the CoreSight features each one relies on.
Post-mortem on an intermittent crash
ETMETFChipTrace_Close() in fault handler
The sink runs circular from boot. When the fault handler calls ChipTrace_Close(), the buffer holds the instructions that led to the fault. Saved to NVM, it survives the reset that follows.
Exact path to the faulting instruction, including the branch decisions that got there.
Races between cores
ETM ×NCSTFTSG
Every core has its own ETM; the funnel merges the streams and the shared timestamp orders them.
Which core touched the shared data first, and what each one was doing at that moment.
Early boot and board bring-up
ETFno DDR needed
The ETF stores trace in its own SRAM, so capture works before the DRAM controller is up.
Where boot stalls: DDR training, clock tree, a peripheral that never answers.
Timing on the production binary
cycle counttimestamp
Cycle counts and timestamps come with the program flow, without instrumenting the code.
Interrupt latency, task execution time, jitter. Observed values on real runs, not a WCET proof.
Coverage evidence
program flowTRACE32ChipTraceAnalyzer
TRACE32 or ChipTraceAnalyzer derive line and branch coverage from the recorded flow of the unmodified binary, merged across runs.
Structural coverage data for DO-178C, ISO 26262 or IEC 61508 verification activities, from the code as built. One capture covers one buffer window: coverage is accumulated over several runs or with a large ETR buffer.
Lightweight software markers
STMITM
A store to a stimulus port becomes a timestamped message in the same trace stream.
printf-style markers for a few bus accesses per message, instead of a UART transmit.
4
Walkthrough: an intermittent failure on the target
1
System running
Normal operation
2
Failure occurs
Intermittent fault
3
Trace captured
ETM / CoreSight
4
Trace extracted
NVM, then Ethernet or JTAG
5
Reconstruction
Execution history
6
Root cause found
Fix and validate
The trace keeps the path that led to the failure, not only the moment it happened.
5
Where it is used
Domains where the binary under test is the binary that ships.
Automotive
NXP S32G2 and S32G3 vehicle network processors. Trace data feeding ISO 26262 verification activities.
Aerospace and defense
Structural coverage and timing observation on the flight binary, for DO-178C verification.
Space
NanoXplore NG-Ultra, radiation-hardened SoC FPGA with four Cortex-R52 cores.
Networking and industrial
NXP Layerscape LS1043A, LS1046A and LX2160A; AMD Zynq UltraScale+ MPSoC. Trace data for IEC 61508 functional-safety verification.
Standards the trace data supports:ISO 26262 · automotiveDO-178C · airborne softwareIEC 61508 · industrial functional safety
ChipTrace records the binary that ships, without instrumentation: structural coverage, observed timing and execution history come from the code as built, which is what these standards ask verification to be performed on.
MOVE.B training
Learn the trace ChipTrace relies on
The CoreSight units ChipTrace programs, the cores it traces and the SoCs it runs on, each one a MOVE.B course.