usb connection prefers the pod's USB network adapter (fw 3.9.0+) by wardviaene · Pull Request #34 · embeddedci-com/embeddedci-python

wardviaene · 2026-10-13T01:54:19Z

Goes with embeddedci-com/benchpod-firmware#47 (firmware 3.9.0: the pod's USB port is also a CDC-NCM network adapter) and #48 (the console trim).

What is in it

SDK usb: finds the console as before. When its status reports the USB network on and up, and port 8080 answers, it returns a TcpTransport to the pod's 10.237.x.y address (transport.usb_console names the console). Otherwise it keeps the console. An explicit device path stays the console.
usb:<name> selects one of several USB pods by identity (usb:benchpod-baea06). Plain usb with several pods raises an error listing them.
Discovery: discover() keeps every address a pod answers from, and DiscoveredPod.addr prefers the USB link (new on_usb).
USB IDs: POD_VIDS gains 0x1209 (pid.codes; PID 0001 is the test ID until ours is assigned). 0x0483 and 0x2E8A stay.
Console status: parse_text_status parses the console's usb line.
3.9.0 console: the serial transport recognizes the console's "moved to the network API" answer for la-voltage/power and raises an error that says to connect with usb or the pod's address. A plain unknown command still means firmware too old, as before.
MCP:
- kind usb_net, and the guide/connect text for usb and usb:<name>;
- status warns when the USB-C port offers only default power (500 mA); the MCP e2e ignores that one warning;
- power_status already shows the pod's own draw (pod, total_current) on boards with the 0x41 monitor.
examples smoke test: waits up to 0.5 s for the DUT rail. Over USB a round trip is ~10 ms and the rail takes ~20 ms.
Docs: SDK, MCP and OpenHTF READMEs and CHANGELOGs. That includes the compatibility table and Windows 10 (1903+) supported but not tested, with the "UsbNcm Host Device" fallback.

Backward compatibility

The SDK decides per pod from its console status, never from its own version.

	Firmware before 3.9.0	Firmware 3.9.0+
This SDK	`usb` = console, as before.	Full API over the USB network.
SDK 2.11.x	Unchanged.	`usb` = console. Status and ping work. LA voltage and power show the pod's "moved ... update" line.

Tests

make test: embeddedci 655 passed, mcp 157, openhtf 74, scripts 12.
HW on baea06 (macOS):
- BenchPod("usb") and usb:benchpod-baea06 give TcpTransport; an unknown name lists the pods found;
- discovery picks 10.237.8.85 over 192.168.1.220;
- a console device path on the trimmed firmware gives the new error.
e2e over --benchpod-connection=usb: SDK e2e, examples and MCP e2e gave 124 passed, 50 skipped (no DUT firmware) and 1 failure. That failure was the smoke-test timing race, fixed here.
Server Go hwe2e over the USB address: 69 passed, 4 skipped, 0 failed.

🤖 Generated with Claude Code

Auto-detected USB pods: read the console status, and when its usb line says net on + link up and <pod ip>:8080 accepts a TCP connect within 1.5 s, return a TcpTransport to it (usb_console = the console's device path). Otherwise keep the SerialTransport as before. An explicit device path is never upgraded. VID 0x1209 (1209:0001, fw 3.9.0) ranks as a pod port; parse_text_status turns the usb line into the JSON status shape. Docs + changelogs + unit tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Guide, connect description, README and changelog: on firmware 3.9.0+ 'usb' uses the pod's USB network adapter (off while Wi-Fi is configured); a serial device path is the console only. connect/status report kind 'usb_net' when the SDK picked the USB network. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Over the USB network a round trip is ~10 ms (LAN ~17 ms) and the rail needs ~20 ms to reach 4.9 V, so the immediate read caught it mid-ramp (2.25 V, 3.17 V). Poll up to 0.5 s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

wardviaene · 2026-10-13T01:55:22Z

HW e2e over --benchpod-connection=usb on baea06 (fw usb-net 26939d1, macOS; SDK e2e + examples + MCP e2e): 124 passed, 1 failed, 50 skipped (no DUT firmware passed). The failure was examples/test_smoke.py::test_target_power_switches reading the DUT rail mid-ramp: USB round trips are ~10 ms against ~17 ms on the LAN, and the rail needs ~20 ms. Fixed in 975f9de (poll up to 0.5 s); it passes over both USB and Ethernet now.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A pod advertises on each of its interfaces, and an update from a second interface replaced the first entry's addresses. Merge them, and make DiscoveredPod.addr prefer the USB network link (10.237.0.0/16). New on_usb. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Mirrors benchpod-cli: auto-detect reads each pod's identity short id from its console (`identity`). usb:<name> (baea06, benchpod-baea06, any case, optional .local) opens that pod and upgrades to its USB network as before; plain usb keeps probing the pod-VID ports after the first pod and errors listing both when it finds two. One pod's macOS cu/tty twins count once. MCP classifies usb:<name> as serial (usb_net when upgraded); docs updated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Firmware 3.9.0 reports what the USB-C source advertises (status.usb.source). default (500 mA) may not carry the pod plus a DUT on the internal 5 V rail, so status says so. The MCP e2e ignores that one warning (bench pods sit on computer ports). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

wardviaene · 2026-10-13T02:19:16Z

Added since the first push:

mDNS discovery: keeps every address a pod answers from, and DiscoveredPod.addr prefers the USB link. HW: both addresses heard, 10.237.8.85 picked.
usb:<name> selects one of several USB pods (SDK and MCP). HW: usb:benchpod-baea06 gives TcpTransport, and an unknown name lists the pods found.
MCP status: warns when the USB-C port powering the pod offers only default power (500 mA). The MCP e2e ignores that one warning.
Server Go hwe2e over the USB address: 69 passed, 4 skipped, 0 failed.

Firmware 3.9.0 moves la-voltage and power from the USB console to the JSON API. Over an explicit console device the SDK then says to connect with usb (the USB network adapter) or the pod's network address instead of reporting an unexpected reply. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…y table Firmware 3.9.0 answers console commands it moved to the JSON API with a moved-to-the-network-API line; the serial transport raises the connect with usb error for that line only (an unknown command still means firmware too old, as before). README: SDK x firmware compatibility table, Windows 10 supported but not tested, with the UsbNcm Host Device fallback. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

On firmware 3.9.0+ with Wi-Fi configured (USB networking off) or the adapter down, the trimmed console has no LA voltage or power. Connection usb now uses the pod's Ethernet or Wi-Fi address from the console status when it answers on :8080, logs a warning naming it (the external LAN policy applies there; clear-wifi turns USB networking back on), and sets TcpTransport.usb_lan_fallback. Firmware before 3.9.0 keeps the console. MCP: kind tcp and a status warning for that case. Tests and README table. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…le error With the external LAN policy off the pod accepts a TCP connection and resets it, so the LAN fallback now checks a JSON ping answers, not just a connect. The 3.9.0 console error names clear-wifi and the external LAN policy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

wardviaene · 2026-10-13T03:32:44Z

Added: LAN fallback for usb (SDK + MCP). On firmware 3.9.0+ with USB networking off or down, usb returns a TcpTransport to the pod's Ethernet/Wi-Fi address from its console status when a JSON ping answers. It logs a warning naming the address and sets transport.usb_lan_fallback (why). The MCP reports kind tcp and a status warning. Firmware before 3.9.0 keeps the console. HW on baea06 (trimmed #48 firmware, Wi-Fi set): BenchPod("usb") gave TcpTransport 192.168.1.220:8080 and read the LA voltage. With the external LAN off it stayed on the console and the error now names clear-wifi and the LAN policy.

…in the USB SDK The MCP server's and the OpenHTF plug's docs now say 'usb' reaches the full API over the USB network adapter, which only embeddedci 2.12.0 does: both require it (were >=2.9 and >=2.4). The mcp-min-sdk CI job installs the minimum from PyPI; while that minimum is the version this repository is about to release, it tests the in-repo SDK instead. Release order: publish embeddedci before embeddedci-mcp and embeddedci-openhtf, then rebuild the benchpod-mcp plugin (uvx caches, .mcpb bundle). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The STM32 pod's console never had a json mode (that was the retired RP2350 firmware), yet every serial open could wait up to 3 s probing for it. JSON goes over the network, also over USB through the USB network adapter; the serial transport is now the text console only. Tests for the old mode go; the unplugged and silent console tests move to the text-console fixture, plus a test that no json switch is ever sent. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The console tier set the LA voltage over the console at open; firmware 3.9.0 moved that to the JSON API, so every test errored. It now detects 3.9.0 from the console status's usb line, expects the network-command error for LA voltage and power there, and runs the old checks on older firmware. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Firmware 3.9.0 takes cloud_ca and cloud_proxy changes over the USB network adapter as well as the console, so the refusal on Ethernet/Wi-Fi now reads "<verb>: change it from the cloud or over USB". sig_policy and lan_policy keep "... or the USB console". Host tools accept both texts (older firmware). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Under external LAN policy locked, firmware 3.9.0 still takes T2/T3 commands over its USB network adapter, so the refusal on Ethernet/Wi-Fi now reads "locked: <cmd> needs the cloud or USB". Host tools match the "locked:" prefix; hwe2e accepts both texts (older firmware). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

25 events at 0.2 s ran past the 4 s capture; the late ones queued behind the read-back and went out back to back, and over the USB network one arrived while the previous 1 ms step train still held the pin (pin conflict, 5/5 over USB, never over Ethernet). 18 events end at ~3.8 s, as the ADC sibling test already does. Now 3/3 over USB, 2/2 over Ethernet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

On Linux the console (/dev/ttyACM0, root:dialout 0660) is closed to users outside the dialout group, so 'usb' never reached the USB network adapter there. The SDK now reads this computer's interfaces (getifaddrs): one /30 in 10.237.0.0/16 names the pod's address with no console; usb:<name> picks among several links by identity_public. TcpTransport.usb_net marks a USB network transport; MCP reports usb_net for it. Found in the 3.9.0 Linux e2e run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

wardviaene and others added 3 commits October 12, 2026 20:42

examples smoke: import order

f3db288

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

wardviaene mentioned this pull request Oct 13, 2026

Firmware 3.9.0: USB network adapter, external LAN policy, trimmed console embeddedci-com/benchpod-firmware#47

Merged

wardviaene and others added 3 commits October 12, 2026 21:05

wardviaene mentioned this pull request Oct 13, 2026

Console trim: physical presence and recovery stay, instrument commands are JSON-only embeddedci-com/benchpod-firmware#48

Merged

wardviaene and others added 3 commits October 12, 2026 21:47

wardviaene and others added 2 commits October 12, 2026 22:36

wardviaene mentioned this pull request Oct 13, 2026

benchpod 0.6.0: USB network for firmware 3.9.0, usb-bridge service, compatibility embeddedci-com/benchpod-cli#27

Merged

wardviaene and others added 6 commits October 12, 2026 23:09

docs: two pods on one computer are not tested on hardware yet

375ca53

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

wardviaene merged commit 7449c44 into main Oct 13, 2026
20 checks passed

wardviaene mentioned this pull request Oct 13, 2026

usb_network(): the pod's USB network setting in the SDK and MCP #35

Merged

Navigation Menu

Repository navigation

usb connection prefers the pod's USB network adapter (fw 3.9.0+) - #34

usb connection prefers the pod's USB network adapter (fw 3.9.0+)#34
wardviaene merged 19 commits into
mainfrom
usb-net

wardviaene commented Oct 13, 2026 •

edited

Loading

Uh oh!

wardviaene commented Oct 13, 2026 •

edited

Loading

Uh oh!

wardviaene commented Oct 13, 2026

Uh oh!

wardviaene commented Oct 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

wardviaene commented Oct 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is in it

Backward compatibility

Tests

Uh oh!

wardviaene commented Oct 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wardviaene commented Oct 13, 2026

Uh oh!

wardviaene commented Oct 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

wardviaene commented Oct 13, 2026 •

edited

Loading

wardviaene commented Oct 13, 2026 •

edited

Loading