Tickless mode time drift

lantczak wrote on Monday, September 05, 2016:

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 +
configUSE_TICKLESS_IDLE = 1 (original implementation)
configEXPECTED_IDLE_TIME_BEFORE_SLEEP = 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.

lantczak wrote on Monday, September 05, 2016:

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

heinbali01 wrote on Wednesday, September 07, 2016:

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.

lantczak wrote on Friday, September 09, 2016:

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 portMISSED_COUNTS_FACTOR 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.