Skip to content

fix(rp): bind picotool deployment to the selected RP device #1259

Description

@zackees

Problem\n\nRP deployment currently opens the selected healthy runtime CDC port for the 1200-baud BOOTSEL touch, but the default managed picotool commands are unscoped: picotool info and picotool load -f -x receive no --ser, --vid, or --pid selector. With multiple RP boards, a post-touch picotool operation can therefore select an unintended bootloader/runtime device. The force flag also allows picotool to reset a compatible runtime target without proving the intended BOOTSEL handoff.\n\nThe RP2350 Windows preflight additionally recognizes only RP2040 BOOTSEL PID 2E8A:0003, while RP2350 BOOTSEL is 2E8A:000F; it consequently does not classify a broken RP2350 PICOBOOT devnode before attempting picotool.\n\n## Fix\n\n- Carry the selected runtime USB serial and expected ROM VID/PID into every picotool probe/load.\n- Require an identity-bound BOOTSEL picotool path; unidentifiable/manual recovery stays on the explicit mass-storage path.\n- Remove -f from the post-touch picotool load, retaining -x only after BOOTSEL is selected.\n- Make Windows PICOBOOT preflight family-aware for RP2040 and RP2350.\n\n## Evidence\n\nThe attached RP2350W runtime CDC is 2E8A:F00F, serial 2DCB876B587EA334, but Windows currently reports it phantom with root-hub Code 43. fbuild correctly refuses to touch that stale COM record. The deployer hardening prevents a future healthy-target deployment from using an unscoped picotool transfer and surfaces the RP2350 ROM driver fault before a long tool timeout.

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