CH32V307 FLASH and RAM Configurability: A Common Pitfall and How to Avoid It

A developer on the WCH forum reported what looked like a bug:

> "I burned the GPIO and tcpserver examples into my custom board. At first everything worked. Later, burning the tcpserver example stopped working. After debugging, I traced it to the RAM size setting being different between the two examples. Using LinkUtility to reconfigure the RAM setting fixed it. Is this a widespread bug?" WCH's response: This is not a bug — it is a feature you need to understand.

The CH32V307 Memory Configuration

The CH32V307's FLASH and RAM sizes are configurable through WCH-LinkUtility. This flexibility lets you tailor the memory map to your application, but it introduces a common pitfall: the MCU configuration must match the linker script (ld file) in your project. When they do not match, the firmware may:

Appear to work initially (if the default config happens to align)
Fail mysteriously after re-flashing (if a different example changed the config)
Crash at runtime (if stack/heap boundaries are wrong)
Fail to boot entirely (if the vector table or initialization code lands outside valid memory)

How to Keep Them in Sync

Check the ld file in your project. Look for MEMORY regions defining FLASH and RAM origins and lengths.
Open WCH-LinkUtility and verify the FLASH/RAM configuration matches the ld file.
Before flashing, if you switch between projects with different memory layouts, reconfigure the MCU settings in LinkUtility.
Document your project's memory map so team members do not accidentally flash with the wrong configuration.

Example Memory Layout

A typical CH32V307 project might use:

MEMORY { FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 256K RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 64K }

If LinkUtility is set to 192K FLASH / 32K RAM but your ld file says 256K / 64K, the firmware will expect more memory than the MCU is configured to provide. The result is unpredictable behavior that looks like a hardware bug.

Why This Design?

The configurability exists because the CH32V307 (and related V3 family devices) share a die family with multiple memory options. Rather than fixed-fuse memory sizes, WCH uses a software-configurable approach that lets the same silicon serve multiple product tiers. This is cost-efficient but places the synchronization burden on the developer.

Bottom Line

If your CH32V307 firmware works in one project but fails in another, or stops working after flashing a different example, check the FLASH/RAM configuration in WCH-LinkUtility before assuming a hardware bug. The fix is usually a 30-second config change.

Source: 发现CH32V307的一个BUG — WCH official forum clarification Looking for RISC-V MCUs? The WCH CH32V307 ($3, Gigabit Ethernet) and the full CH32V series are available at open-riscv.com.