Skip to content

openocd

On-chip debugging and in-system programming over JTAG and SWD

What it does

Speaks JTAG and SWD to a target chip through a debug adapter, exposing a GDB server and a telnet console. It is the layer between a probe — an ST-Link, a CMSIS-DAP, an FTDI-based adapter — and the debugger or flashing tool you actually type at.

Why you would want it

It is the free implementation everything else assumes. A vendor IDE will flash the vendor's own board; openocd flashes whatever you have, from whatever host, and is what makes a five-pound probe interchangeable with a two-hundred-pound one.

Before it will work

A debug adapter and a configuration naming it and the target. Access comes from the programmer hardware class — plugdev and dialout — and openocd ships its own udev rules covering 100 identifiers, the largest set of the five programmer packages.

How it installs

  • apt: openocd

Known problems

Its configuration is two files that must agree: an interface config for the probe and a target config for the chip. A mismatch reports as a failed handshake and looks identical to bad wiring.

It also claims `0403:6001`, `0403:6010`, `0403:6014` and `0403:6015` —

generic FTDI bridges. 0403:6001 is one of only two identifiers libhamlib4t64 claims, so on a station that does both, openocd's access rule and the rig-control cable are the same device to the kernel. See the programmer class.

Keeping it current

  • probe: apt policy
  • strategy: apt_upgrade

Source: catalog/packages/openocd.yaml