Skip to content

test(rp2040): controlled PICOBOOT-only hardware validation with the #1161 pinned artifact #1165

Description

@zackees

Goal

Once the #1161 board re-enumerates (currently USB-bricked; requires physical BOOTSEL/replug), run a controlled PICOBOOT-only load to cleanly isolate the observed write-stall failure to the mass-storage deployment path — and to validate the PICOBOOT-primary transport flip (sibling sub-issue) before it ships as the default.

Pinned artifact (do not rebuild between runs)

  • Size: 882,688 bytes
  • SHA-256: 1C770999678BB7563A81D36C696DC44C074A712E25F0DE68A8A83F859E8AF0E0
  • 1,724 UF2 blocks of 512 bytes, RP2040 family ID 0xE48BFF56, target 0x100000000x1006BB00

Preconditions

Procedure

  1. Board in BOOTSEL, enumerated as 2E8A:0003.
  2. picotool info probe — record output.
  3. picotool load <pinned.uf2> -x (add -f only if starting from application mode) — via the fbuild-managed picotool so the tested binary matches what fbuild ships.
  4. During the load: confirm no access to the RPI-RP2 volume (no open handles on G:), and monitor the System event log for new Disk 51/153 events.
  5. Verify application re-enumeration and running firmware.

Interpretation

Part of the meta issue tracking the #1161 transport strategy change. Defaults chosen by the drafting agent are listed inline — edit as needed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status
    Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions