Event Counters
The DWT profiling counters as tiles: CPI (extra cycles per instruction), exception overhead, sleep, load/store stalls, folded instructions and the cycle event. They are the core's own accounting of where its cycles went, with no sampling involved.
Needs: the SWO trace source, Profiling Source On-chip trace, and one or more Counter: switches on. See Hardware trace. The cycle event is refused while PC sampling is on (they share the same hardware timer).
The tiles
| TILE | MEANING |
|---|---|
| CPI | Extra cycles spent per instruction beyond the first (pipeline stalls, waits on flash) |
| Exception overhead | Cycles spent entering and leaving exceptions |
| Sleep | Cycles the core spent asleep (WFI / WFE) |
| Load/Store | Extra cycles in loads and stores |
| Folded | Instructions that took no cycle at all |
| Cycle event | A tick every POSTCNT interval; off unless enabled with PC sampling off |
| CPU load (measured) | 1 - sleep cycles / elapsed cycles, with the Sleep counter on. A measurement, not the Profiler's sample-share estimate |
Each tile shows the counted cycles, the rate per second and the number of wraps: every counter is 8 bits wide and sends a packet each time it passes 256, so 3,296 wraps is 843,776 cycles. The header states how many seconds of counter data the figures cover.
When the pin overflows
Several counters at once produce a packet every 256 cycles each, which a 2 MHz pin cannot carry for long. When the ITM dropped packets, the header says so in amber (SWO overflowed 133,835 times: wraps were lost, cycles and load are lower bounds) and every figure on the panel is a floor, not a measurement. Turn on only the counters you need (the Sleep counter alone gives the CPU load), or raise the SWO frequency.
Tips
- The same tiles come out of the command line, with a
reliableflag:viewalyzer-cli query dwt-counters --recording capture.vadb. - The measured CPU load and the CPU view's busy figure answer different questions: the CPU view counts task slices from the recorder, this tile counts cycles the core did not sleep. On a firmware that idles in WFI they agree; on one that busy-waits, only this one sees it.