PC sampling

Turn it on and the debugger samples the program counter over the probe while the target runs: a statistical profile with zero overhead on the target and nothing in the firmware. It answers "what is the CPU doing right now" without stopping it.

The PC Sampling tile

• The header line names the source and the rate: Polling over ST-LINK at a few thousand samples per second, or on-chip sampling over the SWO pin when the Hardware Trace switch chose it.
• CPU load: the share of samples that did not find the core asleep (WFI / WFE), over a rolling window. The same figure the ViewAlyzer app computes.
• The function table: one row per function, its samples and share, with an ISR badge on interrupt handlers (found in the ELF's vector table) and a switch to include or exclude them. Click a row to open the function in the Code tile at its hottest line.
• pause freezes the counts to read them; clear starts over.

The gutter

Every line that was sampled carries its count in the Code tile's gutter (and in normal editors of the same file). A line that executed within the last second is amber, so a running firmware shows you where it is right now.

The timeline

With the Timeline tile shown during a session, the samples are bucketed into 10 ms slices and drawn as lanes, one per function, idle when the core mostly slept. It reads like a task timeline, and it is statistical: a lane says which function dominated a slice, never that a switch happened at that instant.

Tips

• The sampling rate is the probe's (about 2.4 kHz over an ST-LINK V3); bkptDebug.pcSamplingUpdateMs only sets how often the views refresh.
• A handler that runs for a few microseconds every second will rarely be sampled. For interrupt timing use the Exception Trace over SWO or a recording.
• A large share outside any function means the ELF does not match the firmware on the board.