Call for testers: probe-rs flashing for the full (most?) CH32 family

[aq1018]

UPDATE

The whole set has been upstreamed to official probe-rs, but a new version is not yet released. You can now install from the official git repository:

cargo install --git https://github.com/probe-rs/probe-rs --locked probe-rs-tools

---

I've been migrating our flash-algorithms onto ch32-metapac in preparation to upstream to probe-rs. It's ready for daily-driver testing — please use it on your normal projects and leave a comment with how it went.

Supported chip families

Algo crate	Flash IP	Arch	Chip families	Status
algos/v0	flash_v0	Qingke-V2/V4	CH32V003, CH641	✅
algos/v00x	flash_v00x	Qingke-V2	CH32V002/4/5/6/7, CH32M007	✅
algos/v1	flash_v1	Qingke-V3	CH32V103	✅
algos/f1	flash_v1	Cortex-M3	CH32F103	🙏
algos/v3	flash_v3	Qingke-V4	CH32V2xx, CH32V3xx	✅
algos/x0	flash_x0	Qingke-V4	CH32X033/034/035, CH643	✅
algos/l1	flash_l1	Qingke-V4	CH32L103	✅
algos/h4	flash_h4	Qingke-V4	CH32H415/416/417	🙏

126 target variants total. Auto-detected — no --chip flag needed.
✅ = USER / SYSTEM / OPTION-BYTES flash verified on at least one chip in the family (algo is shared across the family).
🙏 = help wanted — no hardware report yet.

Install

cargo install --git https://github.com/ch32-rs/probe-rs --branch ch32 --locked probe-rs-tools

How to test

Set the cargo runner to probe-rs run in your project's .cargo/config.toml:

[target.'cfg(all(target_arch = "riscv32", target_os = "none"))']
runner = "probe-rs run" # no need for --chips, it auto-detects

(or your chip's target triple, e.g. [target.thumbv7m-none-eabi] for CH32F103). No --chip flag needed — auto-detection picks the right one.

Then cargo run your normal project. Confirm it flashes and your output shows up. That's it.

Tips

Confirm auto-detection with probe-rs info — it should print your chip's exact part number. On V2/V3 chips with a non-default OB.USER RAM/CODE split, the detected name includes the ram-code option suffix (e.g. CH32V305FBP6_c192_r128).

Verify the memory map with probe-rs chip info <chip> (chip name from the previous step):

CH32V003F4P6
Cores (1):
    - main (Riscv)
NVM: 0x08000000..0x08004000 (16.0 KiB)    # <-- USER Region
NVM: 0x00000000..0x00004000 (16.0 KiB)    # <-- Alias to USER Region (VMA)
NVM: 0x1ffff000..0x1ffff780 (1.9 KiB)     # <-- SYSTEM Region
NVM: 0x1ffff7c0..0x1ffff800 (64 B)        # <-- VENDOR Region, containing ESIG
NVM: 0x1ffff800..0x1ffff840 (64 B)        # <-- OPTION BYTES Region
RAM: 0x20000000..0x20000800 (2.0 KiB)     # <-- SRAM Region

Note, if you change RAM/CODE split in OB, the memory map should change as well

One caveat: use defmt-rtt, not ch32-hal's sdi-print. sdi-print requires wlink on the host to drain bytes; under probe-rs it busy-waits forever and your program will appear to hang.

In your comment: chip part number, did it flash, did you see output, anything weird.

[aq1018]

@andelf do you want to give it a try?

[andelf]

I'll check this later tonight. I have all the remaining chips.

[aq1018]

CH32V003 works!

❯ probe-rs chip info `probe-rs info`
CH32V003F4P6
Cores (1):
    - main (Riscv)
NVM: 0x08000000..0x08004000 (16.0 KiB)
NVM: 0x00000000..0x00004000 (16.0 KiB)
NVM: 0x1ffff000..0x1ffff780 (1.9 KiB)
NVM: 0x1ffff7c0..0x1ffff800 (64 B)
NVM: 0x1ffff800..0x1ffff840 (64 B)
RAM: 0x20000000..0x20000800 (2.0 KiB)

Flash & defmt-rtt works nicely. I also tested SYSTEM by flashing tinyboot and Option Bytes. They all work.

[acedogblast]

Hello I have tried to use defmt but I do not get any info! lines. It does detect, erase, flash, and reset the ch32v003.
I have added defmt = "1.1.0" and defmt-rtt = "1.2.0" to Cargo.toml and added the "-C", "link-arg=-Tdefmt.x" linker in config.toml. I did set DEFMT_RTT_BUFFER_SIZE = "128" since the default 1K is half of the ch32v003's SRAM.

Can you post an example project that uses defmt with your probe-rs fork?

Edit: I forgot to add use defmt_rtt as _; It works now. Thanks for the work in adding this feature.

[aq1018]

CH32V00X working:

❯ probe-rs chip info `probe-rs info`
CH32V006F8P6
Cores (1):
    - main (Riscv)
NVM: 0x08000000..0x0800f800 (62.0 KiB)
NVM: 0x00000000..0x0000f800 (62.0 KiB)
NVM: 0x1fff0000..0x1fff0d00 (3.2 KiB)
NVM: 0x1ffff700..0x1ffff800 (256 B)
NVM: 0x1ffff800..0x1ffff900 (256 B)
RAM: 0x20000000..0x20002000 (8.0 KiB)

Flash & defmt-rtt tested to be working.

probe-rs hardware breakpoints don't work. QingkeV2 has no hardware breakpoint support, use software breakpoints instead. They work fine.

E.g.:

  #[macro_export]
  macro_rules! breakpoint {
      () => { unsafe { core::arch::asm!("ebreak") } };
  }

I was able to use VSCode + probe-rs Debugger extension + breakpoint!() macro to step through code.

[aq1018]

CH32V103 is working. No hardware break point support either, but flashing system / optional bytes / user flash all work.

❯ probe-rs chip info `probe-rs info`
CH32V103R8T6
Cores (1):
    - main (Riscv)
NVM: 0x08000000..0x08010000 (64.0 KiB)
NVM: 0x00000000..0x00010000 (64.0 KiB)
NVM: 0x1ffff000..0x1ffff800 (2.0 KiB)
NVM: 0x1ffff800..0x1ffff880 (128 B)
NVM: 0x1ffff880..0x1ffff900 (128 B)
NVM: 0x1ffff900..0x20000000 (1.8 KiB)
RAM: 0x20000000..0x20005000 (20.0 KiB)

The system flash on this chip is split into two banks, and flashing optional bytes didn't work because probe-rs detected two flashing algorithms (system flash and ob flash) that covered the same region. This has been fixed on main.

[aq1018]

CH32V203 is now working. system / optional bytes / user flash all work. Again, Qingke V3B doesn't have hardware breakpoints. software breakpoints only. (use the macros mentioned earlier )

❯ probe-rs chip info `probe-rs info`
CH32V203C8T6
Cores (1):
    - main (Riscv)
NVM: 0x08000000..0x08038000 (224.0 KiB)
NVM: 0x00000000..0x00038000 (224.0 KiB)
NVM: 0x1fff8000..0x1ffff000 (28.0 KiB)
NVM: 0x1ffff700..0x1ffff800 (256 B)
NVM: 0x1ffff800..0x1ffff880 (128 B)
RAM: 0x20000000..0x20005000 (20.0 KiB)

note: system flash didn't work initially. this is because V3 flash require undocumented bits flipped in order to allow programming the system flash. See ch32-rs/ch32-data@62145f5 for more details.

[aq1018]

CH32V307 works. System/Option Bytes/User flash all work. Also break points works with VSCode, it supports max of 4 break points.

❯  probe-rs chip info `probe-rs info`
CH32V307VCT6
Cores (1):
    - main (Riscv)
NVM: 0x08000000..0x08078000 (480.0 KiB)
NVM: 0x00000000..0x00078000 (480.0 KiB)
NVM: 0x1fff8000..0x1ffff000 (28.0 KiB)
NVM: 0x1ffff700..0x1ffff800 (256 B)
NVM: 0x1ffff800..0x1ffff880 (128 B)
RAM: 0x20000000..0x20010000 (64.0 KiB)

We see RAM is 64KB, total flash size is 480K, with 256KB as 0wait, and the rest is non-0wait.

Now, changing Option Byte USER top 3 bits to 0b000 to get c192_r128 and flashed:

probe-rs download --binary-format bin --base-address 0x1ffff800 ob_c192_r128.bin

ob_c192_r128.bin is an 8 byte binary file that contains first 8 bytes of Optional Bytes (handcrafted)

❯ probe-rs read b8 0x1ffff800 8
1ffff800: a5 5a 1f e0 00 ff 00 ff
❯ probe-rs info
CH32V307VCT6_c192_r128
❯ probe-rs chip info `probe-rs info`
CH32V307VCT6_c192_r128
Cores (1):
    - main (Riscv)
NVM: 0x08000000..0x08078000 (480.0 KiB)
NVM: 0x00000000..0x00078000 (480.0 KiB)
NVM: 0x1fff8000..0x1ffff000 (28.0 KiB)
NVM: 0x1ffff700..0x1ffff800 (256 B)
NVM: 0x1ffff800..0x1ffff880 (128 B)
RAM: 0x20000000..0x20020000 (128.0 KiB)

Now we see RAM is 128KB, total flash size is still 480K, but 192K is 0wait, and the rest is non-0wait.

[YingliangCai]

CH32X035 works!

❯ probe-rs chip info `probe-rs info`                    
CH32X035F8U6
Cores (1):
    - main (Riscv)
NVM: 0x08000000..0x0800f800 (62.0 KiB)
NVM: 0x00000000..0x0000f800 (62.0 KiB)
NVM: 0x1fff0000..0x1fff0d00 (3.2 KiB)
NVM: 0x1ffff700..0x1ffff800 (256 B)
NVM: 0x1ffff800..0x1ffff900 (256 B)
RAM: 0x20000000..0x20005000 (20.0 KiB)

Flash & defmt-rtt works nicely.

[aq1018]

Do you mind testing hardware breakpoints? I think this is Qingke V4 so it should allow 4 breakpoints.

[YingliangCai]

Hardware breakpoint testing was successful; however, the CH32X035F8U6 is limited to 2 hardware breakpoints.

[aq1018]

Nice to know. Thanks!

[andelf]

CH32L103.
flash ✅
defmt-rtt ✅

> probe-rs info
CH32L103C8T6
> probe-rs chip info CH32L103C8T6
CH32L103C8T6
Cores (1):
    - main (Riscv)
NVM: 0x08000000..0x08010000 (64.0 KiB)
NVM: 0x00000000..0x00010000 (64.0 KiB)
NVM: 0x1fff0000..0x1fff0d00 (3.2 KiB)
NVM: 0x1ffff700..0x1ffff800 (256 B)
NVM: 0x1ffff800..0x1ffff900 (256 B)
RAM: 0x20000000..0x20005000 (20.0 KiB)

[andelf]

CH32X035F7P6, early batch with I2C bug.
flash ✅
defmt-rtt ✅

> probe-rs info
CH32X035F7P6
> probe-rs chip info CH32X035F7P6
CH32X035F7P6
Cores (1):
    - main (Riscv)
NVM: 0x08000000..0x0800c000 (48.0 KiB)
NVM: 0x00000000..0x0000c000 (48.0 KiB)
NVM: 0x1fff0000..0x1fff0d00 (3.2 KiB)
NVM: 0x1ffff700..0x1ffff800 (256 B)
NVM: 0x1ffff800..0x1ffff900 (256 B)
RAM: 0x20000000..0x20005000 (20.0 KiB)

[aq1018]

@andelf

Just a quick update for you:

• Rich Memory Layout ch32-data#36 is updated with your CH32H4 additions and merged into main.
• Metapac migration flash-algorithms#3 is merged into flash-algorithms
• https://github.com/ch32-rs/probe-rs is reorganized so master tracks upstream, and ch32 branch is our integration branch.
• Replace legacy CH32 targets with ch32-metapac generated family yamls probe-rs/probe-rs#4056 is the upstream PR (no chip auto-detect, will submit separate auto-detect upstream pr once first pr is upstreamed). chip YAMLs already merged and upstreamed, meaning you can use the official git version today, just without chip auto-detect.
• Add WCH-Link probe-based chip auto-detection for CH32 probe-rs/probe-rs#4057 - chip auto-detection.
• Fix: CH32H4 SYS region marked as read-only probe-rs/probe-rs#4058 - small patch to allow system flash writes.

In the mean time, do you mind testing CH32H4 chip(s)? I don't have them handy. You'll need to reinstall with this new command since integration branch is now ch32:

cargo install --git https://github.com/ch32-rs/probe-rs --branch ch32 --locked probe-rs-tools

Thank you!

Let me know if there is anything else you want me to do.

[holly-hacker]

Just tested on my end, for some reason flashing is a lot slower using probe-rs compared to wlink. With wlink, flashing 13kb to a CH32V203 happens in about a second while commit c28842d7 of probe-rs takes 3 seconds to erase flash and 7 seconds to flash the 13kb.

[aq1018]

@holly-hacker

Yes. This is something I observed this as well. I haven't had the time to dig deeper on why this is happening. But I believe the erase algorithm itself is probably the same. This could be an issue on the probe-rs side. The erase time could be partially explain by my tradeoff of using "fast erase", which erases in smaller chunks (512 bytes on v203 I believe), instead of 4kb per erase. But I cannot explain the write speed. The algorithm is using "fast write", so should be performing identically to wlink...