FreeRTOS Tickless Tick Correction Issue

RE: FreeRTOS Tickless Tick Correction Issue

Dave_couling — Tue, 21 Nov 2017 17:53:56 GMT

I've been seeing this issue recently with SDK 12.3. Was there any resolution you found?

RE: FreeRTOS Tickless Tick Correction Issue

jmag999 — Fri, 18 Dec 2015 16:20:29 GMT

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.

RE: FreeRTOS Tickless Tick Correction Issue

www.FreeRTOS.org — Fri, 18 Dec 2015 16:18:51 GMT

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.

RE: FreeRTOS Tickless Tick Correction Issue

Radoslaw Koppel — Fri, 18 Dec 2015 09:24:55 GMT

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?

RE: FreeRTOS Tickless Tick Correction Issue

jmag999 — Thu, 17 Dec 2015 01:20:39 GMT

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

RE: FreeRTOS Tickless Tick Correction Issue

RK — Wed, 16 Dec 2015 22:36:07 GMT

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.