Porting FreeRTOS to WCH CH32V307, It seems WCH has some serious issue about their RISC-V MCUs...

· · Web · 7 · 0 · 2

The processor itself implements an RV32IMAFCUX ISA, called RISC-V4A. However, someone at WCH decided it needs to be compatible with their Cortex-M chips, so they did a few things to make this processor more "ARM-ish".


The first thing I noticed is, instead of implementing a MTIME counter or CLINT, they put a so-called “SysTick” peripheral, but forgot to wire the counter rergisters to CSRs.

The SysTick peripheral is register-level compatible with the same peripheral used in Cortex-M, extended to 64 bit counter and compare register. and here are the register table:


Another interesting thing is, they also put these peripherals like SysTick and PFIC(their own NVIC implementation, we'll cover that later) at 0xE000_0000, which is PPB(Private Peripheral Bus) on Cortex-M processors.

After a day and a lot of effot, we finally got a working FreeRTOS (without modification) running on the MCU. Now we can finally talk about the exception model which WCH has made a lot of mess on...

RISC-V supports vectored and non-vectored exception handling, defined in a CSR called mtvec. The default handling mode is done by rewriting PC to vectored or non-vectored address defined in BASE.
However, WCH somehow decided that everything "Reserved" by specification can be used, so they simply added a third exception handling method in MODE field, something called "NVIC" by ARM...

The "PFIC" WCH has made is much alike the ones in Cortex-M, utilizing 0b11 MODE bit and BASE as vector table base address, the absolute addresses point to the handlers are stored based on a pre-defined number. Also, this "PFIC" supports nested interrupt handling and preemption. The vector table looks like the following:

What we can clearly tell from the picture above is WCH does not handle exceptions and interrupts seperately.. The ecall exceptions are fitted in the vector table, and will be vectored if the MODE bit set to 0b01 or 0b11...
The spec clearly described that only [Asynchronous interrupts] should be vectored, not exceptions...


This non-standard exception handling caused an unexpected result when RTOS is being used. Since the interrupt priority is fixed and interrupts are mixed with exceptions, the M mode ecall exception has higher priority than SysTick interrupt, so the SysTick interrupt won't fire while handing ecall exceptions due to preempt priorities.. However RTOS uses ecall instruction as yield function, so the scheduler mostly runs in M mode ecall exception routine.

It seems WCH also noticed this issue, however what they did is simply replaced the ecall instruction with a register write to their "PFIC", which pends a software interrupt with lower preemption priority than SysTick...

OK, it seems the vectored ecall handlers are not a problem. Got both vectored and PFIC mode working today.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!