Yeah, I am using a SMP code base. Downloaded from github “FreeRTOS-Kernel.git”, branch “remotes/origin/smp”. We are debugging for why the softirq (which triggered the vTaskSwitchContext) was raised. i am not sure if there exist a bug on our riscv porting codes.
Yeah, that commercial company could support, but they are very slow, however I will keep going here.
I figure out this issue via analyze the task stack. However after this deadlock seqnence is clear, I found this issue could be easily seen just via code review of task.c.
So I start this topic because I am suspecting this is a common issue. vTaskSuspend() take TASK_LOCK and enable interrupt (which will make vTaskSwitchContext possible), so this deadlock is theoretically possible for current freertos kernel. So the fact is Freertos kernel may rely on the CPU ARCH porting to avoid this possible deadlock (e.g disable vPortYield), which i think is wrong behavior. At leaset Freertos kernel need provide a guideline or hint for this.
It seems that you are observing deadlock when calling portGET_TASK_LOCK from the same core. This indicates towards an incorrect implementation of portGET_TASK_LOCK - it is expected that it will not block when called from the same core recursively. You can take a look at the following links for a reference -