No probe
The trace is kept on the board and read back later, over Ethernet or JTAG.
0 CPU cycles
while your application runs: the chip's trace hardware does the recording.
Every core
every instruction, on one shared clock: who did what, and in which order.
Your release build
No instrumented build: the binary you trace is the binary you ship.
Try it now
A real trace, right here: play with it
A zonal gateway ECU on an NXP S32G3, four Cortex-A53 cores. ChipTrace kept the last 21.55 ms of their execution, ChipTraceAnalyzer decoded it: 6,650 instructions in 26 functions. Click a bar to open its C source, coloured with what actually ran. No TRACE32 licence needed to read the trace.
Try
Drag to pan, Ctrl + wheel or pinch to zoom, click a bar to open the function, anywhere else to move the cursor.
The problem
The crash happens when nobody is watching
Today
A fault shows up once a week, on a board in the field or on the test bench at night.
No debugger is attached, the logs stop before the interesting part.
Nobody can reproduce it, so nobody can fix it.
With ChipTrace
The chip has been recording all along, without slowing anything down.
The last moments of every core are saved when the fault happens.
You replay the exact path that led to it, line of code by line of code.
How it works
Three steps, and no CPU time while it records
1
Switch it on
One call at boot sets up the trace blocks of your SoC (Arm CoreSight™), from a small library linked into your firmware. After that, no ChipTrace code runs until the capture is stopped.
2
Run as usual
Your application runs untouched. The hardware records in a loop and always keeps the most recent history: no interrupt, no polling, no stall.
3
Replay
After a crash, or at a point you choose, the trace is saved and read back. ChipTraceAnalyzer or Lauterbach TRACE32® turns it into what every core executed.
What teams use it for
Debugging, timing and coverage evidence
Intermittent crashes
The path that led to the fault, not only the place where the CPU stopped.
Races between cores
Every core on one timeline, to see which one touched the data first.
Timing on the real binary
Interrupt latency and task durations, measured instead of estimated.
Coverage evidence
Lines and branches executed by the shipped binary, for ISO 26262, DO-178C or IEC 61508.
Proven on silicon
Supported SoCs
NXP S32G3 · referenceNXP S32G2NXP LS1043ANXP LS1046ANXP LX2160ANanoXplore NG-UltraAMD Zynq MPSoCST STM32H7
Each reference application is run on the board and checked automatically by T32Pilot, MOVE.B's test bench: more than 380 scenarios on S32G3, LS1043A and NG-Ultra, from instruction trace to the state every core must reach.
What goes into your firmware, supported SoCs, their datasheets and validation →
Go further
More on ChipTrace
Use cases
Which problems is it built for?
Read →ChipTraceAnalyzer
How do I read the trace once I have it?
Read →Trace principle
What does the chip record, and why doesn't it slow the CPU?
Read →Triggers & counters
How do I record only the moment that matters?
Read →Integration
What goes into my firmware, and what does it cost?
Read →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.