I've run into a problem with an OS API call when running FreeRTOS on an NRF51 due to how ticks are corrected.
vTaskStepTick() is getting called while the MCU is awake and in in the middle of a FreeRTOS API call. This causes the API call to do the wrong thing because OS ticks is changed while the OS does not expect it to.
The vTaskStepTick() function is intended to correct the tick count after waking up from a tickless idle sleep. However, the call to this function is inside xPortSysTickHandler(). I'm seeing the following sequence of events:
- My application calls the vTaskDelayUntil() FreeRTOS API.
- vTaskDelayUntil() gets the current tick count and figures out the wakeup time.
- The radio takes control of the MCU
- The radio completes its time slice.
- The xPortSysTickHandler() function is called due to a pending sys tick interrupt
- xPortSysTickHandler() calls vTaskStepTick() because ticks were missed while the radio was running
- Control is returned to the vTaskDelayUntil() OS API function. At this point the OS Ticks variable 'xTickCount' has been changed due to vTaskStepTick().
- vTaskDelayUntil() calls prvAddCurrentTaskToDelayedList() with a wake time in the past.
- prvAddCurrentTaskToDelayedList() assumes that because the wake time is in the past, wake time has overflowed, so the task is added to the pxOverflowDelayedTaskList rather than the pxDelayedTaskList. This means the delay takes much longer than expected.
I don't believe vTaskStepTick() should be called while the vTaskSuspendAll() is called because the OS does not expect tick counts to change in this instance.
It appears to me that vTaskStepTick() should be called upon coming out of tickless idle mode. Moving this call would mean that tick counts never get corrected due to the radio preempting the MCU, however it would cause the OS to work more properly otherwise.
