You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of the CH32V pipeline audit (#1102). Grab-bag of LOW-severity data/doc/code inconsistencies found along the way — none is load-bearing today, each is a landmine for the next person.
genericCH32X035C8T6.json says "clock_source": "hsi+pll" — the CH32X035 has no PLL (and no HSE); it runs the 48 MHz HSI directly. Harmless today because nothing consumes clock_source, but wrong reference data. Should be "hsi".
FastLED/datasheets has no wch/ folder. The audit had to verify chip memory maps against the upstream OpenWCH core and WCH's site. Add CH32V003 / CH32V006 / CH32V103 / CH32V203 / CH32V208 / CH32V30x / CH32X035 / CH32L103 datasheets + reference manuals there (same layout as espressif/soc/*) so board JSONs and future audits can cite pinned PDFs.
Part of the CH32V pipeline audit (#1102). Grab-bag of LOW-severity data/doc/code inconsistencies found along the way — none is load-bearing today, each is a landmine for the next person.
genericCH32X035C8T6.jsonsays"clock_source": "hsi+pll"— the CH32X035 has no PLL (and no HSE); it runs the 48 MHz HSI directly. Harmless today because nothing consumesclock_source, but wrong reference data. Should be"hsi".genericCH32V208WBU6.jsonreuses the CH32V203 variant:"variant": "CH32V20x/CH32V203C8","variant_h": "variant_CH32V203C8.h". The V208 is a different die (BLE radio, different pinout). Currently semi-moot because the env builds Arduino-core anyway (see ch32v: framework field is ignored — noneos-sdk envs silently build the OpenWCH Arduino core (4 of 9 CI envs affected) #1108) and no V208 variant exists upstream, but the JSON presents a V203C8 pin map as if it were the V208's.docs/BOARD_STATUS.mdCH32V section is out of date both directions: the badge list has only ch32v003/103/203/208/303/307 (missing ch32v006, ch32l103, ch32x035, which have workflows), and the "Supported" list names only CH32V003 while nine families build in CI. It also says "Supported" with no build-only caveat even though deploy is unimplemented (ch32v: deploy is unimplemented while board JSONs advertise wch-link/minichlink/isp/wlink and docs say Supported #1105).Dead divergent code:
Ch32vCores::get_linker_script()(crates/fbuild-library/src/library/ch32v_core.rs) resolves a.ldfrom the variant directory, but the orchestrator resolvessystem/<series>/SRC/Ld/Link.ldand never calls this method. Two resolution strategies, one unused — delete or unify (relevant when fixing ch32v: V20x links against Link.ld defaults (64K/20K) — stack pointer beyond physical RAM on CH32V203C6/G6, RB/208 capped at half #1103/ch32v: CH32V006 builds as a CH32V003 — series mapped to system/CH32V00x instead of CH32VM00X (16K/2K linker script on a 62K/8K chip) #1104).FastLED/datasheets has no
wch/folder. The audit had to verify chip memory maps against the upstream OpenWCH core and WCH's site. Add CH32V003 / CH32V006 / CH32V103 / CH32V203 / CH32V208 / CH32V30x / CH32X035 / CH32L103 datasheets + reference manuals there (same layout asespressif/soc/*) so board JSONs and future audits can cite pinned PDFs.Severity: LOW.