test(rp2350): complete RP2350(W) loopback driver and subsystem HIL

[zackees]

Context

Finish the RP2350 and RP2350W hardware bring-up on the currently available Pico 2 W fixture, using the existing AutoResearch/fbuild path and the board's soldered two-pin feedback bridge.

The 2026-08-18 inventory shows:

• historical RP2350W CDC identity: COM17, 2E8A:F00F, serial 2DCB876B587EA334; Windows currently reports this saved record as health=phantom selectable=no, so current physical enumeration still must be established;
• healthy Espressif peer: COM9, 303A:1001, serial 8C:BF:EA:CF:87:B4; the USB PID is shared, so firmware-level chip detection must confirm ESP32-C6 before peer tests;
• prior bench notes on feat(rp2350w): complete pin-free AutoResearch and ESP32-C6 peer-network bring-up #3832 and chore(rp2350w): hand off final #3832 hardware validation #3864 record the soldered bridge as GPIO0 (TX) -> GPIO1 (RX), but this run must confirm that mapping through live findConnectedPins/GPIO evidence before relying on it.

Most source-side RP2350W foundation work has landed: board/deploy support, PIO0/1/2 channel selection, serial RPC, watchdog recovery, CYW43 networking, peer HTTP/JSON-RPC, OTA staging, and btstack BLE transport. What remains is a single evidence-backed closeout of every driver and subsystem reachable with the attached hardware.

Proposal

1. Re-establish the RP2350W through fbuild port scan and the normal RP BOOTSEL/CDC deployment path. Do not pin a stale COM17 record; omit --upload-port unless multiple RP boards are actually present, or use UF2=<volume> if the board is deliberately in BOOTSEL.
2. Run GPIO-only AutoResearch with pin discovery and record the physically observed bridge. The historical GPIO0 -> GPIO1 note is a hypothesis until the current firmware reports it.
3. Validate both rp2350 and rp2350w profiles on the Pico 2 W so common silicon support and W-specific transports are separately covered.
4. Exercise every RP driver reachable with the discovered bridge through the public FastLED/Channels API where available:
   • PIO0, PIO1, and RP2350-only PIO2 clockless TX with PIO RX byte/edge evidence;
   • PIO0 + PIO1 simultaneous resource/concurrency behavior;
   • UART clockless output on any hardware UART route compatible with the discovered bridge (GPIO0 -> GPIO1 is UART0 TX/RX);
   • AUTO and BIT_BANG fallback behavior through the user-facing API;
   • arbitrary-pin PIO SPI if the harness supports capture on the bridge;
   • fixed-function SPI0/SPI1 and APA102/SK9822 only when the present wiring can form the required MOSI -> MISO route; otherwise record the exact pin incompatibility as not reachable in this fixture, not as a pass.
5. Complete the RP2350W-only gates already prepared by feat(rp2350w): complete pin-free AutoResearch and ESP32-C6 peer-network bring-up #3832: RPC smoke, IEEE-754, SIMD, watchdog/reconnect, RP dual-core concurrency, Wave2D, ESP32-C6 peer networking, BLE GATT, and peer OTA.
6. Preserve exact command/output evidence on this issue and update parent feat(rp2350w): complete pin-free AutoResearch and ESP32-C6 peer-network bring-up #3832 with the final matrix.

Acceptance criteria

• A focused RED -> GREEN repro is recorded for every source/harness gap discovered while enabling RP2350 HIL (including any RP2040-only CLI restriction that must be generalized).
• fbuild port scan records the live RP board identity/port and the healthy peer identity; firmware-level detection confirms the peer chip before ESP32-C6 use.
• AutoResearch live pin discovery reports the soldered pair and testGpioConnection proves LOW/HIGH feedback; no pin mapping is accepted from historical notes alone.
• The rp2350 and rp2350w build/deploy/serial RPC paths both pass on the attached Pico 2 W.
• PIO0, PIO1, and PIO2 each produce decisive byte/edge loopback evidence through the public driver path.
• PIO0 + PIO1 simultaneous execution passes without resource collision, stale state machine, or DMA ownership leak.
• Every UART, SPI, AUTO, BIT_BANG, and PIO-SPI path physically reachable with the discovered bridge is tested; every unreachable path is listed with the exact wiring/peripheral constraint.
• RP2350W RPC smoke, IEEE-754, SIMD, watchdog/reconnect, concurrency, and Wave2D gates pass or produce a concrete tracked implementation gap.
• RP2350W <-> ESP32-C6 peer HTTP/JSON-RPC, >=4 KiB payloads in both directions, ten reconnect cycles, BLE GATT, and OTA recovery pass when the peer is firmware-confirmed as C6.
• Closeout records the exact commands, commits, wiring, ports, VID:PIDs/serials, and decisive REMOTE:/RESULT: lines.
• No raw flasher, raw pyserial path, one-off sketch, host-WiFi switch, guessed register map, or unsupported-peripheral shim is introduced.
• Relevant lint, focused tests, RP2350/RP2350W builds, code review, PR delivery, and post-merge live rerun are complete.

Decisions

• Treat the attached Pico 2 W as both the RP2350 common-silicon DUT and the RP2350W transport DUT; this covers both profiles without pretending a second board exists.
• Keep this issue focused on live driver/subsystem completion; feat(rp2350w): complete pin-free AutoResearch and ESP32-C6 peer-network bring-up #3832 remains the parent for the broader pin-free/network work.
• Treat prior GPIO0 -> GPIO1 documentation as a lead only; live discovery is the authority for the current physical bridge.
• Count a driver as complete only with live feedback evidence through the normal API. Compile-only or raw peripheral evidence is supporting evidence, not closeout.
• Mark physically unreachable fixed-pin routes explicitly rather than changing soldered wiring or inferring success.

Open questions

• Which present USB node/BOOTSEL volume belongs to the Pico 2 W after the user-reported reattachment? The saved COM17 record is not currently present, so this must be resolved from a fresh scan/deploy result.
• Whether the current two-pin bridge permits any fixed-function SPI route depends on the live-discovered pins; the historical GPIO0/GPIO1 pair supports UART0 and arbitrary-pin PIO tests but not the canonical SPI0/1 MOSI -> MISO pairs.

Related issues

• feat(rp2350w): complete pin-free AutoResearch and ESP32-C6 peer-network bring-up #3832 — parent RP2350W pin-free, network, and hardware bring-up
• chore(rp2350w): hand off final #3832 hardware validation #3864 — prior final-HIL handoff, including GPIO0 -> GPIO1 wiring history and RP BOOTSEL guidance
• feat(rp2350w): add btstack BLE GATT transport #3861 — RP2350W btstack BLE GATT transport and pending live proof
• meta(rp2040): RX-first channel-driver bring-up — PIO capture, UART/PIO/SPI TX, and SPI LEDs #3647 — RP2040 RX-first PIO/UART/SPI driver bring-up precedent
• meta(rp2040): transport, channel-driver implementation, and postmortem closeout #3648 — RP2040 transport/channel-driver closeout precedent
• test(rp2040): GPIO, PIO, and LED loopback bring-up after headers are soldered #3631 — RP2040 GPIO/PIO/LED loopback hardware precedent
• Support for Raspberry Pi Pico 2 - RP2350 #1673 — original Pico 2/RP2350 support
• meta: handoff — port diagnostics (#1279) and RP2350W HIL context fbuild#1282 — RP-series attachment/phantom-port handoff guidance

[zackees]

Hardware status update (2026-08-18):

• PR test(rp2350): enable RP2xxx driver validation #3901 is merged and supplies RP2350(W) fixed-SPI support, indexed UART/PIO AutoResearch selection, deferred USB-detection normalization, UART affinity/metadata fixes, tests, and documentation.
• The current fbuild port scan still reports the saved RP2350 application endpoint as phantom/non-selectable COM17; there is no RPI-RP2 BOOTSEL volume.
• Windows PnP topology confirms that endpoint was last removed on 2026-08-01. Its two parent USB hubs are currently healthy and present, but the endpoint itself is not present.
• The currently present Code 43 USB node is on a different root-port path and has a different container ID, so it cannot be attributed to this RP2350.

Consequently there is still no live evidence for the bridged GPIO pair, and no RP HIL result is being claimed from historical GPIO0/GPIO1 notes. Remaining acceptance is blocked until the Pico 2 W is reconnected as either application CDC or RPI-RP2 BOOTSEL; then pin discovery and UART/PIO/SPI/concurrency validation can resume.

[zackees]

Progress update after the attached-board investigation and merged tooling/driver work:

• Electrically identified the two-pin bridge as GPIO0 <-> GPIO1, verified in both directions.
• Canonical AutoResearch loopback passed on PIO0, PIO1, and PIO2 using TX GPIO1 -> RX GPIO0.
• The bridge is compatible with UART0 (TX GPIO0 -> RX GPIO1). UART1 is not routable to this bridge, and neither fixed SPI controller exposes a compatible TX/RX pair on GPIO0/GPIO1, so those modes are not physically testable with the supplied wiring.
• FastLED PR test(rp2350): enable RP2xxx driver validation #3901 added the RP2350 validation surface and merged as dd19c066f1.
• fbuild PR fix(rp): complete Arduino-Pico board resolution fbuild#1301 added the common/family RP platform handling and was released as fbuild 2.5.17.
• FastLED PR Fix RP2350W UART diagnostics and validation #3907 fixed the RP UART default receive sizing, preserves specific startup failures, exposes typed UART startup diagnostics through AutoResearch, pins fbuild 2.5.17, and adds regression coverage. It merged to master as 9e5fa8ab92.
• Validation is green: affected Python suites 193 passed, targeted RP UART C++ test passed, full C++ suite 279/279 plus 84/84 examples passed, lint passed, and pre-push review was clean.

Remaining hardware blocker: the RP2350W stopped enumerating before the final UART0 diagnostic rerun. Released fbuild 2.5.17 reports stale/unselectable COM18, and Windows reports an unidentified USB device at Port_#0014.Hub_#0001 with problem code 43 (descriptor request failure). Replug/BOOTSEL/reset attempts have not produced either a normal serial endpoint or PICOBOOT endpoint. No deploy/reset was attempted against the stale port.

The issue should remain open until the board enumerates again (or is replaced) so UART0 and the remaining pin-free/peer-capable acceptance modes can be completed with physical evidence.