I have one external interrupt and the mtimer setup on a MIV32 (Softcore on polarfire). The interrupts only seem to trigger when a task is not actively running. I have put a infinite while loop in one of my tasks to test and it blocks all other tasks and xTaskGetTickCount() also doesn’t increment. I also don’t use taskENTER_CRITICAL() anywhere in my code.
I saw another post (called = risc-v-interrupts-not-enabled-in-xportstartfirsttask) mentioning enable problems on task init. It looks like during task switching or startup the interrupts are disabled.
I can in my while loop run the enable interrupts function (mstatus is then 0x1888) then add a freertos delay and when the delay ends the interrupts are disabled again (mstatus is then 0x1880) . The portASM.S im using is the one provided in the freertos miv32 example project (Compared to more recent ones I’ve found it looks functionially similar FreeRTOS Kernel V10.4.4).
Are the interrupt states loaded during task switching setup during xTaskCreate and some setup issue stores them as disabled?
This point in the “processed_source:” part always gives a t0 = 0x1880
/* Load mstatus with the interrupt enable bits used by the task. */
load_x t0, 29 * portWORD_SIZE( sp )
Where do the “interrupt enable bits” used by the task get set or changed?
Thanks for the response. Here is the link RISC-V - Interrupts not enabled in xPortStartFirstTask. It’s from two years ago and I think it might be related but I wasn’t completely sure that’s why I didn’t just comment my question there.
I haven’t found any other mention of interrupts being disabled during a tasks so I’m wondering if there is some FreeRTOS task setup I’m missing.
I have tried forcing the pxPortInitialiseStack to store 0x1888 (I’m assuming this is the tasks interrupt enable state) instead of 0x1880 but when it gets back to the processed_source: the pxCurrentTCB has a different mstatus as the one I forced during port init.
I’m sure there is a large chunk of the process I am misunderstanding, but interrupts should always be enabled outside of critical sections?
That is not true. First of all, a critical section only suppresses the range of interrupts that interferes with the OS. Sometimes, however, interrupts may need to be disabled globally. Second, although usage of the critical section should imho technically be restricted to OS usage, a lot of code abuses it as a very crude mutex mechanism, so there may be some third party library uses the CS over liberally - or (ab)use other interrupt disable strategies.
I will agree that an OS in which interrupts are disabled during mst task processing would be rather useless, so although I’m not familiar with your POD, I would call the behavior wrong if that is what happens.
Can you try stepping through the xPortStartFirstTask and see that the first task starts with interrupt enabled. The next step is to put a breakpoint in the trap handler and check the value of MPIE at this line (it should be 1). This mret should then set the MIE to 1. Let us know where MIE is getting set to 0.
Your problem seems so similar to the one you linked that I (in paranoia) checked the RISC-V assembly that we have. It is corrected per the related post you linked.
Your in xPortStartFirstTask function in the PortASM.s file should have these lines. You’re seeing these, right?