Severity: HIGH — on CH32V303, every HAL translation unit compiles with the V305/V307 (D8C, connectivity-line) register map and IRQ numbering, while the startup TU links the correct D8 vector table. Interrupts misroute on bench hardware.
Problem
crates/fbuild-config/assets/boards/json/genericCH32V303VCT6.json:11 has:
"extra_flags": "-DCH32V303VC -DCH32V30X -DCH32V30x -DCH32V303"
PR #399 removed -DCH32V30x_D8 from this line to silence a macro-redefinition warning. But the pinned core's ch32v30x.h reads (verbatim):
#if !defined(CH32V30x_D8) && !defined(CH32V30x_D8C)
#define CH32V30x_D8C
— it does not recognize CH32V30x_C at all. So with the flag gone, every HAL/core TU defaults to D8C (V305/V307 connectivity line), while the startup TU — the only TU that includes cores/arduino/ch32/ch32_def_build.h (verified via .d dependency files) — picks startup_ch32v30x_D8.S via its CH32V30x branch. Result: D8C HAL + IRQ enum numbering linked against a D8 vector table, on general-line (V303) silicon.
Bench consequence
- Interrupts with IRQn ≥ 58 (TIM8 group, UART4+, DMA2 channels, USBFS) are mis-numbered vs the vector table →
attachInterrupt/peripheral IRQs vector to the wrong slot or to nothing.
- D8C-only peripherals (ETH, DVP, USBHS) compile fine but bus-fault if touched.
Why the original motivation is moot
#399's redefinition warning no longer exists: since #382, framework sources compile with blanket -w (crates/fbuild-build-mcu/src/ch32v/ch32v_compiler.rs:121-123).
Evidence
Fix
Add -DCH32V30x_D8 back to the V303 extra_flags. Do not add -DCH32V30x_C (that is the V307 selector).
Acceptance
tests/platform/ch32v303 builds; compile response file shows -DCH32V30x_D8.
- V307 build unchanged (
-DCH32V30x_C, D8C startup).
- Bench: a TIM8-group or UART4 interrupt on a V303 board fires correctly.
Found during the 2026-07-21 CH32V bench-readiness sweep (two audit passes converged on this independently).
Severity: HIGH — on CH32V303, every HAL translation unit compiles with the V305/V307 (D8C, connectivity-line) register map and IRQ numbering, while the startup TU links the correct D8 vector table. Interrupts misroute on bench hardware.
Problem
crates/fbuild-config/assets/boards/json/genericCH32V303VCT6.json:11has:PR #399 removed
-DCH32V30x_D8from this line to silence a macro-redefinition warning. But the pinned core'sch32v30x.hreads (verbatim):— it does not recognize
CH32V30x_Cat all. So with the flag gone, every HAL/core TU defaults to D8C (V305/V307 connectivity line), while the startup TU — the only TU that includescores/arduino/ch32/ch32_def_build.h(verified via.ddependency files) — picksstartup_ch32v30x_D8.Svia itsCH32V30xbranch. Result: D8C HAL + IRQ enum numbering linked against a D8 vector table, on general-line (V303) silicon.Bench consequence
attachInterrupt/peripheral IRQs vector to the wrong slot or to nothing.Why the original motivation is moot
#399's redefinition warning no longer exists: since #382, framework sources compile with blanket
-w(crates/fbuild-build-mcu/src/ch32v/ch32v_compiler.rs:121-123).Evidence
boards/genericCH32V303VCT6.jsonstill carries-DCH32V30x_D8; fbuild diverged in fix(ch32v): scope third-party OpenWCH warnings + remove duplicate CH32V30x_D8C define #399 (confirmed viagit log -p).-DCH32V30x_Cselects the D8C startup, and the header's D8C default happens to match.Fix
Add
-DCH32V30x_D8back to the V303extra_flags. Do not add-DCH32V30x_C(that is the V307 selector).Acceptance
tests/platform/ch32v303builds; compile response file shows-DCH32V30x_D8.-DCH32V30x_C, D8C startup).Found during the 2026-07-21 CH32V bench-readiness sweep (two audit passes converged on this independently).