The corresponding setup items
OK, It turns out that this is not a new feature, and is made of two "screen"s. Here are the htoprc lines
@lamp I'm at 3.2.0 shipped from Arch Linux, but I don't know the exact version this feature was added.
OK, it seems the vectored ecall handlers are not a problem. Got both vectored and PFIC mode working today.
@Neo_Chen Getting started with... an HP 39GS :)
Currently using my 39GS Connectivity Kit on Windows 2k SP1, have no idea whether it works on XP..
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...
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.
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...
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:
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...
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...
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.