Tickless overrun issue using FreeRTOS, nRF52

[Michael Dierks]

Question about usage. I am using the nRF52, and ported product code that was running on the Alpha SDK11 to the release SDK11. I believe that what I will describe is a new issue, after the port, but I have not yet fully investigated the reverted build.

In the idle task (tasks.c), there is a section where the code decides that nothing is going on and it can perform a longer tickless sleep.

	#if ( configUSE_TICKLESS_IDLE != 0 )
	{
	TickType_t xExpectedIdleTime;

		/* It is not desirable to suspend then resume the scheduler on
		each iteration of the idle task.  Therefore, a preliminary
		test of the expected idle time is performed without the
		scheduler suspended.  The result here is not necessarily
		valid. */
		xExpectedIdleTime = prvGetExpectedIdleTime();

		if( xExpectedIdleTime >= configEXPECTED_IDLE_TIME_BEFORE_SLEEP )
		{
			vTaskSuspendAll();
			{
				/* Now the scheduler is suspended, the expected idle
				time can be sampled again, and this time its value can
				be used. */
         	    /* 	configASSERT( xNextTaskUnblockTime >= xTickCount ); */
                if (xNextTaskUnblockTime < xTickCount )
                {
                    ++xSkipCount;
                }

				xExpectedIdleTime = prvGetExpectedIdleTime();

				if( xExpectedIdleTime >= configEXPECTED_IDLE_TIME_BEFORE_SLEEP )
				{
					traceLOW_POWER_IDLE_BEGIN();
					portSUPPRESS_TICKS_AND_SLEEP( xExpectedIdleTime );
					traceLOW_POWER_IDLE_END();
				}
				else
				{
					mtCOVERAGE_TEST_MARKER();
				}
			}
			( void ) xTaskResumeAll();
		}

The only modification above is replacing the assert with a block that counts how often the condition happens, hitting the assert is less fun. The system is running on a 1ms tick rate.

The issue I am having is when I break at the ++xSkipCount, I am seeing that xExpectedIdleTime is > 0 (usually 12 to 50ms), but xTickCount is greater then xNextTaskUnblockTime by about 12 to 48. This is the spread I have observed, not definitive.

Following it thru, after the following call to prvGetExpectedIdleTime(), the next xExpectedIdleTime is a huge positive value as it is of UINT32 type (it should be -nn), which is always greater then the check, so the system schedules a sleep. The RTC trims the sleep time to maximum RTC duration and the system sleeps. The behavior after this is somewhat erratic, which prompted the investigation.

Has anyone observed this sort of behavior in a tickless RTOS project? It seems odd that the tick count can run so far ahead in the short execution space.

[www.FreeRTOS.org]

What is the frequency of the clock feeding the SysTick counter? There was somebody that had an issue when it was slowed right down to 32K (search for 2016 in the thread to find the start of the relevant part) - but they never reported back with the conclusion - in the thread there is also a link to a source file that shows how very slow clocks can be used, if that is indeed how your system is configured (very unusual).

[Michael Dierks]

Long weekend. I am running the SysTick from the RTC1 on the 32K XTAL. I am looking for very low power draw, which we have mostly.

I did review the link you provided, I could not access the low-power file included in the last few responses from "rtel" on that thread. I have seen some other posts on tickless and 32K operation. I will review those more. Suppose I will need a more complex trap on where I might be going when the clock tick values get separated.

[www.FreeRTOS.org]

Is RTC1 an up counter or a down counter? We have part specific examples for both types where the clock is 32K.

[Michael Dierks]

I am using the selection macros in the latest FreeRTOS port in the SDK 11. It configures the xSysTick to run from RTC1 interrupt, configured as a up-counting real-time counter, using the 32K external crystal as input. It is configured to count 1ms systick intervals, so approx 31 counts per systick.

[www.FreeRTOS.org]

Here is an example of an implementation that uses a slow (32K) up counting peripheral that you can use as a template. There are others in the download.