DOCS/BKPT DEBUG/RECORDING A TRACE
BKPT DEBUG · VS CODE
Recording a trace
The trace views of the ViewAlyzer desktop app, inside VS Code: record what your RTOS and your firmware's own trace channels do, and read it in a timeline, an event table, CPU statistics and trace graphs.
Needs: the ViewAlyzer recorder compiled into the firmware (a few C files; the ViewAlyzer-Examples repository has FreeRTOS, Zephyr and baremetal projects with it wired in), or the Symbols watch set for a recorder-free poll capture.
Recording
BKPT Debug: Record Trace Capture in the Command Palette asks how the target is connected: ST-LINK or J-Link over SWO, RTT or the RAM buffer; serial; UDP. Set the target, the CPU clock and how long to record, and start. The Traces tile streams live while the capture runs; when it ends, the recording binds to the ViewAlyzer tiles in place and the Recording menu in the strip lists it with everything recorded before.
A capture needs the probe to itself, so it runs between debug sessions. Without a recorder in the firmware, the Symbols tile's Record stream polls the watch set into a capture at up to 10 kHz.
The views
Every ViewAlyzer view is a tile (the Views menu, under its own heading):
| TILE | WHAT IT SHOWS |
|---|---|
| Traces | Variable traces, memory polls and, during a session, the graphed watch symbols, with zoom, pan and cursors shared across the views; a live track that was zoomed or dragged shows a live chip to resume following, and fit Y is always at hand |
| Timeline | Per-task execution slices, context switches and anomalies, from a whole capture down to microseconds; during a session, the sampled-activity lanes |
| Events | During debugging, a bounded journal of received debug events with filters, producer badges, and links to the relevant view; a recording's event browser uses that recording's data |
| Health | The recording's transport and decode statistics |
They are a focused subset of the desktop app: Open in Full App opens the same recording there in one click, and the desktop app's guide describes each view in depth. CPU statistics and Task Details are available in the full ViewAlyzer app; they are not tiles in the current BKPT-Debug layout.
Debug events are not an RTOS task recorder
Live PC-sampled function lanes, DWT exceptions/accesses, and ITM text can populate views without an RTOS recorder. They do not create task names, scheduler switches, queue operations, or historical RAM values that were never captured. RTOS analysis needs matching firmware recorder data; the current GDB Target thread selector does not discover saved RTOS tasks.
The live debug Events buffer retains the latest 20,000 rows and renders them when opened. Filters, selection, and position survive closing the view. Acquisition continues while it is hidden. See Events and performance.
Preserve the meaning of recorded data
Use the matching ELF with the recording so addresses resolve correctly. Live source badges and timestamp details do not imply that an older or generic .vadb stored the same per-object metadata. Where provenance, timestamp validity, or loss counts were not recorded, treat them as unknown. A smooth plot is not evidence of a loss-free capture.
Opening or filtering a view is not the same as saving a recording. The live debug journal and console use bounded buffers; choose the recording workflow when you need a file to reopen or share.
Recordings
Recordings are .vadb files, shared with the ViewAlyzer app and the command line: the same folder, the same index. The Recording menu opens and deletes them; Open Sample Recording in the Command Palette loads a bundled capture when no hardware is at hand.
Free version
The bundled engine runs unactivated: captures are capped in length, the number of user traces shown is limited, and a short cooldown separates captures. The extension shows the limits in effect. Already own ViewAlyzer? BKPT Debug: Use My Licensed ViewAlyzer points the extension at it.