LPC845-BRK: deploy must always unwedge the shared VCOM (pyocd/SWD flash leaves CDC in Windows error 31) #565

Activity

1. fastled-project-sync

   added this to FastLED Trackeron Jun 13, 2026
2. fastled-project-sync

   moved this to Triage in FastLED Trackeron Jun 14, 2026
3. zackees commented on Jun 15, 2026

   

   zackees

   on Jun 15, 2026

   MemberAuthor

   More actions

   /clud-fix burn-down — skipped (downstream of #551)

   Touched as part of the #586 meta sweep. This issue is strictly downstream of #551 (no LPC Deployer exists yet, so there's nothing to attach the VCOM-unwedge logic to). Investigation report on #551 sketches the planned fix shape — including a dedicated vcom_unwedge.rs module specifically for the acceptance criterion this issue tracks. Will re-attempt this one automatically once #551 lands the LPC deployer scaffold.

   Filed via Claude Code — /clud-fix skill burn-down pass.
4. zackees

   added a commit that references this issue on Jun 15, 2026

   feat(deploy/lpc): LpcDeployer Phase 1 — lpc21isp ISP-over-UART (closes …

   ...

   104560c
5. zackees commented on Jun 16, 2026

   

   zackees

   on Jun 16, 2026

   MemberAuthor

   More actions

   Confirmed wedge on 2026-06-15 with refined repro + likely actual trigger

   Reproduced today running bash autoresearch lpc845brk --pin-toggle-rx --upload-port COM10 on Windows 10 against the LPC845-BRK. The wedge is real and consistent. Adding more diagnostic detail because the probable trigger is different from what this issue's original body assumed -- and that changes the fix shape.

   What FastLED's autoresearch actually does today

   ci/autoresearch/phases.py:1684-1716 invokes two separate pyocd subprocesses back-to-back:

   # Subprocess #1: pyocd load --no-reset firmware.bin
   load_cmd = pyocd_cmd_prefix + [
       "load", "--target", target,
       "--no-reset",
       str(firmware_bin),
   ]
   
   # Subprocess #2: pyocd commander -O reset_type=sw -c reset -c go -c quit
   reset_cmd = pyocd_cmd_prefix + [
       "commander", "--target", target,
       "-O", "reset_type=sw",
       "-c", "reset",
       "-c", "go",
       "-c", "quit",
   ]

   Each subprocess opens and closes the CMSIS-DAP HID interface independently. On the LPC845-BRK that interface is part of a composite USB device that also exposes the application VCOM CDC.

   Observation today, after the merged work

   I retested with the architected workarounds in place:

   • pyocd is using --no-reset on the load + reset_type=sw (NVIC SYSRESETREQ) on the separate commander -- not a hardware SRST, so the original "post-flash reset toggles the probe" hypothesis is ruled out for this exact code path.

   • The CMSIS-DAP probe firmware on the LPC4322 / on-board debugger is not observably reset by reset_type=sw (which is a target-side NVIC write, transparent to the probe).

   • And yet the CDC VCOM still wedges into Windows error 31 every single time. Reproducibly. The follow-up sequence is:

     1. pyocd load --no-reset -- opens HID, writes flash, closes HID. (Subprocess Esp32-s3 PSRAM use #1 exits.)
     2. pyocd commander -O reset_type=sw -c reset -c go -c quit -- opens HID again, sends NVIC reset to the target, closes HID. (Subprocess cdc on boot warning #2 exits.)
     3. Within ~50 ms of step 2, the Windows CDC sibling drops to error 31 and stays there until physical USB replug.

   The fact that this still happens with --no-reset + reset_type=sw means the wedge trigger is not the reset itself. It is something about the second HID open-close cycle on a composite device that confuses Windows' CDC driver.

   Refined root-cause hypothesis

   The Windows usbccgp.sys (USB composite class generic parent driver) treats CMSIS-DAP HID + CDC as two function drivers under one device. When pyocd opens the HID, usbccgp serializes the HID interface. When pyocd closes it and then a different process re-opens it within a short window, usbccgp emits a function-level reset event on the device. That function-level reset doesn't affect the HID side (pyocd just re-handshakes) -- but the CDC sibling sees its endpoint cleared and the higher-level usbser.sys driver doesn't recover, going to error 31.

   Two practical implications:

   1. A single pyocd invocation that does load + reset would likely sidestep this. Either pyocd flash --reset (full unified command) or pyocd load -O reset_type=sw firmware.bin (single subprocess, default-on reset) keeps the HID open for the whole sequence.
   2. The --no-reset + separate commander pattern is the active trigger, not the reset semantic. This is why reset_type=sw (which was added specifically for VCOM safety) doesn't save us -- it's not the reset that wedges the CDC, it's the inter-subprocess HID re-open.

   Proposed fix for the autoresearch path (one-line in ci/autoresearch/phases.py)

   Collapse the two subprocesses into one:

   # Single subprocess: load + reset_type=sw all in one HID session
   load_cmd = pyocd_cmd_prefix + [
       "load", "--target", target,
       "-O", "reset_type=sw",   # was: --no-reset, then a 2nd commander call
       str(firmware_bin),
   ]
   result = subprocess.run(load_cmd, env=env)
   # (no more 2nd `pyocd commander -c reset` step)

   I'd expect this to drop the wedge incidence dramatically -- maybe entirely, maybe to "rare" depending on whether the reset itself also nudges the CDC. Worth testing.

   If it still wedges after that, the architected answer is #595's lpc21isp path -- which sidesteps the composite HID entirely by going ISP-over-UART. (Currently lpc21isp isn't installed on this host, so I haven't been able to A/B that path empirically. The merged Rust LpcDeployer in fbuild#595 is the prerequisite.)

   Acceptance criteria for closing this issue haven't shifted

   The issue body's original requirement -- "deploy must always unwedge the shared VCOM" -- remains correct. The fix shape changes from "switch to SW reset" (already attempted, doesn't work) to one of:

   • A. Single-pyocd-call (cheapest; might resolve everything; test first)
   • B. lpc21isp ISP-over-UART path (architected; requires the deployer wiring from feat(deploy/lpc): LpcDeployer Phase 1 — lpc21isp ISP-over-UART (closes #551, sidesteps #565) #595 and a lpc21isp install)
   • C. Programmatic USB re-enumeration after wedge detection (defensive; works on top of any path, requires winusb IOCTL or devcon invocation)

   I lean A first (try the unified pyocd load -O reset_type=sw), B as the architected long-term answer, and C if neither A nor B holds 100% of the time.

   Cross-references from today's bench session

   • lpc845: pinToggleRx + ws2812SctTest handlers stack-overflow at runtime (8 KB stack buffer on 16 KB SRAM) FastLED#3125 -- the LPC845 LowMemory RPC handlers' RAM-bomb (now fixed in #3133); orthogonal but in the same sketch. With #3125 fixed I can now get past the post-flash echo step on hardware that isn't wedged -- so this issue is the last blocker on FastLED's #3102 Section 1 bench-validation meta.
   • LPC8xx Stage 7: deploy support (lpc21isp / pyocd / cmsis-dap / jlink) #551 / feat(deploy/lpc): LpcDeployer Phase 1 — lpc21isp ISP-over-UART (closes #551, sidesteps #565) #595 -- LPC deployer Phase 1 (lpc21isp); the architected workaround that makes path B above usable.
   • LPC845 bloat: 8.3 KB of soft-FP / integer-div leaks past the no-soft-FP invariant on LowMemory + RX_SCT_WS2812 FastLED#3076 -- bloat hunt that made the LowMemory build actually fit on hardware in the first place.

   Happy to test the A fix locally and report back.

   Filed via Claude Code on behalf of zachvorhies@protonmail.com.
6. zackees

   added a commit that references this issue on Jun 20, 2026

   ci(hooks): forbidden_commands.py — block pyocd/esptool/dfu-util/picot…

   ...

   8923088
7. zackees

   added 2 commits that reference this issue on Jul 1, 2026

   feat(deploy): resolve lpc21isp path via env / cache / tools / PATH (#921

   ...

   1007f2e

   feat(deploy): lpc21isp path resolver + baud/hex safety nets (#921, #927…

   ...

   5989187
8. pull

   added a commit that references this issue on Jul 2, 2026

   refactor(autoresearch): delegate all deployment to fbuild (removes py…

   ...

   b0a8090
9. zackees

   closed this as completedon Jul 7, 2026