In short: SWD debugging on ARM Cortex-M uses a 2-wire port into the CoreSight debug block to halt, single-step, read/write memory and registers, and arm a limited number of hardware breakpoints (FPB) and watchpoints (DWT) that trap on instruction fetches or data accesses — while the optional single-pin SWO carries non-halting ITM/ETM trace out at MHz rates.
If you have ever set a breakpoint in a Cortex-M firmware project and wondered what actually happens on the silicon between your IDE and the CPU, this article is for you. SWD (Serial Wire Debug) is the physical and protocol layer; the real work is done by a cluster of on-chip debug units called CoreSight. Understanding that split is what separates an engineer who can "click the red dot" from one who can debug a crash that only happens once every ten thousand interrupts.
SWD vs the debug infrastructure behind it
SWD replaces the 5-pin JTAG TAP with just two signals — SWDIO (bidirectional data) and SWCLK (clock) — plus ground. It drives the same Debug Access Port (DAP) that JTAG would, so capability is identical; you simply free up pins. For the full pin-count and protocol comparison, see our deep dive on JTAG vs SWD. Through the DAP the debugger reaches the AHB-AP, a memory-access port that lets the probe read and write the entire system bus — including the processor's debug registers mapped at 0xE000EDF0 (the DHCSR) — without the CPU's cooperation.
Halt, step and the DHCSR
A halt is not a software trick — it is a hardware state. To stop the core the probe writes the Debug Halting Control and Status Register (DHCSR): set C_DEBUGEN to enable debug, then C_HALT. The CPU completes its current instruction and enters debug state, at which point S_HALT reads back as 1. Single-step is C_STEP with C_HALT cleared: the core executes exactly one instruction and re-halts. Because this is all memory-mapped, the probe can also read R0–R15, the xPSR and even stack frames while halted, which is how your IDE reconstructs a call stack.
On a typical Cortex-M4 at 168 MHz, a halt from the probe takes microseconds — but interrupts are frozen too. If you halt inside a motor-control loop, the PWM stops and the H-bridge may latch current. This is exactly why non-intrusive trace (next section) exists.
Hardware breakpoints: the FPB unit
When your code runs from flash you cannot overwrite an instruction with a BKPT opcode the way you can in RAM — flash is not byte-writable on the fly. Instead the Flash Patch and Breakpoint (FPB) unit holds a small table of comparators. Each loaded with an instruction address; when the fetch address matches, the core halts before executing. The catch is scarcity: Cortex-M0+ typically offers 4 instruction comparators, M3/M4 offer 6, and M7 offers 8. Exceed that count and most debuggers silently fall back to slow software breakpoints or simply refuse.
- Hardware breakpoint — FPB comparator, works in flash, zero runtime overhead, but limited in number.
- Software breakpoint — a
BKPT #0patched into RAM-resident code; unlimited, but only where memory is writable.
Watchpoints and the DWT
A breakpoint traps an instruction address; a watchpoint traps a data access. The Data Watchpoint and Trace (DWT) unit compares the address (and optionally the value) of every load/store against its comparators and halts on a read, a write, or both. This is the fastest way to catch "who is corrupting this global?" — set a write watchpoint on the variable's address and the core stops the instant any code touches it, even a wild pointer you never suspected.
| Feature | Unit | Triggers on | Typical count (M4) |
|---|---|---|---|
| Breakpoint | FPB | Instruction fetch at address | 6 |
| Watchpoint | DWT | Data read / write at address | 4 |
| Cycle / PC trace | DWT + ITM | Profiling counters, PC samples | — |
SWO trace: watching without stopping
Halting is destructive for real-time systems. SWO (Serial Wire Output) is a single extra pin that streams data out asynchronously while the core keeps running. The DWT can emit periodic PC samples and exception entry/exit events; the ITM (Instrumentation Trace Macrocell) lets your firmware do printf-style logging by writing a byte to a stimulus port register — orders of magnitude cheaper than a UART because there is no peripheral driver in the path. At a 6 MHz SWO baud you can carry thousands of events per millisecond without perturbing timing. For full instruction trace you step up to the 4-bit parallel ETM/TPIU, the technology behind Lauterbach and Arm's own trace tooling; Siemens' embedded analysis and Synopsys processor models speak the same CoreSight protocols in simulation.
A practical debugging recipe
Suppose a FreeRTOS task occasionally hard-faults with a bad address. Here is how the pieces combine:
- Set a DWT write watchpoint on the suspect buffer's end address to catch the overrun at the exact store instruction.
- Enable ITM port 0 and log task-switch IDs so you know which task was active without halting.
- Reserve one FPB breakpoint at the HardFault_Handler so you land there with the faulting stack frame intact and can read the stacked PC.
That workflow finds in minutes what blind printf debugging can hide for days. If you want structured, lab-based practice on exactly these flows, our training partner ChipXpert's embedded and VLSI training runs hands-on Cortex-M bring-up sessions. You can also explore adjacent topics such as the Cortex-M fault handling guide.
Ready to debug like the pros? The CourseTron Embedded Systems track covers SWD, CoreSight and RTOS debugging end to end — browse the courses.
Frequently asked questions
How many breakpoints can I set on a Cortex-M4?
Typically six hardware breakpoints via the FPB when running from flash. You can set more only in RAM-resident code, where the debugger patches BKPT instructions as software breakpoints.
What is the difference between a breakpoint and a watchpoint?
A breakpoint halts on an instruction address (FPB), so it fires when the CPU is about to execute specific code. A watchpoint halts on a data address (DWT), so it fires when code reads or writes a specific memory location — ideal for catching corruption.
Does SWO slow down my application?
No. SWO/ITM is non-halting trace: the core keeps running while packets stream out the single SWO pin. An ITM write is a single store to a register, far cheaper than a UART printf, so timing impact is negligible at typical event rates.
Can I use SWD and SWO at the same time?
Yes. SWD (SWDIO + SWCLK) handles control and memory access; SWO is a separate output pin for trace. Together they give you halt/step control and live, non-intrusive visibility — the standard 4-wire SWD+SWO debug header.