chore(rp2350): deploy-only bring-up on attached Pico 2 W

[zackees]

Target

Deployment-only bring-up for the attached Pico 2 W-compatible board sold by the SUUOO Store:

• RP2350, dual-core Cortex-M33 / Hazard3 RISC-V
• 4 MB flash, 520 KB SRAM
• 2.4 GHz Wi-Fi / Bluetooth 5.2
• pre-soldered headers
• observed runtime identity: 2E8A:F00F, serial 2DCB876B587EA334, currently COM17

This is Pico 2 W, not Pico 2 and not RP2040. A separate RP2040 happens to be mounted as G: / RPI-RP2; it is not a bring-up target and must remain untouched.

Scope

This issue proves only that fbuild can compile a board-correct artifact and deploy it repeatedly to this RP2350 target. The onboard LED blink is a visible firmware acceptance witness, not an LED-driver or GPIO validation exercise. Wi-Fi, Bluetooth, serial/RPC, watchdog, PIO/SPI, and FastLED data output are out of scope.

All flashing must go through fbuild deploy. Do not invoke picotool directly or copy a UF2 manually.

Lessons applied

• Use Arduino-Pico's rpipico2w variant and ARDUINO_RASPBERRY_PI_PICO_2W board define.
• Preserve Arduino-Pico's standard ARDUINO_ARCH_RP2040 core contract; identify the silicon with PICO_RP2350 / TARGET_RP2350.
• Enable the Pico 2 W CYW43 board wiring (PICO_CYW43_SUPPORTED, CYW43_PIN_WL_DYNAMIC); its onboard LED is routed through the wireless chip rather than a normal RP2350 GPIO.
• Source runtime USB identities from the FastLED/boards registry. Do not embed VID/PID literals in fbuild's board snapshot.
• Select the target by its exact healthy CDC endpoint so pre-existing BOOTSEL volumes cannot capture the deployment.
• Accept canonical RP2350 UF2 images containing the RP2350-E9 absolute errata block while retaining family, sequence, range, and overlap checks.

Plan and acceptance

• Add the bundled rpipico2w profile and Pico 2 W/2 WH aliases.
• Build a deterministic blink artifact with --no-timestamp and record its path, size, and SHA-256.
• Deploy only through fbuild deploy --transport uf2 --skip-build to the exact Pico 2 W CDC endpoint.
• Confirm the same RP2350 serial re-enumerates healthy as 2E8A:F00F / COM17.
• Repeat the same-artifact deployment without stale handles or unbounded waits.
• Verify the unrelated G: RP2040 volume has identical identity, capacity, and free space before and after the final deployment.
• Operator confirmed that the Pico 2 W onboard LED blinks at the expected cadence.
• Preserve tests, review results, commands, artifact hash, and hardware identity in the linked PR.

Related work

• feat(rp2040): deploy parity with Arduino-Pico, PlatformIO, and official picotool #1049 ? RP deploy parity and safety
• harden(rp2040): deploy robustness across host setups (hub chains, drive-scan stalls, timeout policy) #1082 ? hub, retry, and timeout hardening
• feat(rp2040): make PICOBOOT/picotool a first-class transport and the primary automatic deploy path #1162 ? PICOBOOT/picotool transport
• feat(rp2040,windows): preflight PICOBOOT WinUSB driver binding and classify code-28 failures #1163 ? Windows PICOBOOT driver preflight

[zackees]

Bring-up update from PR #1235 (204ea2e7; baseline 3e9dc5ccd0ce11c29b4f079a0166e9f175d704f8, fbuild 2.5.5 in dev mode):

• Frozen artifact: tests/platform/rpipico2/.fbuild/build/release/firmware.uf2, 165888 bytes, SHA-256 56F4B1395F8643427F7D1F64C695D804008052EBB417A7CCC1F254B426CE98CA.
• Board identity: RP2350 ROM 2E8A:000F, serial 2DCB876B587EA334, BOOTSEL H: (Board-ID: RP2350), runtime COM15.
• Safe ambiguity proof:
  fbuild deploy tests/platform/rpipico2 -e rpipico2 --skip-build --transport uf2 --no-admin -v
  failed before writing with found multiple RP2040 BOOTSEL volumes: G:\, H:\; pass an explicit UF2 volume path to select one.
• First exact-device deploy:
  fbuild deploy tests/platform/rpipico2 -e rpipico2 --skip-build --transport uf2 --port 'uf2=H:\' --no-admin -v
  succeeded in about 10.5 s; H: ejected, G: remained mounted, and the same serial returned healthy as COM15.
• Runtime-path proof:
  fbuild deploy tests/platform/rpipico2 -e rpipico2 --skip-build --transport uf2 --port COM15 --no-admin -v
  completed three consecutive times. Each cycle excluded pre-existing G:, attributed newly appearing H:, accepted the transfer, and returned serial 2DCB876B587EA334 on healthy COM15; no stale handle or unbounded wait occurred.
• Root cause fixed: canonical picotool RP2350 UF2s begin with an RP2350-E9 absolute block (family 0xE48BFF57, address 0x10FFFF00) before RP2350 Arm-S blocks (0xE48BFF59). The old validator rejected block 0. Validation now permits exactly the canonical special block, still requires RP2350-family blocks, validates independent numbering, and rejects overlap.
• Mixed-board safety fixed: a resolvable runtime target now treats all mounted BOOTSEL volumes as pre-existing/stale, so unrelated G: cannot win over selected COM15.
• Validation: 261 deploy-crate tests passed (13 hardware tests ignored), rustfmt clean, targeted clippy clean, pre-push review clean.

Still pending before issue closeout: physically remove/reboot the unrelated RP2040 out of G: so the default picotool path can be exercised without ambiguous PICOBOOT devices, plus human visual confirmation that the deployed onboard-LED blink is visible. No monitor/RPC/GPIO/driver claim is being made.

PR: #1235

[zackees]

Correction and final deploy evidence: the attached target is a Pico 2 W-compatible RP2350 board, not a Pico 2 and not an RP2040.

The board-correct rpipico2w artifact is 688128 bytes with SHA-256 A8E72528E1ED030D202B2D45EDCB397132545644F33D8DB6F08D879B153236A7. The final deployment was run through fbuild deploy against exact target COM17; serial 2DCB876B587EA334 returned healthy as 2E8A:F00F on COM17.

The separate RP2040 on G: was not targeted. Before and after the final deploy it retained volume ID \\?\Volume{67245f76-7fb6-11f1-bc34-5cf3709c9d87}\, size 134066176, and free space 134037504.

Automated build/deploy acceptance is green. The only remaining hardware acceptance item is operator visual confirmation of the Pico 2 W onboard LED blink cadence.

[zackees]

Hardware acceptance complete: the operator visually confirmed that the attached Pico 2 W onboard LED is blinking at the expected cadence after the final fbuild deploy to COM17 (2E8A:F00F, serial 2DCB876B587EA334).

Verdict: PASS for the deployment-only RP2350/Pico 2 W bring-up. This confirmation is a visible firmware witness only; it does not expand the issue into LED-driver, GPIO, Wi-Fi, or Bluetooth validation.