Severity: MEDIUM — probe-free fallback flashing for the 7 CH32V series that have a factory USB-ISP bootloader. Complements the primary wlink deployer.
Scope
CH32V103, V203, V208, V303, V307, X035, L103 all ship a factory ISP bootloader in system flash supporting USB (and UART), entered via BOOT0=1/BOOT1=0 at reset (X035: no BOOT pin — hold PC16 low / PC17 high at power-on; EVT boards wire this to the Download button). Verified against the WCH datasheets (CH32V20x §2.5.2, CH32X035 §1.4.3) and wchisp's device YAMLs.
Explicitly out of scope: CH32V003 and CH32V006. No USB peripheral; their UART-only bootloader has software-only entry (option byte + running application) — unreachable on a blank chip. wchisp's stable v0.3.0 doesn't support V00x at all (V002–007 support is nightly-only, Nov 2024). These parts are probe-only — see the companion board-JSON issue about dropping their bogus "isp" protocol entry.
Implementation outline
- Module alongside the wlink deployer in
crates/fbuild-deploy/ (no new crate).
- Pin wchisp v0.3.0 (assets: linux-x64, linux-aarch64, macos-x64, macos-arm64, win-x64; sha256 each). License is GPL-2.0 — fine to download and invoke as an external pinned binary (same as other flashers); do not link it.
- Invocation:
wchisp flash <firmware.bin>. wchisp cannot force bootloader entry — the user must hold BOOT0/Download at reset. Detect absence of the ISP device (4348:55e0 / 1a86:55e0 — wchisp matches both, verified in its src/transport/usb.rs) and print the per-family entry procedure.
- Protocol selection: route
upload_protocol = isp (or --protocol isp) here; default stays wlink. Gate by family capability (never offer for V003/V006).
- Device identity from the FastLED/boards registry (blocked on the registry issue linked from the meta).
- Windows:
55e0 needs a WinUSB driver (Zadig or the WCH driver) — document in the error text when the device is present but unopenable.
Acceptance
- With a V203 board in BOOT0 mode on USB:
fbuild deploy ... --protocol isp flashes without any probe.
- With no ISP device present: actionable error explaining the BOOT0/Download-button entry for that family.
--protocol isp on a V003 env: hard error ("no ISP bootloader on this part; use a WCH-LinkE probe").
From the 2026-07-21 deployment-strategy audit (meta issue has the full strategy matrix and sources).
Severity: MEDIUM — probe-free fallback flashing for the 7 CH32V series that have a factory USB-ISP bootloader. Complements the primary wlink deployer.
Scope
CH32V103, V203, V208, V303, V307, X035, L103 all ship a factory ISP bootloader in system flash supporting USB (and UART), entered via BOOT0=1/BOOT1=0 at reset (X035: no BOOT pin — hold PC16 low / PC17 high at power-on; EVT boards wire this to the Download button). Verified against the WCH datasheets (CH32V20x §2.5.2, CH32X035 §1.4.3) and wchisp's device YAMLs.
Explicitly out of scope: CH32V003 and CH32V006. No USB peripheral; their UART-only bootloader has software-only entry (option byte + running application) — unreachable on a blank chip. wchisp's stable v0.3.0 doesn't support V00x at all (V002–007 support is nightly-only, Nov 2024). These parts are probe-only — see the companion board-JSON issue about dropping their bogus
"isp"protocol entry.Implementation outline
crates/fbuild-deploy/(no new crate).wchisp flash <firmware.bin>. wchisp cannot force bootloader entry — the user must hold BOOT0/Download at reset. Detect absence of the ISP device (4348:55e0/1a86:55e0— wchisp matches both, verified in itssrc/transport/usb.rs) and print the per-family entry procedure.upload_protocol = isp(or--protocol isp) here; default stays wlink. Gate by family capability (never offer for V003/V006).55e0needs a WinUSB driver (Zadig or the WCH driver) — document in the error text when the device is present but unopenable.Acceptance
fbuild deploy ... --protocol ispflashes without any probe.--protocol ispon a V003 env: hard error ("no ISP bootloader on this part; use a WCH-LinkE probe").From the 2026-07-21 deployment-strategy audit (meta issue has the full strategy matrix and sources).