CH32V003 (and possibly the other WCH SoCs) cannot be used with multiple interrupts enabled

[andrei-edward-popa]

Describe the bug

It seems that on CH32V003 platforms, if multiple interrupts are enabled, the CPU stops and cannot even be programmed. What I tested was to have systick interrupt + uart interrupt enabled and the uart transmission stops unexpectedly. If I'm using only the uart interrupt (i.e. disable the systick interrupt) it works as expected. I don't think this was tested by anyone, to have 2 or more interrupts enabled at a time because, as I saw, for now only systick interrupt is enabled. The hang point is not deterministic, it can hang at any point (i.e. after 1 print using UART interrupt, after 2 prints, after n prints, in the middle of a print etc.). I'm not sure if this issue exists on the other SoCs, for now I only have CH32V003 boards.

• Target: CH32V003
• What I tried to diagnose this issue was to keep only 1 interrupt active. With 2 or more active the CPU stops unexpectedly and cannot even be programmed.
• It is not a regression

To Reproduce

Steps to reproduce the behavior:
Download uart_ints.zip, put it on the samples directory and run the following:
west build -b ch32v003f4p6_dev_board samples/uart_ints
west flash
or
west build -b ch32v003evt samples/uart_ints
west flash

Expected behavior

The example should print a message infinitely many times through UART interrupts.

Impact

The board is unusable with multiple interrupts enabled.

[VynDragon]

I would expect this is the device running out of interrupt stack or data storage somewhere, to make sure i would try with and without stack limit on ch32v20x or ch32v30x to see what happens, may not get to it for a while.

[andrei-edward-popa]

@VynDragon I forgot to mention, I increased the stack size of the ISR to 512 and the behavior was the same.

[VynDragon]

If it runs out of memory it will make little difference what the stack limit is without stack guards.

[andrei-edward-popa]

@VynDragon When you have some results/findings let us know, I'm really excited to see what is the problem here, especially if it is not the stack :)

[andrei-edward-popa]

@VynDragon Another findings from my side: Using CONFIG_MULTITHREADING=n, the provided example works as expected. Also, I reduced the stack size of the main thread to 256 B and the stack size of the ISR to 128 B and with CONFIG_MULTITHREADING=n also works.

[VynDragon]

Ok so not a stack issue then

[andrei-edward-popa]

@VynDragon So, let me describe what I found. It seems that the problem is from the idle thread. The idle thread calls internally k_cpu_idle, which calls the architecture specific arch_cpu_idle function. For RISC-V, this function executes a wfi instruction and does other stuff, but the important part is wfi. If I removed the __asm__ volatile("wfi"); line from arch_cpu_idle, the interrupts work as expected. I'm not sure what can be the problem with wfi here, maybe it is related to WFITOWFE bit from PFIC->SCTLR register that is set by default on the PFIC driver, but I'm not sure; I can test tomorrow. With CONFIG_MULTITHREADING=n the problem is gone because the idle thread is not present.

[VynDragon]

That is very helpful information. I intend to dig into this bug when i have the time and motivation, but you may figure it beforehand.

Edit: and looking at ch32 docs I think you may be right.

namely: 3) If the SEVONPEND bit in PFIC_SCTLR is configured, the interrupt controller does not enable the interrupt under, but when a new interrupt pending signal is generated (the previously generated pending signal does not take effect), it can also make the microprocessor wake up, and the corresponding interrupt pending flag needs to be cleared manually after waking up.

[VynDragon]

Maybe this is useful on how to fix it: https://github.com/cnlohr/ch32fun/blob/f61d201e95c7c0508c5860142da99c1e9b0f7975/ch32fun/ch32fun.h#L510

Edit: seems to be imiating ARM on that: https://developer.arm.com/documentation/ka005782/latest/
To me that bit looks like the issue.
I'd still apply the method of 'just set it to normal WFI and reserve WFE for power management code', if that is actually the issue.

[VynDragon]

Well i've started digging and now i'm confused on how the idle thread is supposed to work... Why is it calling wfi with IRQs locked 🤔

Suspect this hits the case described there by pure statistical chance: https://stackoverflow.com/questions/23305953/why-do-we-need-to-disable-interrupt-before-wfi-in-arm-linux-cpu-idle

not sure this is actually correct on riscv, but i know it works on CLIC platform so i need to understand why.

[andrei-edward-popa]

@VynDragon This is what I don't understand either right now, let me know when you figure it out. I'm trying to create a custom arch_cpu_idle for WCH, but even using __WFE from ch32fun.h it still doesn't work.