Suspend not occurring on task it is being called from

Kernel
1

I am working on a custom RISVC 32i simulator and currently having issues with the vTaskSuspend actually suspending the task that it is being called from. I am creating two tasks with Task1 having priority 1 and Task2 having priority 0, both tasks create successfully. I start the scheduler and see that Task1 is being called continuously even after the tick interrupt (I enabled the call back configUSE_TICK_HOOK) and vTaskSuspend(NULL) has been executed by the function. I don’t understand why after Task1 executes the vTaskSuspend(NULL) and the next tick happens Task1 continues to execute even though vTaskSuspend(NULL) continues to be called for Task1 over and over. I looked into the vTaskSuspend function and see the correct handle to Task1 is being used and see that taskRESET_READY_PRIORITY is being called. It is defined as this in the RISCV portmacro.h (configUSE_PORT_OPTIMISED_TASK_SELECTION=1):

#define portRESET_READY_PRIORITY( uxPriority, uxReadyPriorities ) ( uxReadyPriorities) &= ~( 1UL << ( uxPriority ) )

Here is the assembly:
taskRESET_READY_PRIORITY( pxTCB->uxPriority );
8067ec: 02c42683 lw a3,44(s0)
8067f0: 00269793 slli a5,a3,0x2
8067f4: 00d787b3 add a5,a5,a3
8067f8: 00279793 slli a5,a5,0x2
8067fc: 0004a717 auipc a4,0x4a
806800: 1d470713 addi a4,a4,468 # 8509d0
806804: 00f707b3 add a5,a4,a5
806808: 0287a783 lw a5,40(a5)
80680c: 02079263 bnez a5,806830 <vTaskSuspend+0xb8>
806810: 00100793 li a5,1
806814: 00d797b3 sll a5,a5,a3
806818: fff7c793 not a5,a5
80681c: 0004a717 auipc a4,0x4a
806820: 34070713 addi a4,a4,832 # 850b5c
806824: 00072683 lw a3,0(a4)
806828: 00d7f7b3 and a5,a5,a3
80682c: 00f72023 sw a5,0(a4)

Do I have something misconfigured in FreeRTOS or does this appear to be an issue with simulator? If I have the two tasks at the same priority they switch between each other every time a ticks happens it just appears that I cannot suspend the task1 once it is already started the task. Thanks

2

If a task suspends itself it should call yield here: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/V10.4.6/tasks.c#L1790. For the RISC V port that translates into an ecall instruction here: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/V10.4.6/portable/GCC/RISC-V/portmacro.h#L95. That is a different mechanism to a context switch occurring in the tick interrupt, which simple makes a function call as at that time the context has already been saved https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/V10.4.6/portable/GCC/RISC-V/portASM.S#L214 - so it is possible for the tick interrupt to switch tasks of equal priority but not ecall if ecall is not implemented correctly, installed correctly, or the processor is not in machine mode. Check those three things.

3

Richard,

Thanks. I see the Yield being called at line 1790, I will look more at the ecall.

4

This was the issue as the ecall was not calling the mtvec. Thanks

5

Thank you for taking time to report back.