Debugging and Programming Interfaces

On this page

After the firmware is flashed and no longer responds to the serial port, the first step is to determine whether the lost communication is with the application, the download entry point, or hardware debug access. Their dependencies differ: the application may have crashed, but ROM downloading can still be entered; the debug port may also be inaccessible due to power, wiring, or security configurations. It is inaccurate to generalize that "JTAG/SWD can always rescue a bricked device" or that "if USB can flash, it can debug."

CapabilityWhat it doesDependencies
Core DebuggingHalt, step, breakpoints, register/memory accessChip debug module, permissions, probe, and service support
Firmware ProgrammingErase, write, and verify the imageProgramming interface/algorithm, storage configuration, and operating conditions
Boundary ScanApply and capture test states on covered pins/interconnectsBoundary cells, BSDL, test vectors, and board-level coordination
ROM / Bootloader DownloadReceive image during boot phaseSpecified entry point, transport protocol, and image format
Over-the-Air (OTA) / Online UpgradeReceive and switch firmware while runningService, verification, power-loss recovery, and version policy

JTAG: An Input Interface Does Not Guarantee Every Test Capability

Common JTAG signals are TCK, TMS, TDI, and TDO; the presence of TRST depends on the implementation. TMS drives the TAP state machine on TCK edges, while TDI/TDO serially shift in and out selected registers; debug modules and boundary scan are different uses built upon related structures. Not all chips with JTAG support the required core debugging or complete boundary scan.

A daisy chain typically connects one device's TDO to the next device's TDI; the host needs to know the chain order and configurations such as instruction register lengths for each device. Other devices can reduce shift overhead via BYPASS, but they do not automatically disappear from the physical chain. Mixed voltage domains also require matching; one cannot assume all JTAG targets accept 5 V.

Boundary scan can check some digital interconnects without running application firmware, but it is not "direct control of every pin." Analog, power, high-speed dedicated pins, and networks without boundary cells may not be covered; testing also requires avoiding contention with other drivers on the board. The BSDL describes the device's boundary structure, which, combined with the board netlist and vectors, defines actual coverage. OpenOCD: Boundary Scan Introduction and Tool Support

Microchip: TAP state machine

When do shifted bits take effect?

From reset, TMS sequence 0,1,0,0 reaches Shift-DR and completes capture. Every subsequent TCK shifts, including the cycle with TMS=1 that leaves Shift-DR. Pause-DR can persist without changing the updated value; Update-DR commits it. Inputs remain yours to choose, including detours, pauses and resynchronization. Five consecutive TMS=1 cycles reach TAP reset; this does not mean resetting the CPU or erasing chip data.

Preparing the visual
When do shifted bits take effect?

Shifting and updating occupy different TAP states. Shift-DR changes temporary bits; Update-DR transfers them to the update register.

SWD: Electrical Conditions Beyond Two Protocol Signals

SWDIO is a bidirectional data line, and SWCLK is the clock. Requests include access direction and DP/AP information; the link also requires response, data, parity, and bidirectional switching phases. Taking the Arm debug architecture as an example, the DP provides the external debug entry, and the AP accesses corresponding internal resources; specific core, multi-core, and bus capabilities are determined by the implementation. Arm Debug Interface Architecture

"Simpler two-wire" only counts protocol signals; board-level setups usually also require GND and target voltage reference, and reserving nRESET for reliable reset/recovery is often valuable. SWO is an optional trace output, not a third data line required for normal SWD communication; SWD also cannot universally replace JTAG's boundary scan functionality.

VTref usually allows the probe to sense the target I/O levels, it is not a power output for the target. If the probe additionally provides power, it must be used according to interface definitions to avoid conflicts with board power supplies. Short wires and reasonable return paths help signal quality; SWDIO also allows bidirectional driving, so unidirectional buffers cannot be added arbitrarily. SEGGER VTref Definition

Between GDB and Flash: What Are the Intermediate Responsibilities?

GDB + Correct ELFSymbols, breakpoints, variablesDebug ServiceOpenOCD / Vendor ServiceProbeTarget level and transmissionTarget debug / memory accessAuth, power, core, Flash controlSWD / JTAGFlash algorithm & target setupCorrect address, erase granularity, working RAMDebug request passes through multiple layers: successful probe connection does not equal Flash programmabilityHalt, reset, and Flash writing all change the target state; preserve necessary fault evidence before troubleshooting.

GDB uses a matching ELF to obtain addresses and debug information, sending requests to services like OpenOCD via remote protocol; the service accesses the chip by combining probe and target configurations. Probe support for SWD does not imply that its software already supports the Flash controller, security mode, or multi-core topology of a new MCU.

Downloading to Flash often requires device algorithms, sometimes placing small programs into target RAM for execution. RAM availability, Flash size and bank, clock initialization, and address mapping errors can all cause "can read ID, but cannot burn." J-Link, CMSIS-DAP, ST-Link, etc., are not functionally identical just by brand; specific probe models, firmware, host software, and target support must be checked together; "infinite Flash breakpoints" are also software capabilities with conditions, not unlimited hardware comparators for all probes.

The following uses OpenOCD's ST-Link interface configuration and STM32F4 target configuration as examples, applicable only to verified and matched hardware and tool versions. The command establishes a debug session; reset and halt change the target execution state, so preserve necessary information before troubleshooting field faults.

openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

Start GDB supporting the target architecture in another terminal, and load the ELF corresponding to the target firmware:

arm-none-eabi-gdb firmware.elf
target extended-remote localhost:3333
monitor reset halt
info registers
x/8i $pc

Automatic erase or unlock commands are not provided here. The actual effect of reset halt depends on the target reset configuration, and the port can also be configured; check against local OpenOCD documentation and target settings. OpenOCD: GDB Connection and Debugging, Reset Configuration

Hardware breakpoints/watchpoints are limited in number; software breakpoints may require modifying instructions, and Flash implementation depends on tool support. Halting the CPU does not necessarily halt peripherals, DMA, watchdogs, or another core; single-stepping observation itself changes timing, so it cannot directly prove that real-time operation has no races.

ROM, USB DFU, UF2, and UART Are Not in the Same Classification Dimension

ROM Download EntryChip-fused; interface and entry conditions confirmed by exact modelFlash BootloaderUpdatable software; requires integrity and recovery designApplication In-Service UpgradeWhere the download entry is determines which layer can be relied upon after application corruptionDepends on application or independent service still runningThe diagram shows dependency hierarchy, not that every chip boots in these three layers; USB DFU, UF2, UART describe different protocols/transports.

ROM indicates where the code is located, DFU is a name for a firmware upgrade protocol, UART/USB are transport-related interfaces, and UF2 is an image block format and common loading method. USB DFU can be implemented by ROM or an updatable Bootloader; not all chips with USB have DFU out of the box.

Platform ExampleVerifiable Actual BehaviorGeneralization Cannot Be Made
STM32 System Memory DownloadBoot mode, interface, and pins for specific models see AN2606Not all BOOT0 pulled high result in USART1 + USB DFU
RP2040 Pico BOOTSELROM entry can present virtual USB mass storage, receiving UF2Drag-and-drop UF2 does not equal USB DFU class protocol
nRF52 Software DFUCommon solution depends on the burned BootloaderCannot be written as all series having USB ROM DFU out of the box
AVR / PIC ProgrammingInterface selected by device and toolISP, ICSP, UPDI are not all the same six-pin protocol for AVR

STM32 entries may also be affected by option bytes, chip revision, and security configurations; check tables by exact part number. ST AN2606

Pico's BOOTSEL code is located in ROM; application Flash corruption usually does not overwrite this ROM, but it still depends on normal power supply, USB connection, and device state. Raspberry Pi Pico Documentation

Nordic's nRF5 SDK DFU tool requires the corresponding software Bootloader; newer software platforms also need configuration according to the upgrade solution used. Do not attribute the capabilities pre-installed on a dev board to all bare chips. Nordic nRF Device Firmware Update

Some newer Microchip AVRs use UPDI for programming and debugging, while PIC's ICSP has its own device protocols and entry conditions. Microchip AVR Interface

Download Time Must Separate Erase, Verify, and Transfer

At UART 115200 baud, 8N1, each byte requires 10 bits, with an ideal net byte rate of 11520 B/s. For a 256 KiB image, data transfer alone takes at least about 22.76 seconds, plus protocol headers, responses, retries, Flash erase/write, and verification. Increasing the serial baud rate cannot proportionally shorten the time dominated by internal erase/write; a USB connection does not mean burning is completed at the USB nominal bus bandwidth.

Image address, vector table/entry, link layout, Bootloader partition, and signature requirements must be consistent. After the tool reports writing is complete, distinguish between byte checksum passed, boot verification passed, and application function passed; these three events are not the same result.

When Connection Fails, Confirm Step-by-Step from the Layer with Fewest Dependencies

First verify target power and VTref, GND, interface direction, reset state, and host recognition of the probe, then verify transport selection, target configuration, and clock. Reducing debug speed can help judge connection quality, but cannot fix incorrect voltage or security locks.

If the application disables debug pins or enters low power after starting, try connecting under reset according to chip support; this requires a reset line and correct tool configuration, and not all devices support the same process. Read protection, authentication, and permanent security states should be handled according to vendor definitions; some recoveries erase data, some states are irreversible, and "unlock/full chip erase" should not be taken as the default action before preserving fault evidence.

After being able to halt, first confirm that the ELF matches the running image, then look at reset reason, PC, stack, and exception context. Having the same source code files is not enough; differences in optimization, link address, libraries, or build configuration can mislead judgment of variables and line numbers.

Bus troubleshooting combines logic analyzers and oscilloscopes: one ACK only indicates that a byte was received, not that data freshness, subsequent transactions, or electrical margins were always correct. Even if protocol decoding is normal, check levels, rise times, and power supply as needed; logic analyzers cannot alone rule out all physical layer issues.

Development, Production Line, and Field Organize Processes by Target

The development phase needs observability and recovery entries; the production line needs traceable images, verification, serialization, and functional testing; field upgrades need verification, compatibility, and power-loss recovery. Mass production can directly use dedicated programmers for batch burning, or use established download services, without being fixed to "first SWD burn Bootloader, then DFU."

OTA only indicates that the image arrived via wireless or network, not automatically providing authenticity and reliable switching. Receiving, verifying, writing to candidate area, startup confirmation, and failure recovery should form a clear state machine; read protection, signatures, and debug authorization are different mechanisms, and final configuration must align with product maintenance strategy.

Recalculate Transmission Lower Bound

from math import isclose
baud, bits_per_byte, image_bytes = 115200, 10, 256*1024
payload_rate = baud/bits_per_byte
assert payload_rate == 11520
assert isclose(image_bytes/payload_rate, 22.755555555555556)
assert isclose(image_bytes*8/1e6, 2.097152)
print('UART 8N1 effective byte rate and image pure transmission time lower bound passed')

Command examples are verified against official documentation; no debugger was connected, reset executed, Flash erased, or chip security state modified in this session.

Continue Reading