Skip to content

fix(rp): bind picotool deployment to the selected device - #1260

Merged
zackees merged 1 commit into
mainfrom
fix/rp-picotool-target-binding
Aug 6, 2026
Merged

fix(rp): bind picotool deployment to the selected device#1260
zackees merged 1 commit into
mainfrom
fix/rp-picotool-target-binding

Conversation

@zackees

@zackeeszackees commented Aug 6, 2026

Copy link
Copy Markdown
Member

Closes#1259\n\n## Summary\n- bind every picotool probe/load to the selected runtime USB serial and the exact ROM identity from verified FastLED/boards profiles\n- remove picotool force-reset (-f) and refuse unscoped or ambiguous PICOBOOT operations\n- treat Windows PICOBOOT Code 43 and other problem devnodes as a mass-storage-only fallback; never touch a stale runtime devnode\n- add RP2350 PICOBOOT preflight coverage and release fbuild 2.5.14\n\n## Verification\n- soldr cargo test -p fbuild-deploy rp2040 --lib -- --nocapture (117 passed)\n- soldr cargo test -p fbuild-core verified_cache_installs_typed_profiles_and_aliases --lib -- --nocapture\n- soldr cargo check --workspace --all-targets\n- git diff --check\n\nHardware deployment was intentionally not retried: the attached RP2350W remains a Windows Code-43 phantom and fbuild correctly refuses to reset that stale devnode.

Summary by CodeRabbit

  • New Features

    • Improved RP2040/RP2350 deployment with board-specific USB targeting and runtime serial matching.
    • Added safer automatic fallback to BOOTSEL mass storage when picotool cannot be used.
    • Added clearer diagnostics for deployment and device-detection issues.
  • Bug Fixes

    • Prevented unintended force-reset behavior during picotool operations.
    • Improved handling of ambiguous, missing, or unusable USB device identities.
  • Documentation

    • Updated deployment guidance to describe target-bound picotool loading and fallback behavior.
  • Chores

    • Updated the project version to 2.5.14.

@zackees
zackees merged commit 9bb107b into mainAug 6, 2026
88 of 93 checks passed
@zackees
zackees deleted the fix/rp-picotool-target-binding branch August 6, 2026 04:49
@coderabbitai

coderabbitaiBot commented Aug 6, 2026

Copy link
Copy Markdown

Review Change Stack

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 179cb073-1dc4-4012-ba1d-d6210e219504

📥 Commits

Reviewing files that changed from the base of the PR and between 767047d and b903fd1.

⛔ Files ignored due to path filters (1)
  • Cargo.lock is excluded by !**/*.lock
📒 Files selected for processing (7)
  • Cargo.toml
  • agents/docs/deploy-architecture.md
  • crates/fbuild-core/src/usb/profiles.rs
  • crates/fbuild-deploy/src/rp2040.rs
  • crates/fbuild-deploy/src/rp2040_picotool.rs
  • crates/fbuild-deploy/src/rp2040_preflight.rs
  • pyproject.toml

📝 Walkthrough

Walkthrough

RP2040 and RP2350 deployment now resolves verified, family-specific BOOTSEL identities and binds picotool operations to the selected serial, VID, and PID. Preflight classification is target-aware, forced loading is removed, and deployments fall back to UF2 when picotool cannot be used.

Changes

RP2040/RP2350 deployment

Layer / File(s)Summary
Verified profile target resolution
crates/fbuild-core/src/usb/profiles.rs, crates/fbuild-deploy/src/rp2040.rs
all_profiles() exposes installed verified profiles. RP deployment resolves exactly one family-specific BOOTSEL identity and tests missing, duplicate, and ambiguous identities.
Target-bound picotool commands
crates/fbuild-deploy/src/rp2040_picotool.rs
Picotool info and load commands now include --vid, --pid, and --ser. The load command no longer uses -f.
Preflight and fallback integration
crates/fbuild-deploy/src/rp2040_preflight.rs, crates/fbuild-deploy/src/rp2040.rs, agents/docs/deploy-architecture.md
PICOBOOT classification supports RP2040 and RP2350 targets. Unusable devices skip picotool and use BOOTSEL mass storage. Documentation describes the target-bound flow and timeout.
Release metadata
Cargo.toml, pyproject.toml
Project versions changed from 2.5.13 to 2.5.14.

Estimated code review effort: 4 (Complex) | ~45 minutes

Possibly related issues

  • FastLED/fbuild issue 1166: Covers the same PICOBOOT-first deployment strategy and target-bound picotool behavior.
  • FastLED/FastLED issue 3626: Addresses related RP2040 USB deployment, BOOTSEL/UF2 handling, and serial targeting.
  • FastLED/FastLED issue 3832: Addresses related RP2350 device identity and family-specific VID/PID handling.

Possibly related PRs

  • FastLED/fbuild#1053: Adds USB transport-profile integration consumed by this target-resolution flow.
  • FastLED/fbuild#1060: Provides related USB-profile-based RP2040/RP2350 deployment behavior.
  • FastLED/fbuild#1157: Provides Windows USB problem-device enumeration used by PICOBOOT preflight.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/rp-picotool-target-binding

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

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

Labels

None yet

Projects

Status: Triage

Development

Successfully merging this pull request may close these issues.

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

1 participant

@zackees