A custom CH32H417 board froze when running USBHS Wi-Fi with tickless SysTick; switching to a fixed 1 ms SysTick resolved the symptom, pointing to a SDRAM timing/interaction issue.
CH32H417 Dual-Core Note: A SysTick vs SDRAM Freeze Workaround
The CH32H417 is WCH's high-end dual-core RISC-V MCU: a QingKe V5F performance core paired with a V3F core, 5 Gbps USB 3.0 (USBSS), 100 Mbps Ethernet PHY, dual high-speed ADCs, and external SDRAM support. A recent forum thread highlights a tricky interaction between the system tick timer and SDRAM that can freeze the V5F core.
Symptom: V5F Suddenly Stops Running
A developer building a custom CH32H417 board reported that the V5F core would suddenly stop executing when running the USBHS Wi-Fi stack. The symptoms were unusual:
- The freeze happened while the USBHS driver was active.
- After reproducing it without USBHS, the SWD debug port was still unresponsive.
- SDRAM self-tests passed in isolation, suggesting the memory was not simply failing.
The board used external SDRAM with a few fly-wire fixes for pin conflicts, which added another variable, but the core issue seemed to be a resource-contention or timing interaction rather than a pure hardware defect.
The Workaround: Switch to a 1 ms Periodic SysTick
After experimenting with the RTOS configuration, the developer found that using a
1 ms periodic SysTick made the problem disappear. The freeze had occurred under a
tickless idle configuration, where the OS dynamically stretches the tick interval to save power.
Why would tickless mode matter?
- In tickless mode, the SysTick is reprogrammed to fire after a variable number of clock cycles.
- Changing the SysTick reload value or entering a low-power state can alter the bus-clock and AHB matrix behavior around the SDRAM controller.
- If the SDRAM refresh or access arbitration is sensitive to that clock-domain switching, an occasional freeze becomes plausible.
This is not a definitive root cause, but it is a useful data point: for CH32H417 designs with external SDRAM and high-bandwidth USBHS traffic, a fixed 1 ms SysTick appears to be the more stable choice.
Recommended Debug Path
If you hit a similar freeze on CH32H417:
- Start with a fixed 1 ms SysTick and confirm stability.
- Check SDRAM timing parameters: refresh interval, row/column delays, and wait states. Keep them conservative until the system is stable.
- Verify that SDRAM and USBHS DMA do not contend for the same AHB bus segment; review the reference manual's bus matrix diagram.
- Use WCH-LinkE with a minimal test project to isolate whether the issue is core, memory, or software.
- If the problem persists, prepare a reproducible project and contact WCH FAE (lzs@wch.cn is the address mentioned in the thread). A minimal example is far more useful than a description.
Product Context
The CH32H417 is positioned above the CH32V307/317 family and below larger application processors. Its dual-core design makes it interesting for USB 3.0 peripherals and industrial gateways, but it also means two cores can compete for SDRAM and DMA bandwidth.
For teams already using WCH RISC-V parts, the CH32H417 ($6 range, USB 3.0, dual-core) is a natural upgrade when CH32V307 ($3, gigabit Ethernet) or CH32V317 ($4, HS USB) run out of bandwidth.
Source: CH32H417双核运行时systick和sdram的冲突问题 — WCH Microelectronics Community