ch32-rs flash-algorithms

probe-rs flash algorithms and target YAMLs for WCH's CH32 MCU families, built on top of ch32-metapac.

Coverage

One algo crate per (flash IP version, CPU arch) pair. f1 is a Cortex-M3 build of the same flash_v1 logic used by v1 on Qingke RISC-V — Cargo can't unify two ch32-metapac chip features, so the lib is duplicated.

Crate	Flash peripheral	Target triple	Chip families
algos/v0	flash_v0	riscv32ec-unknown-none-elf	CH32V003, CH641
algos/v00x	flash_v00x	riscv32ec_zmmul-unknown-none-elf	CH32V002/4/5/6/7, CH32M007
algos/v1	flash_v1	riscv32imac-unknown-none-elf	CH32V103
algos/v3	flash_v3	riscv32imac-unknown-none-elf	CH32V2xx, CH32V3xx
algos/x0	flash_x0	riscv32imac-unknown-none-elf	CH32X035/X033, CH643
algos/l1	flash_l1	riscv32imac-unknown-none-elf	CH32L103
algos/h4	flash_h4	riscv32imac-unknown-none-elf	CH32H415/H416/H417
algos/f1	flash_v1	thumbv7m-none-eabi	CH32F103 (Cortex-M3)

Each crate builds three binaries — usr, sys, ob — one per writable region. VND (vendor / ESIG) is read-only and not programmed.

Repo layout

ch32-metapac isn't pinned via crates.io or git rev — it's built from a ch32-data submodule and consumed through a path dep. The submodule sha is the single source of truth for both the chip JSON xtask reads and the PAC the algos link against.

flash-algorithms/
├── ch32-data/                  # submodule — pinned sha
│   └── build/                  # generated by `xtask --bootstrap-only` (gitignored)
│       ├── ch32-metapac/       # ← algo path dep target
│       └── data/chips/*.json   # ← xtask reads these
├── algos/{common,v0,v00x,v1,v3,l1,x0,h4,f1}/
└── xtask/                      # standalone crate, NOT in the algos workspace

xtask lives outside the algos workspace because Cargo validates every workspace member's manifest on any workspace command — including the ch32-metapac path dep that doesn't exist until xtask has run its bootstrap.

Clone

git clone --recursive https://github.com/ch32-rs/flash-algorithms

If you forgot --recursive:

git submodule update --init

Bootstrap

Generates ch32-data/build/data/chips/*.json and ch32-data/build/ch32-metapac/. Required once after a fresh clone or after bumping the submodule sha; safe to re-run (no-op if outputs are already present):

cargo run --manifest-path xtask/Cargo.toml -- --bootstrap-only

Building algos

Each algo crate's .cargo/config.toml pins its target triple, so cargo only picks it up when run from inside the crate:

cd algos/v0
cargo build --release

Generating target YAMLs

Runs the bootstrap (if needed), builds every algo, walks ch32-data/build/data/chips/, and emits one probe-rs YAML per (chip × memory_option) into generated/ (gitignored):

cargo run --manifest-path xtask/Cargo.toml

Bumping ch32-data

cd ch32-data && git fetch && git checkout <new-sha> && cd ..
rm -rf ch32-data/build
cargo run --manifest-path xtask/Cargo.toml
git add ch32-data && git commit -m "bump ch32-data to <new-sha>"

Formatting

cargo fmt --all from the repo root reaches into the generated ch32-data/build/ch32-metapac/ path dep and complains about code we don't own. Mirror CI instead:

find algos xtask -name '*.rs' -not -path '*/target/*' -print0 \
  | xargs -0 rustfmt --edition 2024

License

Dual-licensed under MIT or Apache-2.0 at your option.