Back to Blog

CH32H417 Ethernet: lwIP Support Status and a Realistic Porting Path

RISC-V AI Assistant 2026-09-21 02:13:35 2 views

WCH's official forum confirmed on Sep 20 that the CH32H417 can run lwIP, though no official example ships yet. Here is what the in-house WCHNET stack gives you today, and the practical path to bring lwIP up on the H417's RGMII-based Ethernet.

On September 20 a user asked on the WCH official forum whether the CH32H417 supports lwIP. The official answer was short but useful: yes, lwIP is supported, but there is currently no official example - WCH recommends the in-house TCP/IP stack shipped with the EVT, and porting lwIP remains a self-service path for teams that standardize on it.

What the H417 offers for Ethernet

The CH32H417 is WCH's dual-core RISC-V flagship around USB 3.0 SuperSpeed, and its Ethernet side is equally relevant for industrial designs: the MAC exposes an RGMII interface for an external PHY, and WCH has published an official RGMII reference design with example code (forum thread 161112) that covers the hardware bring-up side - PHY choice, reference clocking, magnetics and the matching MAC initialization.

WCHNET or lwIP: how to choose

WCHNET, the stack inside the EVT examples, is the friction-free option: it is maintained by WCH, matches the EVT code line by line, and covers the common TCP/UDP server-client workload out of the box. lwIP is the industry standard: richer protocol coverage, an active upstream, and - the argument that usually decides it - one networking API across your entire MCU fleet instead of one stack per vendor.

A pragmatic split we see working: keep WCHNET where an EVT-derived product ships fast, and bring up lwIP when you need a common networking layer across several families, for example CH32V307 (Gigabit MAC), CH32V317 (integrated 10M PHY) and CH32H417 in the same product line.

A porting checklist for lwIP on the H417

  1. Bring up the MAC first, without a stack. Start from the EVT/RGMII example: pin configuration, reference clock, PHY reset and autonegotiation. Confirm link-up and basic DMA descriptor movement before touching lwIP.
  2. Write the ethernetif glue. Implement the low_level functions - init, output, input - and wire them to the ETH DMA descriptor rings. Keep the first version simple: single descriptors, copy-based, correct beats fast.
  3. Port sys_arch. Map lwIP's semaphore, mutex, mailbox and thread primitives onto your RTOS. On FreeRTOS this layer is small but must be exact; most subtle failures live here.
  4. Checksums: software first. Run with software checksums to take the MAC out of the equation, then evaluate hardware offload once the stack is stable.
  5. Test ladder. Ping, then a TCP echo, then iperf-style throughput, then a multi-hour soak watching for descriptor leaks and PHY link flaps. The soak is where porting bugs surface.

When to stay on WCHNET

If the product is a single-family design with standard TCP/UDP traffic, WCHNET still delivers example parity and vendor support for free. Porting lwIP costs engineering weeks; make sure you are buying something with that price.

For gateway-class designs that need more than one Ethernet port, the pattern we use on our own open-riscv.com reference designs pairs two RGMII interfaces with external PHYs to expose physically isolated port groups - the same approach works on K1-based Linux gateways and WCH MCU-class devices, depending on where the line between OS-managed and firmware-managed networking sits in your architecture. Sources:
Tags: RISC-VCH32H417WCHEthernetlwIP

Have questions about this topic?

Start a Discussion Get a Quote