feat(rp): add SWD/probe-rs deploy transport so a non-enumerating RP board is still flashable

[zackees]

Problem

Both RP deploy transports require a live USB endpoint on the target:

--transport <TRANSPORT>  RP2040 deploy transport: `picotool` (default, PICOBOOT-primary)
                         or `uf2` (mass-storage primary, historical order)

picotool needs the PICOBOOT vendor interface; uf2 needs the BOOTSEL mass-storage volume. A board whose firmware wedges before or during USB bring-up presents neither. There is no endpoint to talk to, so fbuild deploy cannot reach it at all.

This is not recoverable from the host. FastLED#3714 worked the problem end to end on a Windows bench and exhausted every software path — elevated pnputil /restart-device, Disable-PnpDevice/Enable-PnpDevice with 3 s and 10 s windows, pnputil /scan-devices, 1200-baud touch, picotool reboot -f -u. The decisive constraint: a root-hub port restart is a USB bus reset, not a VBUS power cycle. Desktop root hubs never cut VBUS, so a wedged RP never re-runs its ROM bootloader. Recovery currently requires a physical action — BOOTSEL-hold power cycle, cable swap, or an SWD probe.

That makes unattended RP bring-up impossible to guarantee: one bad flash strands the board until a human walks over.

Why this is worth doing here

fbuild already has the plumbing. The LPC probe-rs work shipped (#1000, #935), including the fork that replaced hidapi with nusb for CMSIS-DAP v1 HID transport (#936). An RP SWD backend is a new target for existing infrastructure, not a new capability from scratch.

SWD is also the only path that can answer why a sketch bricks USB — halt the core and get a backtrace, instead of inferring from the outside.

Proposal

Add an SWD deploy backend for RP2040/RP2350 via probe-rs, selectable as a third transport:

fbuild deploy -e rp2040 --transport swd

• Target a CMSIS-DAP probe (Raspberry Pi Debug Probe, ~$12, already supported by the existing CMSIS-DAP transport).
• Chip targets RP2040 and RP2350 are both in probe-rs's built-in target registry.
• Flash + verify + reset with zero dependence on the target's USB.
• Reasonable fallback order when a probe is present: try USB transports first (they need no extra hardware), fall back to SWD when the target does not enumerate — so a wedged board self-heals on the next deploy instead of blocking.

Scope notes

• Probe presence should be detected, not assumed; absent a probe, behavior is unchanged.
• This is complementary to, not a replacement for, the device-side escape in FastLED#4167 (after N consecutive watchdog resets the board reboots into the bootloader). That handles firmware that still runs; SWD handles firmware that does not.
• The other half of unattended recovery is a per-port-power-switching hub (uhubctl -a cycle) for a true VBUS cycle. That is bench hardware, out of scope for fbuild, and tracked in FastLED#3714.

Context

• FastLED#3713 — RP2040 board fails USB enumeration, recover & flash with no intervention
• FastLED#3714 — bench host setup for unattended deploy & recovery; item C is this exact suggestion ("an rp2040 probe-rs backend in fbuild deploy, like the existing LPC probe-rs path, would fold this into the standard flow — candidate for a FastLED/fbuild issue")
• FastLED#4167 — device-side boot-loop escape to the bootloader

Filed from an unattended FastLED bench run where the RP2350 is not enumerating and therefore cannot be reached by any current transport.

Generated with Claude Code

https://claude.ai/code/session_01KkufoNxfnNRU9psT3R9F51