ch32v-core is fetched without its TinyUSB submodule — all 9 CH32V boards are red

[zackees]

Split from #1400, which fixed this class for SAMD (#1418) and ESP8266 (#1398). Unlike #1400, this one is confirmed failing, not inferred.

Confirmed broken

Nightly Platforms run 33866723360 (2026-09-04) failed on all nine CH32V boards: CH32V003, CH32V006, CH32V103, CH32V203, CH32V208, CH32V303, CH32V307, CH32X035, CH32L103.

From the CH32V003 / build job log verbatim:

build error: package error: ch32v-core unpacked without its submodule contents.
These directories are declared in .gitmodules and came out empty:
  - libraries/Adafruit_TinyUSB_Arduino

Cause

crates/fbuild-library/src/library/ch32v_core.rs:

const CH32V_CORE_URL: &str = "https://github.com/openwch/arduino_core_ch32/archive/d76716239cdf8a084a5045c3dfd3151b3f69eeec.tar.gz";

Note this is the /archive/<sha> form, not /archive/refs/tags/. Both are auto-generated and both omit submodules — worth stating because the SAMD regression guard in #1418 originally only rejected the refs form.

Verified by downloading the pinned archive:

• it contains .gitmodules
• arduino_core_ch32-d767162…/libraries/Adafruit_TinyUSB_Arduino/ is present with exactly one entry — the empty directory itself

That is precisely the condition #1401's unpack check fires on. The boards were green through 2026-08-24; #1401 merged 2026-08-28.

Why the usual fix does not apply

The ESP8266 (#1398) and SAMD (#1418) fixes both switched to a prepared artifact. Neither option exists here:

• openwch publishes no release assets at all. gh release view 1.0.4 --repo openwch/arduino_core_ch32 --json assets returns empty, as do the other four releases.
• The pin postdates every release. Commit d767162 is 2025-05-07 ("Update PlatformIO builder script ([META] fbuild build cache must survive CI tar-extract / cross-runner restore #147)"); the newest release is 1.0.4 from 2023-12-18. Downgrading to a release would lose 17 months of core changes.

Is the content actually needed?

Not on the current build path. ch32v_core.rs defines get_libraries_dir(), but:

• it has no framework_libraries implementation, and
• no orchestrator under crates/fbuild-build-mcu/ consumes get_libraries_dir() for ch32v

so bundled core libraries are never enumerated for these boards. The tests/platform/ch32v003 sketch is a plain pinMode/digitalWrite blink. CH32V003 has no USB peripheral at all.

This is the same shape as SAMD: a genuinely unused submodule turned into a hard failure by a check that fires on the package rather than on use.

It is not universally irrelevant, though — CH32V208 and CH32V307 do have USB, so a user sketch including Adafruit_TinyUSB.h would hit the original #1380 failure mode. Any fix should say which of the two problems it is solving.

Options

1. Declare the submodule knowingly-unpopulated (see the escape-hatch issue filed alongside this one). Cheapest, and honest about the fact that nothing reads it today. Does not help a sketch that wants TinyUSB.
2. Submodule-aware fetch — git clone --recurse-submodules at the pinned sha. PackageBase does not do clones today. Fixes it properly for USB-capable parts.
3. FastLED-owned mirror bundle. There is precedent: arduino_core_lpc8xx.rs already fetches from FastLED/framework-arduino-lpc8xx, which carries no .gitmodules. Costs a mirror to maintain.

I have not picked one — option 2 is the only one that makes TinyUSB actually usable, but it is also the only one that changes the fetch path for every package.

Not the cause

Worth recording so nobody re-checks: the failure is unrelated to the CH32V bring-up work in #1208/#1209.

[zackees]

Escape-hatch proposal filed as #1422 — option 1 above depends on it.