Debugging & Observability on Embedded Systems Development

SWD, JTAG & Debug Probes

Mon, 01 Jan 0001 00:00:00 +0000

SWD, JTAG & Debug Probes#

Debug access to a microcontroller requires a physical interface between the host toolchain and the target silicon. The two dominant protocols — SWD and JTAG — differ in pin count, capability, and ecosystem support. Choosing the right debug probe and wiring it correctly determines whether breakpoints, flash programming, and register inspection work reliably or not at all.

SWD — Serial Wire Debug#

SWD is an ARM-specific two-wire protocol using SWDIO (bidirectional data) and SWCLK (clock). It provides full debug access — breakpoints, watchpoints, flash programming, and register read/write — over just two signal lines plus ground. SWD clock speeds typically run at 1-4 MHz for reliable operation, though many probes support up to 10 MHz on short traces. The protocol also carries SWO (Serial Wire Output) on an optional third pin, enabling trace output without additional UART hardware.

Serial Debug Output — UART, SWO & RTT

Mon, 01 Jan 0001 00:00:00 +0000

Serial Debug Output — UART, SWO & RTT#

Getting runtime information out of a microcontroller is fundamental to firmware development. Three approaches dominate: UART-based printf, ARM’s SWO trace output, and SEGGER’s RTT memory-based transfer. Each trades off pin usage, throughput, timing distortion, and toolchain dependency differently. Understanding these tradeoffs determines whether debug output is helpful or actively misleading.

UART Debug Output#

The most common debug channel uses a UART peripheral retargeted to printf() via a syscall stub (e.g., _write() on GCC/Newlib or fputc() on Keil). Typical baud rates range from 115200 to 921600. At 115200 baud, a 64-byte message takes roughly 5.5 ms to transmit — long enough to distort millisecond-scale timing. A USB-to-serial adapter (CP2102, CH340, FTDI FT232) bridges the UART to the host. DMA-backed UART transmission reduces CPU blocking: the firmware queues a buffer and returns immediately, but the output still occupies the wire at baud-rate speed. UART debug requires two dedicated pins (TX/RX) and is available on virtually every MCU.

Logic Analyzers & Oscilloscopes at the Bench

Mon, 01 Jan 0001 00:00:00 +0000

Logic Analyzers & Oscilloscopes at the Bench#

Software debugging reveals what firmware thinks is happening. Logic analyzers and oscilloscopes reveal what is actually happening on the wire. Protocol mismatches, signal integrity failures, and power delivery problems are invisible to software tools but immediately apparent with the right instrument and trigger configuration.

Logic Analyzers for Protocol Decoding#

A logic analyzer captures digital signals and decodes them into human-readable protocol transactions. The Saleae Logic Pro 8 (8 channels, 500 MS/s digital, $480) and Logic 8 (8 channels, 100 MS/s, $200) are the most common bench tools for embedded work. Budget alternatives using Cypress FX2-based clones ($10-15) work with the open-source sigrok/PulseView software at sample rates up to 24 MHz. For SPI decoding, sample at least 4x the clock rate — a 10 MHz SPI bus needs 40 MS/s or higher. I2C, running at 100-400 kHz, is comfortably captured at 1-2 MS/s. Protocol decoders overlay the raw waveform with decoded bytes, addresses, and ACK/NACK status, making it straightforward to confirm whether the MCU is sending what the firmware intends.

Hard Faults & Crash Analysis

Mon, 01 Jan 0001 00:00:00 +0000

Hard Faults & Crash Analysis#

When an ARM Cortex-M processor encounters an unrecoverable error, it triggers a fault exception. Without a proper fault handler, the default behavior is an infinite loop — the system appears frozen with no indication of what went wrong. Implementing fault capture and understanding the fault registers transforms a mysterious hang into a diagnosable event with a precise faulting instruction and root cause.

Cortex-M Fault Types#

The Cortex-M fault architecture defines four exception types. HardFault (exception 3) is the catch-all — any fault that cannot be handled by a more specific handler escalates here. BusFault fires on invalid memory accesses: reads from unmapped addresses, writes to read-only regions, or peripheral access with clocks disabled. UsageFault catches illegal instructions, unaligned access (when not permitted), and divide-by-zero (if enabled via CCR.DIV_0_TRP). MemManage triggers on MPU violations — access to regions forbidden by the Memory Protection Unit configuration. On Cortex-M0/M0+, only HardFault exists; the other three require Cortex-M3 or higher and must be explicitly enabled via the SHCSR register.