Repository navigation
bug(rp2040): reject unrelated pre-existing CDC port after stock-ROM deploy #1080
Description
Parent: #1040 and #1049. FastLED/FastLED#3627 and #3648 depend on this safety condition.
Reproduction (2026-07-15, fbuild-only)
Precondition from fbuild port scan:
COM12 2E8A:000A Raspberry Pi Pico SDK CDC UART ser=5303284720C4641C
A separate Pico was already in stock ROM USB / RPI-RP2 mass-storage mode at G:. It has no CDC port by design. Run from FastLED with the editable fbuild development install:
FBUILD_DEV_MODE=1 UV_NO_SYNC=1 bash autoresearch rp2040 --rpc-smoke --timeout 120s --skip-lint --cleanObserved decisive lines:
Target rp2040 @ None
wrote G:\NEW.UF2
Deploy succeeded (full flash); FBUILD_DEPLOY_PORT=COM12
RESULT: RPC smoke PASS
Immediately after the command, both fbuild port scan and fbuild serial probe list still showed only the exact pre-existing COM12 / serial 5303284720C4641C; no new post-deploy CDC endpoint appeared. The RPC command therefore talked to the unrelated pre-existing replacement board and produced a false green result.
Expected
For an already-mounted stock ROM target with no selected runtime identity, deployment must fail closed unless the post-deploy CDC endpoint is demonstrably associated with the selected BOOTSEL volume. It must never return an unrelated pre-existing CDC port or let AutoResearch run RPC against it.
A correct solution may accept a re-enumerated same-name port only when board serial/topology/other stable identity correlates it to the selected target. If correlation is unavailable, require a new/associated endpoint or return the existing typed CDC-handoff/recovery failure.
Acceptance
- Add a focused regression test with a pre-existing unrelated CDC candidate and a selected BOOTSEL volume; no correlated/new runtime endpoint must be an error, never success with that port.
- Preserve valid subsequent deployment where a selected runtime can be correlated across reset, including COM-name reuse.
- Do not hard-code production RP2040 VID/PIDs; use the generated FastLED/boards catalogue and synthetic IDs only in fixtures.
- Validate with fbuild tests, then repeat the canonical fbuild-only stock-ROM AutoResearch command. The returned port must be newly observed or identity-correlated to the selected board.
This is a deploy-result correctness defect, not evidence of QSPI failure. No PlatformIO or direct-flash workaround is in scope.
Activity
zackees commentedon Jul 16, 2026
Investigation correction (2026-07-15)
The initial report inferred a stale-port handoff from
wrote G:\NEW.UF2followed byFBUILD_DEPLOY_PORT=COM12. The fbuild daemon log resolves that ambiguity:Therefore this run had selected COM12 before the RP2040 deployer observed
G:. The BOOTSEL transition can be COM12 itself resetting and returning on the same port name; it is not evidence that an unrelated pre-existing CDC port was returned. The physical run is a subsequent-deployment attempt on serial5303284720C4641C, not stock first-deployment proof for a second board.Current
main(and the editable source commit used) already snapshots pre-deploy CDC ports and fails with the typed CDC-handoff failure when only pre-existing ports remain. Focused confirmation:No code change is justified by this reproduction. Closing as invalid after preserving the evidence; #1040/#1049 remain open for a genuine stock-ROM first-deploy acceptance run with the board identity recorded.
zackees commentedon Jul 16, 2026
Closed after investigation: the reported stale-port condition was not reproduced; see the evidence comment.