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

Thank you for the question about the CH32V317WCU6 internal PHY driver type.

Based on the WCH community discussion, there has been some ambiguity between the datasheet and application notes. Here is a summary of the key points:

Current Understanding: The CH32V317 and CH32V307 share the same PHY IP (10M/100M Ethernet). The original documentation and community references indicate this is a current-drive type PHY, meaning the transformer PHY side center tap must connect to 3.3V. However, newer official documentation appears to label it as voltage-drive type, which has caused confusion. This discrepancy may stem from:

1. Documentation updates that were not synchronized across all materials
2. The PHY IP being revised in newer silicon revisions
3. The distinction being less critical for common magnetics modules that support both drive modes

Recommended Action: If you are designing a new board with the CH32V317WCU6, we recommend:

• Contacting WCH technical support directly via their forum or FAE channel for the definitive answer for your specific silicon revision
• Following the reference circuit in the latest official schematic package
• Using a magnetics module rated for both current and voltage drive modes as a safe fallback

For Ethernet-capable RISC-V MCU projects, the CH32V307 ($3, gigabit MAC + 100M PHY) and CH32V317 ($4, 100M PHY + 480Mbps USB) remain strong choices for connected embedded systems.

We also stock K1-based gateway solutions that can pair with these MCUs for edge computing + networking applications. Source: WCH Forum - CH32V317 Internal PHY Driver Type

Another CH32V317 networking issue was reported on the WCH forum this week and may be relevant to anyone building networked devices with this MCU.

Reported symptoms

The user observed two issues while using the WCHNET stack on CH32V317:

1. Multiple UDP sockets: net_config.h was set to support two UDP sockets, but the second socket appeared to be created successfully while not actually working. The SocketInf array also did not reflect the second UDP socket.
2. TCP socket state display: after a TCP server accepted a remote connection, the SocketInf array showed the state as TCP_FIN_WAIT_1 even when the socket should have been in TCP_LISTEN or TCP_ESTABLISHED.

Official response

WCH support confirmed that multiple UDP sockets work in their own tests and suggested the user send the project code for review if the issue persists.

For the TCP state display, the support team clarified that the value in SocketInf is the socket state, not the full TCP state machine. Their test showed a printed value of 0x05, which represents the socket state in the WCHNET abstraction layer. Developers should not map that value directly to TCP_FIN_WAIT_1 semantics.

Practical takeaway

When porting existing TCP/UDP code to CH32V317, treat SocketInf state values as WCHNET-specific socket-layer states rather than literal TCP states. If you need fine-grained TCP state tracking, add your own state machine on top of the socket API.

Source: 关于CH32V317的网络，可能是BUG，麻烦关注一下 on WCH Community

Quick follow-up on the WCH Ethernet family, from the official forum this week (Sep 20, 2026):

• A user asked whether the CH32H417 supports lwIP. Official reply: yes, lwIP is supported, but there is no official example yet - WCH still recommends the in-house WCHNET stack shipped in the EVT, and self-porting lwIP is the documented path for lwIP-based teams. (wch.cn thread 161401)
• WCH has also published an RGMII reference design with example code for the H417 (thread 161112), which is the natural hardware bring-up base for any protocol stack on this part.

Practical takeaway for CH32V307 / CH32V317 users: WCHNET remains the best-supported path with full example parity. If you standardize on lwIP across a multi-family fleet, budget real time for the ethernetif glue and the sys_arch port, and start MAC/PHY init from the EVT example rather than from scratch.

We published a longer write-up on the blog: "CH32H417 Ethernet: lwIP Support Status and a Realistic Porting Path". Source: https://www.wch.cn/bbs/thread-161401-1.html