Is it atomic TCB transfer from ready/pending lists?

Kernel
1

is this a possible situation that may cause TCB losts?
for a re-entry irq handler, if this operation is not atomic, it may cause a TCB removed from one list and not insert to new list, or bitmap not updated synchronized?

2

Kernel data, which includes task lists, is always updated in a critical section to ensure that the update is atomic. This avoids any inconsistent state as you described above. Are you facing any issue?

3

yes, i found a task will not be scheduled after running serveral minutes. I use jtag to debug the code and found this task is in pxReadyTasksLists but not in uxTopReadyPriority, after set the corresponding bit to 1, and continue run, this task back to normal.

i used gcc cr5 porting as reference, and i guess taskENTER_CRITICAL() may not prevent higher priority irq re-entry since it just mask lower priority irqs.

currently, i try to use “cpsid/cpsie” to wrap " uxListRemove & prvAddTaskToReadyList operations", but not sure it completely solve the problem.

4

But you are not supposed to call any FreeRTOS API from higher priority IRQs. Are you doing that? Also, see this response - Understanding priority levels of ISR and FreeRTOS APIs - #16 by aggarg

Are you writing a new port? Which hardware is it?

5

Please see this: https://www.freertos.org/RTOS-ARM-Cortex-R5-Xilinx-UltraScale_MPSoC.html#ConfigAndUsage

6

thanks for your suggustion. i guess the problem may cause by interrupt prio settings.

for cortex R5, is systick timer irq priority MUST lower than configMAX_API_CALL_INTERRUPT_PRIORITY, or any suggestion value? currently, mine is 16, bigger than defaut 18. timer irq may run during xEventGroupSetBitsFromISR() function, the mask-irq protection is not effective now.

so , timer tick irq should always be lowest priority?

7

Not necessarily the lowest but it has to be less than or equal to configMAX_API_CALL_INTERRUPT_PRIORITY.