In Tickless Idle Mode Expected Idle Time is always less then 4

Kernel
1

rahimoval wrote on Friday, October 07, 2016:

Hi all,
I am using freeRTOS version 9.x.x on Freescale Cortex-M0+ port. I have configured tickless idle and using systick as normal context switch timer and during tickless idle the systick is deactivated and MCU specific 16 bit low-power timer (LPTMR) is activated to wake the MCU and make time adjusments to tick. It is working, but one problem which I heve is that in SuppressTickAndSleep the parameter xExpectedIdleTime is always less then 4, which is very short to put the MCU in LP-Mode. I am using timers with long periods (30 mins) and other my application tasks are blocked on queues waiting for messages. What am I doing wrong? Why the expected idle time is very short in my case?
Thanks in advance for your answers

2

xz8987f wrote on Saturday, October 08, 2016:

Hello,
I would say that you have something running with a period of about 4 ticks? Are you sure you don’t have a task or FreeRTOS timer running at the frequency. If you are debugging it with a Segger probe, you might use their SystemView (https://mcuoneclipse.com/2015/11/16/segger-systemview-realtime-analysis-and-visualization-for-freertos/) to see what is going on. If you are using Eclipse, then a Kernel awareness might be helpful (see https://mcuoneclipse.com/2016/07/06/freertos-kernel-awareness-for-eclipse-from-nxp/ and https://mcuoneclipse.com/2016/04/09/freertos-thread-debugging-with-eclipse-and-openocd/). I had a similar problem in the past in a huge software project where a task was polling a semaphore instead of using a larger timeout: that polling thrashed pretty much longer idle time.

I hope this helps,
Erich

3

rahimoval wrote on Saturday, October 08, 2016:

Hi,
thanks for your reply. I found the problem. My tasks were blocking on queues with limited delay times (exactly 5 ticks). I have defined these delay times to port max delay and everything seems to be ok now. Thanks for your links. I’ll definitely look through them