finish: programming check has no record for an SWD cable header (STDC14, ARM-10)

Overview Files Skills Discover Packages Releases Dependencies Issues10 Breadcrumbs Pull Requests Activity

Closed general

noah · 7d ago ·closed by John Lauer

Version: adom-aiflow 0.2.56 (local build 0.2.56+noah.1), KiCad lane.

What I ran: finish on a board (not a molecule) whose STM32G0B1 is programmed through J7, a 14-pin STDC14 header (Samtec FTSH-107) for the ST-LINK V3 cable: SWDIO J7.4, SWCLK J7.6, NRST J7.12, GND J7.5/7/11, VTref J7.3.

What happened: with "pins": {"SWDIO": "J7.4", ...} finish says programming: GND: J7.5 is not on the board; NRST: J7.12 is not on the board; .... With the connector form ("connector": "J7", "access": "cable", "connectorPins": {...}) it says programming: pins.SWDIO missing; pins.SWCLK missing; pins.NRST missing; pins.GND missing. The check only knows machine contacts, labelled test pads, Tag-Connect footprints and a USB cable.

Expected: an SWD (or UART) cable header is a normal way to program a board: accept "access": "cable" (or "header") with connector and connectorPins, checked like the Tag-Connect record (the pads carry SWDIO, SWCLK, GND and NRST, and the SWD nets reach the target).

Workaround: deviate "programming" --why ....

1 Reply

John Lauer · 5d ago

Thanks Noah. You're right: an SWD cable header is a normal way to program a board, and the check had no record for it.

What was wrong. The programming check knew four landings: machine contacts, labelled test pads, a Tag-Connect footprint ("access": "tag-connect", SWD only) and a USB cable for an ESP32. A record with "access": "cable" fell through to the plain pins form, which wants each pin to be a reference. So you got pins.SWDIO missing for the connector form and J7.5 is not on the board for "J7.4" style pins.

What changed in adom-aiflow 0.2.58.

"access": "cable" or "header" with connector and connectorPins is checked like the Tag-Connect record. The declared pads must carry the declared nets, the nets must be distinct, and every signal net except GND must reach the part being programmed.
This works for swd (SWDIO, SWCLK, GND, with NRST checked when you declare it), uart-boot (TX, RX, GND) and updi (UPDI, GND, building on the UPDI support from PR #73).
targetRef can be left out when the board has one programmable part, or when target names it.
Your first form now works too. "pins": {"SWDIO": "J7.4", "SWCLK": "J7.6", "NRST": "J7.12", "GND": "J7.5"} (pads of one connector) is read as the same cable header, with each pad's net taken from the board.
The finish item, the hint and the aiflow-molecule skill describe the header record. finish lists a problem as an open item and never refuses.

For your board:

"programming": {"interface": "swd", "access": "cable", "connector": "J7", "target": "STM32G0B1...",
  "connectorPins": {"SWDIO": {"pads": ["4"], "net": "SWDIO"}, "SWCLK": {"pads": ["6"], "net": "SWCLK"},
                    "NRST": {"pads": ["12"], "net": "NRST"}, "GND": {"pads": ["5", "7", "11"], "net": "GND"}}}

VTref (J7.3) is not required, so you can leave it out.

How it was verified. New unit tests build an STDC14 (FTSH-107) header on an STM32 board. They check the connector form with cable and header, the "J7.4" pins form, a pad that does not carry its net, an SWCLK pad wired to GND (net GND does not reach U1) and a UART header missing RX. The new workflow suite runs finish on such a board and gets programming: U1 STM32G0B1CBT6, interface swd with declared access checked. All existing programming tests (Tag-Connect, USB cable, UPDI) still pass.

Still open. Nothing for this issue. You can drop the deviation once you're on 0.2.58.

Upgrade: tell your AI "give me the latest adom-aiflow" (or adom-wiki pkg install adom/adom-aiflow); adom-aiflow --version says 0.2.58.

John Lauer closed this · 5d ago