I'm using the configUSE_TICKLESS_IDLE mode and in turn the vTaskStepTick method in order to correct the slept ticks.
When looking at the xTaskIncrementTick I wondered why this method takes care about the tick counter overflow and delayed lists, whereas the vTaskStepTick just adds the missing ticks.
A system that sleeps most of the time, would almost never call 'taskSWITCH_DELAYED_LISTS();'.
I think this is a bug if I don't missed something else.
An easy solution could be to call that 'taskSWITCH_DELAYED_LISTS()' within vTaskStepTick(), if the incremented xTickCount is less than before?
But easy solutions are usually not working.
Regards.
Thank you for taking the time to post these comments. As a gerneral rule we prefer potential bugs to be discussed on the support forum, with a bug report only being opened when the support discussion agrees it is a bug.
In this case the expected idle time is capped to the time at which the delayed and overflowed delayed lists are swapped, so the MCU will come out of deep sleep before the swap occurs, perform the swap, and then go back to sleep. That way vTaskStepTick() will never step the tick past the point of an overflow.
If you look at the variable xNextTaskUnblockTime in tasks.c you will see that when the blocked list is empty xNextTaskUnblockTime gets set to portMAX_DELAY (0xffffffff on a 32-bit system), so the next unblock time is the tick before the overflow, so the next tick performs the overflow management. The variable only appears a few times int he file so take a look and re-open this thread (in the support forum first) if you still think there is an issue. You will see xNextTaskUnblockTime = portMAX_DELAY; when the scheduler is started, and in a couple of places where the next unblock time is being set but the delayed list is empty.