app

AI Flow

Public Made by Adom

by adom

Adom's AI Flow: a tool to help the AI follow all of the steps it takes to build a board.

kicadpcbedaroutingplacementcopper poursablationcurrent densitythermalkelvincomparison
Overview Files Skills Discover Packages Releases Dependencies Issues10 Breadcrumbs Pull Requests Activity
Closed PR #65 released in 0.2.51 on 4 Nov 2026 bug report

Programming check needs explicit native USB Serial/JTAG cable access without robot contacts

matt · ·closed by John Lauer

AIFlow0.2.30 assumes every programmable board uses SWD/UART-boot/USB-DFU robot contacts. An ESP32-S3 using its native USB Serial/JTAG connector has a different valid service path. Requiring robotic contacts or falsely declaring DFU misrepresents that board.

Attached isolated contextual patch adds an explicit interface usb-serial-jtag with access usb-cable. It verifies the real USB connector footprint, each declared connector pad/net, four distinct data/ground/VBUS nets, actual ESP32 target reference/MPN and boot instructions. Ordinary robotic-contact checks remain unchanged. This is connectivity/access metadata validation; it does not claim an end-to-end circuit check, USB power compliance or successful hardware programming. Separate native schematic/PCB membership and bench checks remain required.

Regressions reject wrong pad net, wrong connector and wrong target. Release build and full isolated workspace passed514tests,0failures,9existingignored. The source baseline is fbc027548dbb4207be1107e9e9bdf2628e0663e9 with previously reported local fixes; this attachment changes only programming.rs and generic tests. No private board data, installed runtime or pinned bridge was changed. Actual manual USB programming remains untested until assembly.

usb-cable-programming.patch

1 Reply

John Lauer ·

Merged your patch in adom-aiflow 0.2.36 (on top of Colby's 0.2.35). Thank you.

You're right: an ESP32-S3 programmed through its own USB connector over native USB Serial/JTAG has a real service path, and AI Flow only knew robot contacts. A board now declares "interface": "usb-serial-jtag", "access": "usb-cable". The check then confirms:

  • connectorPins D+, D-, GND and VBUS each name pads that carry the declared net;
  • they are four distinct nets;
  • targetRef/target match the ESP32 on the board;
  • boot instructions are present.

Robot-contact interfaces are unchanged.

One change from your patch: it also required the connector's reference to start with J and its library name to contain "usb". A correct board with USB1 or CN1, or a project-library footprint like MyLib:TypeC_16P, would have failed on its name alone. The pad-to-net mapping you already check is the real evidence. So the connector now only has to exist on the board and not be the target chip. A wrong connector still fails, because its pads won't carry the four nets. Your three regressions pass, plus a new one for a renamed connector. The workspace has 521 tests.

The record format is documented in the aiflow-molecule skill beside swd, uart-boot and usb-dfu. As you said, this is connector-mapping evidence, not a programming test: the native gate and the bench stay the proof.

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

John Lauer closed this ·
Drew Owens mentioned this in pull request #65 ·

Log in to reply.