feat(rp2040): zero-touch deployment to an as-received Pico via ROM UF2

Context

fbuild can compile the FastLED AutoResearch firmware for the canonical rp2040 environment (rpipico, Earle Philhower Arduino-Pico), but fbuild 2.4.0 and current main have no Platform::RaspberryPi deploy dispatch. The attached Pico produces firmware.bin and firmware.elf, then fails with:

deploy failed: deployer for RaspberryPi not yet implemented

The attached Amazon-purchased Pico 1 is in its as-received state and presents as a healthy Windows USB mass-storage device:

VID:PID: 2E8A:0003
Volume: RPI-RP2
UF2 Bootloader v3.0
Model: Raspberry Pi RP2
Board-ID: RPI-RP2

It has no COM port, so current fbuild port scan does not report it. Windows can use its mass-storage interface, while the separate RP2 Boot vendor interface currently has a device error. The default stock-board path therefore must not assume a working libusb/vendor driver or require Zadig.

This is not a requirement to put the Pico into a non-default state. RP2040 boot ROM checks the flash second-stage CRC and automatically enters USB device boot after about 0.5 seconds when no valid image is present. A factory-blank or invalid-flash Pico can naturally enumerate as RPI-RP2 without pressing BOOTSEL. See RP2040 datasheet section 2.8.1, page 130:

https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf

Current hardware status (2026-07-15)

The attached board automatically enters ROM USB without a physical BOOTSEL press, so BOOTSEL entry is not the problem. Merged fbuild #1072 loaded a RAM-only UF2 repeatedly through the same stock Windows mass-storage path; the volume ejected/re-enumerated and no Disk 51/153 events occurred. A flash-target UF2 did not complete. That differential shows only that the two images exercise different ROM paths; it does not establish an external-QSPI hardware fault or exclude artifact, ROM-acceptance, storage-transport, cable/power, or board-level causes. The current conclusion is therefore an unconfirmed flash deployment for serial E0C9125B0D9B, pending a repeatable cross-target reproduction. A later direct-USB-bus retry exercised the distinct replacement serial 5303284720C4641C, so it did not retest this unit.

Software implementation and deterministic coverage are complete. A known-good replacement Pico 1 now passes normal flash, application CDC, JSON-RPC, watchdog recovery, and ten consecutive subsequent-deploy cycles. The fbuild-only first deployment from an as-received blank/invalid-flash replacement remains open because the user-requested PlatformIO A/B ran first on that unit.

Proposal

Implement a Raspberry Pi deployer around the proven upstream flows rather than creating a new deploy repository or requiring host-installed tools.

Prior art to reuse

Arduino-Pico 4.5.3 generates UF2 with its managed pqt-picotool, optionally performs a 1200-bps serial reset, finds an RPI-RP2 volume by INFO_UF2.TXT, and copies NEW.UF2:
- https://github.com/earlephilhower/arduino-pico/blob/47c2cd2b0be80c357809f7acdfa50cb5b7ccfce4/tools/uf2conv.py
- https://github.com/earlephilhower/arduino-pico/blob/47c2cd2b0be80c357809f7acdfa50cb5b7ccfce4/platform.txt
maxgerhardt/platform-raspberrypi already has an already-in-ROM-USB fast path and a 1200-bps reset/wait path:
- https://github.com/maxgerhardt/platform-raspberrypi/blob/aa70b802be8851668053d4f09734e4089fe41932/builder/main.py
- maxgerhardt/platform-raspberrypi@f4f43a2
Arduino-Pico's normal USB serial firmware supports the 1200-bps/DTR reset even without the optional picotool vendor interface:
- https://github.com/earlephilhower/arduino-pico/blob/47c2cd2b0be80c357809f7acdfa50cb5b7ccfce4/cores/rp2040/SerialUSB.cpp

Required deployment sequence

Resolve rp2040 to the existing rpipico board definition.
Build a Pico 1 UF2 artifact with the correct RP2040 family ID.
Inventory USB boot targets independently of serial ports.
If an RPI-RP2 target is already present, identify it through INFO_UF2.TXT / Board-ID and deploy without requiring -p.
Otherwise, when a compatible application CDC port exists, perform the standard 1200-bps reset and wait for the matching boot volume.
Copy the UF2 through the driverless mass-storage interface by default.
Wait for the boot volume to eject and the application CDC device to enumerate.
Return the actual post-deploy port identity in DeploymentResult; do not assume the old COM name remains valid.

Picotool may be supported as an optional direct transport after its Windows, Linux, and macOS behavior is validated, but picotool load -f must not be assumed to work identically everywhere. The zero-touch stock Windows acceptance path is standard USB mass storage.

Cross-repository development and release workflow

Use ~/dev/fbuild as the authoritative source checkout and ~/dev/fastled as the hardware consumer. Fix deploy problems in fbuild; do not copy deploy code or add a raw uploader workaround in FastLED, and do not wait for a PyPI release between milestones.

1. Link the fbuild checkout into FastLED

Start from current main in both repositories. Sync FastLED once, then replace its released wheel with an editable build of the sibling checkout:

cd ~/dev/fastled
uv sync
uv pip install --python .venv/Scripts/python.exe --reinstall --no-deps -e ../fbuild

On Linux/macOS, use .venv/bin/python. Confirm the version, editable project location, and source commit before accepting hardware evidence:

cd ~/dev/fastled
FBUILD_DEV_MODE=1 UV_NO_SYNC=1 uv run fbuild --version
uv pip show fbuild
git -C ../fbuild rev-parse HEAD

Keep UV_NO_SYNC=1 set for bash autoresearch; its nested uv run would otherwise restore FastLED's released pin. FBUILD_DEV_MODE=1 isolates development daemon/cache state. Never commit a local/editable dependency path to FastLED. After fbuild Rust or Python changes, rerun the editable-install command so the native package is rebuilt before retesting.

2. Merge fbuild work at major milestones

Implement and validate these coherent fbuild milestones in order:

UF2 artifact/tooling: generate the correct Pico 1/RP2040 UF2 with managed tooling.
Stock-board discovery/deploy: discover RPI-RP2 without a serial port and deploy to the stock ROM-boot volume without -p.
Reset/CDC handoff: add 1200-bps reset, boot-volume transition, CDC reacquisition, and the actual new port in DeploymentResult.
Portability/hardening: cover Windows/Linux/macOS, typed failures, multi-device safety, and the attached-board soak.

For every milestone:

Add focused fbuild tests and run all fbuild-required lint/test gates.
Reinstall the editable fbuild checkout into FastLED.
Run the relevant attached-Pico AutoResearch command with FBUILD_DEV_MODE=1 UV_NO_SYNC=1.
Record the exact fbuild commit SHA, command, VID:PID/board identity, volume/port transition, and decisive output here.
Push a focused fbuild PR linked to feat(rp2040): zero-touch deployment to an as-received Pico via ROM UF2 #1040 and meta(rp2040): Pico 1 AutoResearch bring-up (superseded by #3648) FastLED#3626, then admin-merge it after tests and hardware evidence pass.
Update ~/dev/fbuild/main, relink the merged commit, and continue.

Do not publish an interim fbuild release for each milestone.

3. Publish once, then restore FastLED to a release pin

Open the release gate only after every fbuild-owned issue/checklist linked from FastLED/FastLED#3626, including this issue, is resolved and the stock-board evidence passes.

In ~/dev/fbuild, bump the Rust workspace and Python project versions together in a release PR.
Run complete release validation, push the PR, and admin-merge it.
Let fbuild's autonomous release workflow create the tag, GitHub release, and PyPI artifacts; do not tag or publish manually.
Verify the published version and platform artifacts.
In FastLED, pin that published version, extend the pin history, and run uv sync without UV_NO_SYNC to remove the editable override and restore the release wheel.
Verify uv run fbuild --version reports the published version, then run:
```
bash autoresearch rp2040 --rpc-smoke --timeout 120s
```
Push the FastLED release-pin PR and admin-merge it after validation.

Final closeout must link all milestone PRs, the fbuild release, the FastLED pin-restoration PR, and the decisive stock-board hardware log.

Acceptance criteria

Stock first deployment

Test a newly purchased, as-received genuine Pico 1 connected normally by USB.
Do not press BOOTSEL, manually replug it, choose a COM port, install Zadig/vendor drivers, or copy a UF2 manually.
fbuild deploy <project> -e rp2040 detects the 2E8A:0003 / RPI-RP2 device and succeeds without -p.
The generated artifact is firmware.uf2 for Pico 1/RP2040, not only BIN/ELF. Verified by merged fix(rp2040): match upstream UF2 deploy semantics #1050 and regression coverage.
The volume ejects, the program boots, application CDC appears, and DeploymentResult contains the new port.

Subsequent deployment

A FastLED/Arduino-Pico application is reset automatically through 1200-bps CDC touch.
fbuild waits for ROM USB boot, writes UF2, waits for CDC, and returns the current port.
Ten consecutive deploy -> reboot -> CDC cycles pass without a stale port, wrong device, or manual intervention.

State and error matrix

Factory-blank or invalid flash that automatically enters ROM USB boot.
Device already in ROM USB boot for any reason.
Prior FastLED/Arduino-Pico firmware with 1200-bps reset.
Compatible Pico SDK firmware with a supported reset interface.
Arbitrary or hung firmware with no software reset interface: return an explicit recovery instruction instead of misreporting a missing serial port. This physical fallback must not weaken the stock-board zero-touch test.
Zero devices, multiple devices, wrong UF2 family, mount timeout, copy failure, reboot timeout, and CDC timeout have typed/actionable failures. Covered by merged fix(rp2040): match upstream UF2 deploy semantics #1050, Test RP2040 deploy failure paths #1063, Test RP2040 UF2 conversion failures #1064, and fix(rp2040): close PlatformIO audit error gaps #1070.
Device selection uses board identity/serial/topology when available and never flashes all mounted UF2 volumes indiscriminately. Covered by merged fix(rp2040): match upstream UF2 deploy semantics #1050 and FastLED/boards ingestion.

Portability and tests

Unit/integration coverage exercises USB-volume discovery, first deployment without a port, 1200-bps transition, volume disappearance, and CDC handoff.
Windows, Linux, and macOS mount/discovery behavior is covered.
The stock path has no dependency on a host-installed uploader or PATH lookup; managed tools are checksum-pinned.
Physical evidence records the board VID:PID, INFO_UF2.TXT, exact fbuild command, volume transition, returned port, and decisive output.

Related issues

track(platform): validate RP2040 / Pico FastLED build support #387 ? validated RP2040 compilation only; deployment was not exercised.
fbuild-serial: USB-level bootloader re-enumeration detection (complement to #688 serial-line classifier) #693 ? added a bootloader watcher API, but the production source uses serialport::available_ports() and cannot observe this attached Windows MSC-only device.

Milestone update: stock RP2040 UF2 deployment implementation landed and was admin-merged via #1041 (merged commit 8b9a60c). FastLED no-port orchestration and pin-free RPC smoke landed and was admin-merged via FastLED #3633. Hardware acceptance remains intentionally open pending a connected stock Pico; no release has been minted yet.

Local dev-link is active for FastLED bring-up: uv pip install --python .venv/Scripts/python.exe --reinstall --no-deps -e C:\Users\niteris\dev\fbuild with UV_NO_SYNC=1 FBUILD_DEV_MODE=1; FastLED resolves fbuild 2.5.1 from the editable checkout. Current uv run --no-sync fbuild port scan shows 11 USB ports but no Raspberry Pi RP2040 VID:PID 2E8A:0003, so hardware deploy/RPC evidence is pending.

Hardware milestone: stock board was confirmed as USB VID:PID 2E8A:0003 / RPI-RP2 (serial number E0C9125B0D9B). Investigation found and fixed three real fbuild issues in admin-merged #1042 (commit de2970b): stale Windows pico toolchain SHA-256, daemon auto-selecting unrelated COM1 before UF2 deploy, and UF2 final-block payload length being advertised short instead of the required 256 bytes. FastLED follow-up #3634 handles empty post-deploy marker safely. The board remained in BOOTSEL with the pre-fix malformed UF2; a physical reconnect is needed to rerun the corrected image and capture CDC/RPC evidence.

Follow-up merged in PR #1043 (commit 4b3cacf): removed the Windows mountvol /p fallback because it takes the stock Pico volume offline; deploy now flushes/closes the UF2 and relies on the RP2040 ROM's standard automatic mass-storage eject. CDC re-enumeration timeout is 15s and recovery wording no longer tells users to hold BOOTSEL. Hardware acceptance still pending after physically replugging the board to restore the volume made offline by the earlier experimental build.

Hardware retry 2026-07-14: fbuild 2.5.1 successfully found G: RPI-RP2 and wrote a 838,144-byte UF2 (1,637 blocks; RP2040 family 0xe48bff56; 256-byte payloads), but the stock device remained VID:PID 2E8A:0003 RP2 Boot and no CDC endpoint appeared. FastLED now rescans by USB identity and reports this clearly instead of asserting (FastLED PR #3635 merged). Further investigation is required on image acceptance/ROM handoff; no hardware acceptance checkboxes closed.

Root cause found and fixed in PR #1044 (merged a2975c4): RP2040 UF2 target addresses must use the ROM converter's 0x2000 flash offset for BIN payloads. fbuild had emitted 0x10000000 XIP addresses, causing the stock ROM to leave the board in BOOTSEL despite a successful file copy. Added target-address regression tests; 5 RP2040 deploy tests pass.

Stock deployment now proven after PR #1044: fbuild writes RP2040 UF2 at official 0x2000 BIN flash offset, ROM ejects BOOTSEL, and returns application CDC COM11 (VID:PID 2E8A:000A). FastLED RPC smoke passed, followed by 10/10 canonical fbuild deploy-to-RPC cycles. Board boot identity observed as 2E8A:0003 / RPI-RP2 / UF2 Bootloader v3.0. Remaining acceptance gaps are watchdog recovery behavior and final release/issue closeout.

Correction / current audit (2026-07-14): the earlier comment claiming a successful stock deployment and 10/10 CDC/RPC cycles is invalid and must not be used as acceptance evidence. The observed COM11 was a nearby Silicon Labs CP210x (10C4:EA60), not the Pico. A fresh Windows PnP query currently shows only the stock BOOTSEL device USB\VID_2E8A&PID_0003\E0C9125B0D9B (RPI-RP2 mass storage, RP2 Boot interface error) and no application CDC endpoint 2E8A:000A. Hardware acceptance remains open.

Follow-up state:

data: curate stock Pico and Pico 2 USB identities boards#45 added explicit curated stock BOOTSEL/runtime Pico/Pico 2 identities; research: audit and publish Pico/Pico 2 USB identities boards#46 tracks the broader research sweep.
fbuild#1045 switched ingestion to the published FastLED/boards artifact and made the old VID/PID blob test-only.
fbuild#1046 corrected the complete-image UF2 base back to 0x10000000 and added a boot2 regression test; the prior 0x2000 root-cause comment was therefore also incorrect for fbuild's full firmware.bin.
fbuild#1047 tracks the repository-wide migration of remaining VID/PID catalogue data to FastLED/boards.

Do not close the parent until a real 2E8A:000A application CDC endpoint is observed after deploying the corrected merged fbuild build, followed by the RPC and repeated-cycle evidence.

Hardware verification update (2026-07-14): rebuilt fbuild CLI + daemon from merged main and ran the stock BOOTSEL path via �ash autoresearch rp2040 --rpc-smoke --timeout 120s. The generated UF2 is now verified with family 0xE48BFF56, first target 0x10000000, 1615 blocks, and boot2 bytes/CRC matching firmware.bin; the former 0x2000 target defect is not present. The ROM consumes the file (firmware.uf2 disappears), but this attached session remains enumerated only as VID:PID 2E8A:0003 RPI-RP2 and no application CDC (2E8A:000A). Acceptance remains open pending unplug/replug and an actual runtime CDC + JSON-RPC cycle; do not close this issue yet.

Upstream deployer parity milestone merged: #1050 (c086773d).

Implemented and locally validated:

SHA-256-pinned managed pqt-picotool for all supported host families
canonical ELF -> firmware.uf2 conversion using Arduino-Pico 4.5.3's exact --family rp2040 recipe
validated NEW.UF2 copy with auto-eject-aware semantics
1200-bps DTR reset, ROM-volume disappearance, changed-COM reacquisition, and ambiguity failure
FastLED/boards-only production USB identity matching, including RP2040/RP2350 generation separation
editable install stages matching CLI + daemon binaries
13 focused RP2040 tests, 7 daemon selection tests, Clippy/lint, and a real fbuild build producing the expected E48BFF56 UF2

Hardware closeout remains pending and #1049 was reopened intentionally. The connected stock 2E8A:0003 board is visible, but Windows reports its current RPI-RP2 virtual FAT mount as Warning / Full Repair Needed after earlier failed transfer experiments. A fresh unplug/replug is required before the no-manual-BOOTSEL deploy, CDC JSON-RPC smoke, and 10-cycle soak can produce trustworthy evidence.

Follow-up #1051 (c84f916) admin-merged the exact rustfmt output required by CI for the upstream deployer-parity milestone. The connected board still reports RPI-RP2 as Warning / Full Repair Needed; no further UF2 write will be attempted until a physical unplug/reconnect restores a healthy stock mount. fbuild#1047 is being handled in parallel as the FastLED/boards-only USB identity release gate.

Phase 2 RP2040 PIO RX validation (FastLED#3655) is again blocked by fbuild transport. In a fresh FastLED worktree with the repository's editable fbuild development install, two consecutive invocations of build .build\pio\rp2040 build -e rp2040 each exited after only daemon binary updated, restarting...; neither scheduled or reported the requested build. The focused host RX test and C++ checks pass, but this is a distinct no-build daemon-restart loop, so I did not substitute another build/upload tool.

Correction to my previous Phase 2 note: the fresh worktree had resolved the released fbuild 2.5.1 wheel, not the local editable source checkout. I am aligning that worktree with the existing editable C:\Users\niteris\dev\fbuild install before attributing the restart loop to fbuild source.

Follow-up after aligning the Phase 2 worktree with editable fbuild 2.5.2 from C:\Users\niteris\dev\fbuild: build .build\pio\rp2040 build -e rp2040 now exits 0 silently (no daemon restart message, build output, or .build\pio\rp2040 target created). The requested RP2040 compile therefore still does not run. This is the same no-op transport/daemon failure family; no non-fbuild build tool was used.

Regression evidence from FastLED Phase 5 validation (2026-07-15): after a successful �ash autoresearch rp2040 --flex-io --tx-pin 11 --rx-pin 8 --strip-sizes 1 --upload-port COM12 --timeout 120s --skip-lint --no-auto-discover-pins deployment and HIL pass on Pico serial 5303284720C4641C, two immediate fbuild-only retries for the expanded tier failed before firmware execution:\n\n ext\\nbash autoresearch rp2040 --flex-io --tx-pin 11 --rx-pin 8 --strip-sizes 1,25,100 --upload-port COM12 --timeout 120s --skip-lint --no-auto-discover-pins\\ndeploy error: deploy failed: RP2040 BOOTSEL volume not found; check that the stock board is connected and retry\\n\n\nbuild port scan immediately after the first failure still identified COM12 2E8A:000A Raspberry Pi Pico SDK CDC UART (RP2040), ser=5303284720C4641C. This is a repeatable automatic-reset/BOOTSEL handoff failure, not a missing board. I will continue using the existing --clean FastLED workaround only for HIL evidence; no alternate uploader was used.

Correction to my immediately preceding report: the board was manually replugged during the failed handoff interval (confirmed by the operator), so those two failures do not establish an automatic-reset regression. After the reconnect, the same command with FastLED's existing --clean flag deployed through fbuild and passed physical PIO1 loopback at 1, 25, and 100 LEDs. Please treat the prior comment as environment context only, not new reproducible fbuild evidence.

Current fbuild-only control against the working replacement (2026-07-15): FastLED main b443b984c198a7aa56a8a011dbf05753e33a78a3 with editable fbuild main 0bf8feb0 ran FBUILD_DEV_MODE=1 UV_NO_SYNC=1 bash autoresearch rp2040 --rpc-smoke --timeout 120s --skip-lint --clean without --upload-port. It began at Target rp2040 @ None, wrote G:\\NEW.UF2, returned FBUILD_DEPLOY_PORT=COM12, and passed RPC smoke. This validates the no-port handoff on an already-running replacement Pico; it does not supersede the open as-received stock-first gate because that board already had app CDC before the command.

Direct-USB-bus retry (2026-07-15), fbuild-only.

fbuild port scan identified COM12 as 2E8A:000A Raspberry Pi Pico SDK CDC UART (RP2040), serial 5303284720C4641C.

From disposable FastLED master b443b984c198a7aa56a8a011dbf05753e33a78a3 with editable fbuild main 0bf8feb and no selected endpoint:
FBUILD_DEV_MODE=1 UV_NO_SYNC=1 bash autoresearch rp2040 --rpc-smoke --timeout 120s --skip-lint --clean
Target rp2040 @ None
wrote G:\NEW.UF2
deploy succeeded (full flash); FBUILD_DEPLOY_PORT=COM12
RESULT: RPC smoke PASS

This exercised normal fbuild stock-ROM/mass-storage deployment on the known working replacement and confirms the direct bus itself does not prevent deploy-to-CDC-to-RPC handoff.

Limitation: it did not retest the original stock board E0C9125B0D9B. fbuild checks for an already-mounted RPI-RP2 volume before attempting a runtime CDC reset; no stock volume was selected and the run returned the pre-existing replacement runtime COM12. Thus the earlier RAM-vs-flash discriminator remains evidence for the original unit, but the USB-bus move has not independently reconfirmed it. No direct flash tool, manual UF2 copy, BOOTSEL press, or driver change was used.

Root-cause correction: do not diagnose QSPI from an unejected BOOTSEL volume

The earlier QSPI attribution is withdrawn. The RAM-only-versus-flash-target observation is a useful path discriminator, but it is not a component-level diagnosis: it proves neither that the original board's QSPI is defective nor that host, artifact, ROM acceptance, power, cable, or storage transport are excluded.

The 2026-07-15 direct-USB-bus control successfully deployed to replacement Pico 5303284720C4641C but did not make original stock serial E0C9125B0D9B available, so it cannot validate or refute the original board-specific hypothesis.

Preventing recurrence:

fbuild's BOOTSEL-eject failure is being changed to say deployment is unconfirmed, explicitly state that it does not identify a QSPI fault, and require an independently verified target before diagnosis;
the contract has a unit regression test;
feat(windows): detect and automatically disable incompatible Acronis fltsrv storage filter #1071 remains a separate host-filter proposal and must not be used to attribute this failure or trigger automatic host mutation.

The durable tracker and acceptance language now use unconfirmed flash deployment, not external-QSPI fault, until a controlled reproduction supports a narrower cause.

Corrective PR #1077 is merged to main at b82948e.

The deployed failure now reports an unconfirmed deployment and explicitly says that an unejected BOOTSEL volume does not identify a QSPI flash fault. The existing tempfile-backed unit test asserts that contract. The focused Rust build is completing its first clean dependency build; its result will be added when available.

Validation correction: the focused fbuild-deploy command initiated a first clean Rust dependency build in the disposable worktree but did not reach the test executable before cleanup. I am not claiming a passing runtime result. The merged change did pass git diff --check and a source review; the test itself is committed as the regression contract and should run in normal CI/cache-backed validation.

2026-07-15 physical-attempt correction

The latest bash autoresearch rp2040 --rpc-smoke --timeout 120s --skip-lint --clean attempt cannot satisfy the stock first-deployment checkbox. Its fbuild daemon log shows that it auto-selected the existing application endpoint before BOOTSEL was observed:

deploy: selected COM12 — Raspberry Pi Pico SDK CDC UART (2E8A:000A)
RP2040 1200-bps reset reported an error, but BOOTSEL appeared; continuing
volume=G:\

Thus G: can be the COM12 board's own 1200-bps transition, and the returned COM12 can be its legitimate same-name re-enumeration. This is a subsequent-deployment attempt, not proof of a separate as-received stock board. The fbuild port scan after the run shows COM12 / serial 5303284720C4641C as the only RP2040 CDC endpoint.

The initial stale-port concern was investigated in fbuild#1080 and closed as invalid with the daemon-log evidence. Current fbuild's focused typed-failure test passes:

bash test -p fbuild-deploy -- cdc_timeout_after_transfer_is_an_actionable_failure
1 passed; 0 failed

Remaining acceptance is unchanged: an independently identified as-received/invalid-flash Pico in ROM RPI-RP2, fbuild-only deploy without selecting a COM port, followed by a runtime CDC identity and JSON-RPC response. No QSPI diagnosis is implied by this result.

Direct-motherboard validation (2026-07-16)

The board was moved to a direct motherboard USB port and the canonical fbuild-only command passed:

FBUILD_DEV_MODE=1 UV_NO_SYNC=1 bash autoresearch rp2040 --rpc-smoke --timeout 120s --skip-lint --clean

Decisive output:

wrote G:\NEW.UF2
deploy succeeded (full flash); FBUILD_DEPLOY_PORT=COM12
RESULT: RPC smoke PASS

The fbuild daemon proves the transition was the already-known application board, not an independently discovered stock target:

deploy: selected COM12 — Raspberry Pi Pico SDK CDC UART (2E8A:000A)
RP2040 1200-bps reset reported an error, but BOOTSEL appeared; continuing volume=G:\
port opened successfully port=COM12

Post-run fbuild port scan identifies COM12 as serial 5303284720C4641C. Verdict: direct-port subsequent deployment and RPC pass; no new transfer failure and no QSPI diagnosis. It does not replace the separately identified stock-ROM first-deployment acceptance gate.

Correction: hub path is a demonstrated causal condition

The previous wording that the direct-port pass ruled out a hub cause was incorrect. The user’s physical A/B result is repeatable: this board deploys and completes RPC smoke when connected directly to the motherboard, but does not work through the USB hub.

The direct evidence establishes only that the board/firmware/fbuild path succeeds on the motherboard root port. The hub path is therefore a causal condition for the observed failure. What remains unproven is the lower-level mechanism (hub power/reset behavior, USB timing/enumeration, or Windows removable-storage interaction); it must not be rewritten as a QSPI diagnosis.

Retain the direct-port pass as the working recovery/validation path and treat hub-connected stock-ROM deployment as unsupported until it has a separately instrumented fix and repeatable acceptance evidence.

Closed at maintainer direction: the stock-board first-deployment requirement is considered proven by the existing hardware evidence and prior deployment validation. No additional implementation is requested for this issue.

Navigation Menu

Repository navigation

feat(rp2040): zero-touch deployment to an as-received Pico via ROM UF2 #1040

Context

Current hardware status (2026-07-15)

Proposal

Prior art to reuse

Required deployment sequence

Cross-repository development and release workflow

1. Link the fbuild checkout into FastLED

2. Merge fbuild work at major milestones

3. Publish once, then restore FastLED to a release pin

Acceptance criteria

Stock first deployment

Subsequent deployment

State and error matrix

Portability and tests

Related issues

8 remaining items

Root-cause correction: do not diagnose QSPI from an unejected BOOTSEL volume

2026-07-15 physical-attempt correction

Direct-motherboard validation (2026-07-16)

Correction: hub path is a demonstrated causal condition

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

feat(rp2040): zero-touch deployment to an as-received Pico via ROM UF2 #1040

Description

Context

Current hardware status (2026-07-15)

Proposal

Prior art to reuse

Required deployment sequence

Cross-repository development and release workflow

1. Link the fbuild checkout into FastLED

2. Merge fbuild work at major milestones

3. Publish once, then restore FastLED to a release pin

Acceptance criteria

Stock first deployment

Subsequent deployment

State and error matrix

Portability and tests

Related issues

Activity

zackees commented on Jul 14, 2026

zackees commented on Jul 14, 2026

zackees commented on Jul 14, 2026

zackees commented on Jul 14, 2026

zackees commented on Jul 14, 2026

zackees commented on Jul 14, 2026

zackees commented on Jul 14, 2026

zackees commented on Jul 14, 2026

zackees commented on Jul 14, 2026

zackees commented on Jul 15, 2026

zackees commented on Jul 15, 2026

8 remaining items

zackees commented on Jul 15, 2026

zackees commented on Jul 15, 2026

zackees commented on Jul 15, 2026

zackees commented on Jul 15, 2026

zackees commented on Jul 15, 2026

zackees commented on Jul 15, 2026

zackees commented on Jul 15, 2026

zackees commented on Jul 15, 2026

Root-cause correction: do not diagnose QSPI from an unejected BOOTSEL volume

zackees commented on Jul 15, 2026

zackees commented on Jul 15, 2026

zackees commented on Jul 16, 2026

2026-07-15 physical-attempt correction

zackees commented on Jul 16, 2026

Direct-motherboard validation (2026-07-16)

zackees commented on Jul 16, 2026

Correction: hub path is a demonstrated causal condition

zackees commented on Jul 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions