Analyzing Code Coverage via Trace Reconstruction

Learners will process raw trace data to generate accurate code coverage reports, identifying untested execution paths within complex embedded firmware.

In this lesson, you will learn how to reconstruct execution history from raw Embedded Trace Macrocell (ETM) packets to determine which code paths were actually executed during a test run.

From Raw Packets to Execution Paths

When a processor is configured to stream trace data, it does not send every instruction. Instead, to save bandwidth, it sends "atoms"—highly compressed packets that indicate branch outcomes (taken vs. not taken) or indirect branch targets. To achieve code coverage, we must reconstruct the program flow by mapping these atoms against the static Disassembly/ELF file.

The Reconstruction Process

Think of the trace stream as a sequence of breadcrumbs through a maze (your code). Every time the CPU hits a branch instruction, the hardware emits an atom:

1 (or T): Branch taken.
0 (or N): Branch not taken.

If you encounter an indirect branch (like a bx lr or function pointer), the hardware includes the target address in the stream. By "replaying" these atoms through your control-flow graph (CFG), you can reconstruct the exact instruction pointer (IP) sequence.

Illustrative Example

Consider this simple conditional block:

0x08001000: cmp r0, #0
0x08001002: beq 0x08001008  // Branch instruction
0x08001004: mov r1, #1      // Path A
0x08001006: b   0x0800100A
0x08001008: mov r1, #0      // Path B
0x0800100A: ...

If your trace buffer receives a 0 (Not Taken) atom for the branch at 0x08001002, the reconstruction engine knows the CPU moved linearly to 0x08001004. If it receives a 1, it maps the execution to 0x08001008. By aggregating these hits over millions of cycles, you can generate a heat map. If an address range in your binary never appears in the reconstructed path history, you have identified a gap in your test suite—an untested execution path.

This process is fundamentally non-intrusive; because the ETM hardware handles the instrumentation, the timing of your firmware remains unchanged, allowing you to measure coverage on real-time systems that would otherwise fail under heavy software-based instrumentation overhead.

Key Takeaway: Trace reconstruction translates compressed hardware atoms into a full execution log, allowing you to map exactly which lines of code were exercised without modifying the firmware timing.