BKPT LabsDOCS/BKPT DEBUG/DEBUGGING BKPT DEBUG · VS CODE
BKPT DEBUG · USER GUIDE

Debugging

Run control, breakpoints, the call stack, registers and memory: the debugger's tiles, in the order you use them once the target is halted at main.

Run control

The strip's icons and the keys do the same things: continue, pause, step over, step into, step out, step one instruction, reset, stop. While the target runs the strip reads running; at a halt it names the reason (breakpoint-hit, end-stepping-range, a pause, a fault) and the status bar shows the frame.

Stepping masks interrupts by default (bkptDebug.maskIsr = auto), so a step lands on the next line of your code instead of inside a handler that happened to fire. Set it to off to step into interrupts, or on to keep them masked across Continue as well.

Breakpoints

A breakpoint hit in the main loop: the halt line in the Code tile, the Breakpoints tile listing it, the Call Stack with the loop's locals.
A BREAKPOINT HIT IN THE MAIN LOOP: THE HALT LINE IN THE CODE TILE, THE BREAKPOINTS TILE LISTING IT, THE CALL STACK WITH THE LOOP'S LOCALS

Click a line number in the Code tile (or in a normal editor) to set or clear a breakpoint. Breakpoints are VS Code's own, so they survive between sessions and show in its Breakpoints view too. The Breakpoints tile lists them with the debugger's verdict: bound at an address, pending, or refused (a line with no code). A breakpoint set while the target runs is armed at once; if the target could not be interrupted for it, it is bound at the next halt and says so.

The Code tile

The centre of the layout. It follows the halt: the current line is highlighted, a selected frame is marked in its own colour, and while PC sampling runs each line carries its sample count in the gutter (amber when the line executed within the last second). Click a line number to toggle a breakpoint. Files open as tabs; drag a tab to the tile's edge to split it into groups the way VS Code's editor does, and the arrangement is kept per workspace. open in the tab row opens the same file in a normal editor.

While the layout is the visible tab, a halt updates the Code tile and does not open editors behind it; close the layout and halts open the file in the editor instead.

Call Stack and locals

Two steps later: the Call Stack tile with the frame's locals, the Registers tile with the changed registers marked.
TWO STEPS LATER: THE CALL STACK TILE WITH THE FRAME'S LOCALS, THE REGISTERS TILE WITH THE CHANGED REGISTERS MARKED

One card per frame (#0 at the top), with the function, file and line, the frame's locals with their values (hover for the type), and its sp and pc. Click a frame to select it: the Code tile shows that frame's line and the locals are the frame's. A value the compiler kept in a register or optimised away shows as <optimized out>, which is the compiler's verdict, not the debugger's.

Registers

The core registers as the halt left them, r0 to r12, sp, lr, pc and xpsr, with a mark on every register that changed since the previous halt. The FPU bank folds below on cores that have one, opened when a value in it changed.

Memory

The Memory tile: 256 bytes at an address expression, hex and ASCII, re-read at every halt.
THE MEMORY TILE: 256 BYTES AT AN ADDRESS EXPRESSION, HEX AND ASCII, RE-READ AT EVERY HALT

A 256-byte window at any address expression (0x20000000, &rms, $sp), hex and ASCII, re-read at every halt. While the target is halted the bytes are editable in place: click a byte, type the new value, and it is written through the probe.

Evaluate and edit variables

BKPT Debug: Evaluate Expression asks for a gdb expression and shows the value. In the Code tile, right-click a variable for its type and value and to set it in place (locals and globals alike); the Symbols tile does the same for any global in the ELF, with live values while the target runs (see Live watch).

Reset, restart and stop

Reset resets the target and runs to main again (bkptDebug.runTo), keeping the session and its breakpoints. Restart ends the session and starts a new one: the live graphs, the sampled lanes and the ITM Console start from zero with it. Stop detaches: the target keeps running whatever it was doing, and the debugger's own configuration on the core (vector catch, interrupt masking, sampling) is restored before it lets go.

The Target menu

Target in the strip scans the connected core with the bundled probe tool: the CoreSight components it finds (DWT, ITM, FPB, TPIU, ETM) and what they mean for you, as verdicts: PC sampling available, DWT data watch with N comparator slots, ETM trace and where its sink is. It also reports the probe's SWO receiver ceiling, shown next to the SWO clock field. The verdicts feed the Hardware Trace tile's decisions and the Symbols tile's DWT slots. The scan needs the probe to itself, so it runs between sessions.

Known limits

  • The extension never programs the target. Flash with your vendor tool; the first halt tells you when the flash and the ELF disagree.
  • Hover-to-evaluate in the Code tile and frame arguments in the Call Stack are on the list; use the right-click popup and Evaluate Expression meanwhile.
  • One session at a time, one core: multi-core parts are debugged one core per window.