Daily Segger joke 1/1: Segger RTT is available in SES even you are using CMSIS-DAP debugger with it.

OK, It turns out that this is not a new feature, and is made of two "screen"s. Here are the htoprc lines

Show thread

Some "hidden" feature from the new htop utility, this tab is invisible until run as root user.

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

Show thread

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...

Show thread

7/?

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.

Show thread

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...

Show thread

6/?
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:

Show thread

5/?
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...

Show thread

4/?
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...

Show thread

3/?

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.

Show thread

2/?

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:

Show thread

1/?
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".

Show thread

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

Show older
Mastodon

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