Skip to content

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

Closed

Description

@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

Activity

  1. zackees commented on Aug 2, 2026

    @zackees
    MemberAuthor

    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

  2. changed the title [-]chore(rp2350): deploy-only hardware bring-up on attached Pico 2[/-] [+]chore(rp2350): deploy-only bring-up on attached Pico 2 W[/+] on Aug 2, 2026
  3. zackees commented on Aug 2, 2026

    @zackees
    MemberAuthor

    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.

  4. zackees commented on Aug 2, 2026

    @zackees
    MemberAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions