CH32V317 Flash Clock Frequency Configuration Guide

CH32V317 Flash Clock Frequency Configuration

A recent discussion on the WCH community forums raised an important question about Flash clock frequency configuration on the CH32V317 MCU. This is a critical configuration that affects both performance and reliability.

Background

The CH32V317 is WCH high-performance RISC-V MCU featuring:

• QingKe V4F RISC-V core up to 144MHz
• 480Mbps high-speed USB (USBHS)
• 10/100M Ethernet PHY
• 256KB Flash, 64KB SRAM
• Rich peripheral set (CAN, PDUSB, etc.)

The Question

A developer noticed uncertainty about the correct Flash clock frequency setting for the CH32V317. Setting the Flash wait state incorrectly can lead to:

1. Too few wait states: Flash read errors, random crashes, data corruption
2. Too many wait states: Reduced performance without stability benefit

Best Practices for Flash Clock Configuration

#### 1. Check Your System Clock

First, verify your system clock frequency:

uint32_t sysclk = SystemCoreClock;

#### 2. Set Flash Wait States Based on Frequency

For CH32V317 (and similar V4F core MCUs):

Configure in code:

FLASH->ACTLR = FLASH_ACTLR_LATENCY_2;

#### 3. Enable Flash Prefetch Buffer

For optimal performance, enable the prefetch buffer:

FLASH->ACTLR |= FLASH_ACTLR_PRFTBE;

Common Pitfalls

1. USBHS requires specific clock: When using USBHS at 480Mbps, the system clock must be set to 48MHz, 96MHz, or 144MHz
2. Ethernet PHY clock: The 10/100M Ethernet PHY has its own clock requirements
3. Debug vs Release: Flash latency settings affect debug behavior

Related Products

The CH32V317 ($4) is part of our WCH RISC-V MCU product line:

• CH32V003 ($0.1): Entry-level RV32EC, 48MHz
• CH32V208 ($1): BLE 5.3 wireless, 80MHz
• CH32V307 ($3): Gigabit Ethernet, 144MHz
• CH32V317 ($4): USB 480Mbps + Ethernet, 144MHz
• CH32H417 ($6): USB 3.0 dual-core, 5Gbps

For product inquiries, visit our product catalog or contact contact@open-riscv.com.

---

Source: WCH Community - CH32V317 Flash Clock Discussion

CH32V003 入门建议

CH32V003 是南京沁恒的 RV32EC 入门级 MCU，主频 48MHz，片上 2KB SRAM + 16KB Flash（部分型号），价格约 $0.1，非常适合 RISC-V 入门和成本敏感场景。

1. 开发环境

推荐使用 MounRiver Studio（基于 Eclipse 的官方 IDE），内置 GCC + OpenOCD 调试。

2. 最简 GPIO 闪烁代码

#include "ch32v00x.h"

int main(void) { GPIO_InitTypeDef gpio = {0}; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE); gpio.GPIO_Pin = GPIO_Pin_0; gpio.GPIO_Mode = GPIO_Mode_Out_PP; gpio.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOC, &gpio); while (1) { GPIO_WriteBit(GPIOC, GPIO_Pin_0, Bit_SET); for (volatile int i = 0; i < 80000; i++); GPIO_WriteBit(GPIOC, GPIO_Pin_0, Bit_RESET); for (volatile int i = 0; i < 80000; i++); } }

3. 调试 / 烧录

• 使用 WCH-Link（便宜，淘宝 ¥15 左右）
• 或 DAP-Link / JLink OB
• 烧录接口：SWD（2 线）

4. 常用外设

GPIO、USART、I2C、SPI、TIM（PWM）、ADC（10-bit）、看门狗，基本覆盖教学 / 简单控制需求。

如果要做 BLE，请升级到 CH32V208；如果需要以太网，请考虑 CH32V307。 如有更多问题，欢迎在论坛继续讨论或联系 contact@open-riscv.com

CH32V317 Ethernet Throughput Tuning: Pushing Past 15 Mbps TCP RX (WCH BBS Community Findings)

Building on the existing CH32V317 Flash / clock thread. There is a very practical follow-up question on the WCH BBS right now about how to actually get the CH32V317's built-in 100M Ethernet + PHY to deliver useful throughput. The WCH field engineer response (and a community follow-up) gives a clean answer that I want to surface here since this is the most common WCH-networking question in the last month:

Q (WCH BBS thread 159876): "How much real-world TCP throughput can the CH32V317's 100M Ethernet deliver? It feels similar to the CH32V307's 10M performance." A (WCH field engineering): Throughput is software-stack-bound, not MAC-bound. With a tuned WCHNET configuration the CH32V317 can sustain ~60 Mbps TCP TX (TCP client, 1460-byte packets, single direction) and 15 Mbps TCP RX with back-pressure enabled. Pure MAC loopback / UDP without stack overhead will line-rate the 100M PHY. Practical config changes (in net_config.h) to get the higher numbers: #define TCP_SEND_BUFSIZE_COUNT 16 // up from default 4 #define TCP_RECV_BUFSIZE_COUNT 16 // up from default 4 #define WCHNET_NUM_TCP_SOCKETS 8 // up from default 4 #define WCHNET_NUM_UDP_SOCKETS 4 #define WCHNET_TCP_MSS 1460 #define WCHNET_NUM_RX_BUF 32 // descriptor ring #define WCHNET_NUM_TX_BUF 16 #define WCHNET_TIMER_TICK_MS 5 #define WCHNET_RX_QUEUE_SIZE 32

These consume more RAM but are required to keep the pipeline full at 60+ Mbps. RAM cost on a CH32V317 (with 64 KB zero-wait flash + 160 KB non-zero-wait flash and 20 KB SRAM) is about 8-12 KB extra.

Note on TCP RX: the WCH engineer noted that the RX path is the slow side; on the first configuration pass TCP RX stays around 5-7 Mbps unless you explicitly enable back-pressure (set WCHNET_RX_FLOW_CTRL 1). With flow control on, TCP RX climbs to 15+ Mbps on the same hardware. Tying back to the original thread topic (clock config): the MAC needs HCLK at 96 MHz or 144 MHz to actually feed the descriptor ring at line rate. Running the system clock at 72 MHz (the default after reset) will cap the MAC throughput regardless of buffer tuning. Use the MRS clock-config wizard to lock HCLK = 96 MHz minimum for any real network use case. Caveats: - WCHNET is the in-house protocol stack; LwIP porting to the CH32V317 is also viable and typically gets 5-15% better RX throughput with the same buffers, at the cost of more code work. - CH32V317 vs CH32V307 ethernet: V317 has the same MAC + 100M PHY as V307 but runs at a higher HCLK ceiling and has a wider bus, which is why V317 is the right part for USB-to-Ethernet dongles. - If you are using CH32V317 in USB-to-Ethernet mode (USB HS 480 Mbps + 100M Ethernet), the USB CDC-ECM driver overhead will cap you at ~80-90 Mbps before you even hit the MAC ceiling. Source: WCH BBS thread 159876 (CH32V317 100M Ethernet throughput Q&A + community follow-up), https://www.wch.cn/bbs/thread-159876-1.html