I’m trying to understand the CM3 /  GCC port implementation of vPortSuppressTicksAndSleep.  I think I understand everything except for the behaviour when entry to low power mode is aborted due to eTaskConfirmSleepModeStatus() returning eAbortSleep.

        /* If a context switch is pending or a task is waiting for the scheduler
        to be unsuspended then abandon the low power entry. */
        if( eTaskConfirmSleepModeStatus() == eAbortSleep )
        {
            /* Restart SysTick. */
            portNVIC_SYSTICK_CTRL_REG = portNVIC_SYSTICK_CLK_BIT | portNVIC_SYSTICK_INT_BIT | portNVIC_SYSTICK_ENABLE_BIT;
            /* Re-enable interrupts - see comments above the cpsid instruction()
            above. */
            __asm volatile( "cpsie i" );
        }

My understanding from the CM3 core documentation is that writing NVIC_SYSTICK_ENABLE_BIT will reload the value from the SYSTICK_LOAD_REG and start counting down.  Thus if the entry into sleep mode is aborted, the SYS_TICK interval is restarted, loosing any of the tick period that has elapsed so far. Given the amount of effort expended in trying to correct for lost clocks to the SYS_TICK timer when it is disabled and then re-enabled when the tick-less period is generated by extending the SYS_TICK period, this seems like a bit of an oversight.  I therefore expect I’ve missed a subtlety in the implementation. Can someone (Richard?) explain what I’ve missed and why restarting the SYS_TICK timer without making a prior adjustment to the reload register is OK? Thanks,
Phil.

You are correct, this is an anomaly.  It is very hard to get the code to go through that path, but for completeness it should be fixed. I think copying the current count value into the reload register, starting the timer, then resetting the reload register back to its “normal” value for a tick period should be ok. Do you agree? Regards.

Thanks Richard,   that’s exactly how I would resolve the issue.
 
There’s obviously going to be a small drift due to the time taken to execute eTaskConfirmSleepModeStatus which I guess could be estimated in the same way you’ve already done for the other path, but given the likely infrequent execution of this path compared with the normal path, it’s probably not that important.  I think it’s reasonable to expect some drift when using tick-less idle. Regards, Phil.