FreeRTOS Tickless Tick Correction Issue

[jmag999]

By default, the NRF_DEBUG is disabled. After enabling, and removing this assert check:

devzone.nordicsemi.com/.../

I am now hitting another one here:

#if ( configUSE_TICKLESS_IDLE != 0 )

	void vTaskStepTick( const TickType_t xTicksToJump )
	{
		/* Correct the tick count value after a period during which the tick
		was suppressed.  Note this does *not* call the tick hook function for
		each stepped tick. */
		configASSERT( ( xTickCount + xTicksToJump ) <= xNextTaskUnblockTime );

It appears that the ticks to jump is not correct.

[RK]

What's the actual error there? Is it the configASSERT() asserting or is it compilation error? If you preproccess that line to expand it, what do you get? I tried doing it in my head but it's deep and gnarly so it would be good to see what the compiler thinks it expands to.

[jmag999]

There is no build error. The configASSERT is asserting, usually within a minute of starting a debug session.

[Radoslaw Koppel]

Did you change anything in configuration? Most important here would be OS ticks frequency. I have to verify it according newest SD documentation - this may happen if SD would keep MCU busy unexpectedly long.

---

It looks that SD130 can keep MCU bussy for at most 1650us. If you are using default OS ticking frequency (1000 Hz), please try to update configEXPECTED_IDLE_TIME_BEFORE_SLEEP in FreeRTOSConfig.h to the value 3 - at value 2 it is prepared to support MCU blocking up to 1 OS tick. Are you using driver for data storing in FLASH?

[www.FreeRTOS.org]

That assert is a sanity check. When tickless mode is entered an expected maximum idle time is provided. The actual idle time may be shorted than the expected maximum - for example an interrupt may arrive - but it should never be greater than the expected maximum. If the assert is hit then the code is asking to step the tick past the time at which a task would otherwise have left the Blocked state due to a timeout, which means it is being stepped past what was otherwise the expected maximum idle time. I think that code is called before the scheduler is resumed, so it shouldn't happen. See www.freertos.org/low-power-tickless-rtos.html for more information.

[jmag999]

Yes, I agree that it shouldn't happen, which is why I am flagging it as an issue. I have not modified the tick time.