In the GCC/ARM_CM3 implementation of vPortSuppressTicksAndSleep, a SysTick interrupt could fire and pend a tick after the scheduler is suspended and before the SysTick has been stopped. ulReloadValue would then get calculated using the SysTick current-value-register that has just been refreshed and a value of xExpectedIdleTime that doesn't account for this recent tick. I think the result would be a SysTick wake-up scheduled a tick too late.

Is this reasoning correct?

This could conceivable happen if the Idle task started to run right at the end of a time slice (immediately before a tick interrupt).

I'm not sure the scenario you highlight adds any additional uncertainty than say, calling vTaskDelay( 1 ). A time measured in ticks is only accurate to the resolution of one tick period, so vTaskDelay( 1 ) could block for 0.001 of a tick period, or 0.999 of a tick period, depending on how far through the time clice it was called. However, unlike a pure vTaskDelay( 1 ), it could result in some time slippage - but that is noted in the code comments.

Anything that stops the timer will inevitably result in some time slippage forward or backwards (depending on the compensation value). The scenario you highlight could be mitigated by updating eTaskConfirmSleepModeStatus() so it returns eAbortSleep if a tick is pending (it already aborts if the tick attempted a context switch), but then you are more likely to abort a sleep, which in turn means you will be turning the clock off more often (when re-trying an aborted sleep) so I'm not sure you gain anythng.

Other than some clock slippage (relative to calendar time) - do you see anything actually dangerious in the implementation. By that I mean, somethign that could cause a crash, or lock up, etc.?

Regards.

Thanks for the fast reply.

Your example from "vTaskDelay( 1)" clarifies things and I think you are right that this scenario does not add any more uncertainty than that. I didn't see any other concern apart from clock slippage.