Tickless mode time drift

Hi, I’m using tickless mode. I noticed that there is quite big time drift between freertos tick and real time value. I expect some tiny drift but my measurement results are 2s differencial in 15 min perion. I’m using timers to trigger some actions in the system and this value of drift is too big. My system: cortex m4 (atmel sam4e16e) + freertos 9.0.0 + configUSETICKLESSIDLE = 1 (original implementation) configEXPECTEDIDLETIMEBEFORESLEEP = 5 What about following code in port.c line. 526: ~~~ /* Stop the SysTick momentarily. The time the SysTick is stopped for is accounted for as best it can be, but using the tickless mode will inevitably result in some tiny drift of the time maintained by the kernel with respect to calendar time. */ portNVIC_SYSTICK_CTRL_REG &= ~portNVIC_SYSTICK_ENABLE_BIT;
    /* Calculate the reload value required to wait xExpectedIdleTime
    tick periods.  -1 is used because this code will execute part way
    through one of the tick periods. */
    ulReloadValue = portNVIC_SYSTICK_CURRENT_VALUE_REG + ( ulTimerCountsForOneTick * ( xExpectedIdleTime - 1UL ) );
    if( ulReloadValue > ulStoppedTimerCompensation )
    {
        ulReloadValue -= ulStoppedTimerCompensation;
    }

    /* Enter a critical section but don't use the taskENTER_CRITICAL()
    method as that will mask interrupts that should exit sleep mode. */
    __asm volatile( "cpsid i" );
    __asm volatile( "dsb" );
    __asm volatile( "isb" );
~~~ The ulReloadValue is calculated before critical section. If IRQ will occur just after calculation and before critical section then ulReloadValue will be inacurate.

Tickless mode time drift

I moved critical section just before calculation and no improvement. I found define portMISSEDCOUNTSFACTOR as I understand it can use it to tune sleep time

Tickless mode time drift

Good you found the portMISSED_COUNTS_FACTOR! There is indeed some drift in the clock-tick count when using tickless idle. A 2s difference in 15 minutes is a lot. How precise did you get it? What you could do is find another source to measure time. Use a 32-bit Timer-Counter and give it a very low tick-rate: choose a prescaler so that it overflows e.g. every 30 seconds or less often (frequent interrupts would increase the power consumption of your MCU). The measured time will then consist of two numbers: an interrupt count plus the actual value of the TC. Reading these two values requires some care, as an interrupt might occur while fetching them. You can either read them from with a critical section, or use the following method that allows for interrupts: ~~~~ extern unsigned long ulInterruptCount;
unsigned long ulSlowCount, ulCounts[ 2 ];
for( ;; )
{

    ulCounts[ 0 ] = tc_read_cv( TC0, ulTCChannel );
    ulSlowCount = ulInterruptCount;
    ulCounts[ 1 ] = tc_read_cv( TC0, ulTCChannel );

    if( ulCounts[ 1 ] >= ulCounts[ 0 ] )
    {
        /* TC0_Handler() has not occurred in between. */
        break;
    }
}
~~~~ Regards.

Tickless mode time drift

I found that my system is switching to/from tickless each 50ms. It is due to one of the tasks that has to be redesing to no interrupt so often. I suspect that high frequency of on/off (each on/off is adding some drift) actions is reason of 2s differencial. After increasing portMISSEDCOUNTSFACTOR I don’t have anymore problems with time drift. But what is supprising I had to increase it from 45 to 600. My CPU & SystTick is working on external 11MHz. Not sure why I need 600 processor cycles. The code when systick is off (reason of time drift) needs someting about 128 cycles on my CPU.