Hardware trace

The Cortex-M3 and up carry two debug blocks that report what the core does with no firmware support: the DWT (program-counter samples, every interrupt entry and exit, data watches, cycle counters) and the ITM (the printf port). In a debug session BKPT Debug programs them through the probe and reads the packets back over the SWO pin. Three tiles show the result: Hardware Trace (the controls), ITM Console and Exceptions; the PC samples feed PC sampling and the data watches the Symbols rows.

Needs: an ST-LINK or J-Link with the board's SWO pin wired to it, and a core that has the blocks (Cortex-M3, M4, M7, M33; the M0 and M0+ have no ITM, and the tile says so). Two things must be in place before the session starts, and the tile names the missing one in its header line:

a Target scan (the Target menu in the strip, between sessions): the on-chip decision needs the scan's verdict on what the core has;
the core clock: the Core clock field at the top of the Target menu (saved as bkptDebug.cpuClockHz in the workspace settings). The SWO baud and every sample rate derive from it; the Hardware Trace tile shows the value it has, and says so when it is not set.

Without either, the session polls over the probe and the header says why.

The SWO clock field below it is optional: blank (bkptDebug.swoFreqHz = 0) means automatic, the fastest exact rate this probe's receiver takes, up to 10 MHz (a STLINK-V3 takes up to 24 MHz, a V2 2 MHz; a J-Link reports its own ceiling; the scan shows it next to the field). The TPIU divides the core clock by a whole number, so the rate in use is rounded to what it can make and the tile shows that value. A faster pin is the main cure for ITM overflows: at 2 MHz a 20 kHz PC sample stream alone fills 65% of it and data watches lose packets, at 10 MHz the same session sits at 13%.

The one switch

The Hardware Trace tile starts with Profiling Source:

VALUE	WHAT YOU GET
Off	No hardware trace; the debugger leaves the DWT and ITM alone.
Sampling (default)	A rough profile with nothing else to set up. With a Target scan and a core clock in place, on-chip PC sampling over the SWO pin when the core has the DWT and an ITM; polling over the probe otherwise.
On-chip trace (advanced)	Everything the core has, the way an Eclipse SWV panel shows it: the PC sample interval, exception trace, the DWT event counters, data watches on the comparators, ITM ports and timestamps.

Whichever you choose, the tile always says what runs and how fast, in one line: On-chip, every 16384 cycles (~10.4 kHz at 170 MHz) or Polling over ST-LINK, ~3.1 kHz. The same line heads the PC Sampling tile.

On-chip trace, control by control

CONTROL	MEANING
PC sample interval	64 to 16384 cycles between samples; each entry is labelled with the rate it yields and its share of the SWO pin, and entries the pin cannot carry are greyed out.
Exception trace	Every interrupt's enter, exit and return from the hardware; counts in the Exceptions tile.
Event counters	CPI, exception overhead, sleep, load/store and fold cycles; each counter is 8 bits and emits a packet every 256 cycles, so several at once cost real pin bandwidth.
Data watches	Pick a DWT comparator slot in a Symbols row (`dwt:1`..`dwt:N`, as many as the Target scan found): the chip emits the value on every write, no probe traffic, and it lands on the row and its graph like a polled sample. The tile lists every slot with the variable it traces.
ITM ports, timestamps	The stimulus-port mask (port 0 carries `printf`) and the local timestamp prescaler. Text lands in the ITM Console. Timestamps cost up to three bytes per packet: an interrupt that runs right after another, or a tick that writes several watched variables, produces a burst the ITM FIFO cannot hold with them on (on the bench a 200 Hz interrupt lost every entry with timestamps on and counted every one with them off). Turn them off when the counts matter more than the times.
Load line	The estimated share of the SWO pin from everything enabled; it turns red before the pin overflows.

A control the core lacks is disabled with the reason, never hidden.

The ITM Console and Exceptions tiles

The ITM Console shows what the firmware prints on ITM stimulus ports, read-only, with the port and a timestamp per line; it opens itself the first time a line arrives and starts empty with each session, like a terminal on a new run (the previous session's text is in its recording). The Exceptions tile shows the traced exception counts per handler (enter, exit, return, deepest nesting) while the session runs, and the recording's full table once it stops.

Captures and `.vacf`

The same switch and Advanced panel sit on the Record form for captures without a debug session, and a .vacf connection file carries the settings as its hardware-trace key, so a configuration made here works in the ViewAlyzer app and on the command line. The full story of the sources, the pin budget and what each core supports is in the ViewAlyzer guide's Hardware trace page.

Known limits

The SWO-borne sources need the SWO pin; over RTT or the RAM buffer the profile is PC sampling by polling.
Data-watch streaming needs the on-chip session; a slot row polls when the session cannot carry it.
Manchester SWO is not supported; the probes here receive NRZ.

BKPT DEBUG OVERVIEW START HERE EMAIL SUPPORT