We are teaming up with the design agency @oakstudios to update our homepage and our brand. Goodbye social media blue, hello vibrant purple!
i.MXRT MCUs have an additional power mode which will automatically gate CPU core clock when WFI instruction is executed. This is the default behavior and I had no clue why debug connection was lost until I found this post: https://mcuoneclipse.com/2019/01/02/regaining-debug-access-of-nxp-i-mx-rt1064-evk-executing-wfi/
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
OK, it seems the vectored ecall handlers are not a problem. Got both vectored and PFIC mode working today.
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.
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:
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".