Expected idle time seems incorrect in the idle task for sleep processing

Kernel
1

I’m working on a project where I have only one task is enabled (6 tasks created but not started). The task which is enabled has a timer associated with it, which basically enables the task to do some processing after 15 seconds periodically and the task has a busy wait of 5 seconds. So, whenever the idle task is scheduled to run(when the task gets blocked waiting for the timer to get expired), the expected idle time returned is coming like 100 ticks which doesn’t seems to be right since the block time of the task, which is enabled is 15 seconds. Could anyone explain what is the unit of expected idle time? The configTICK_RATE_HZ is 1000. Is there anyway to check the tasks which are in the ready queue?

2

Hi @abhilashdevapal,

Your intuition is right that the expected idle time should be higher. The expected idle time xExpectedIdleTime is of type TickType_t so it is measured in units of ticks. Since your project has configTICK_RATE_HZ set to 1000, you should regularly see expected idle times of 10000 or 15000. Are there other tasks or other active timers you are overlooking?

What do you mean by a task being “enabled”? What do you mean by tasks created but not started? Given your observations, could these other tasks actually be running?

3

Hi @jefftenney , thanks for your response.
There are 5 other tasks which got created before the control has been given to the freertos scheduler from the main(). All these 5 tasks have queues created for them and waiting for queue receive with portmaxDELAY. So basically these 5 tasks are blocked forever(I’m sure that this tasks will not get unblocked).

The task I mentioned as ‘enabled’ was created for the debug purpose to make sure that I’m getting the right expected idle time. By ‘enabled’, I meant the task which will be in the ready queue predictably.

4

I see. Is your debugger FreeRTOS aware? If so it can help you identify why the expected idle time is only ~100 msec. It can show you all of your task states and call stacks, and it can show you all your FreeRTOS timers. One of them will be responsible for your “unexpected” expected idle time.

What platform/port are you using, and which version of FreeRTOS?

5

Hi @jefftenney ,

The platform is windows and I’m using eclipse IDE with segger. FreeRTOS version is v10.2.0. Is there any way I can make the eclipse IDE freeRTOS aware(like installing some packages)?

6

Hi @jefftenney ,
I installed a package to make the debugger freeRTOS aware. In the task list, I’m not able to see the runtime status. Checking further I got to know that configGENERATE_RUN_TIME_STATS has to be enabled to see the run time status. But even after enabling it, I’m not able to see the run time status.

Timer list and Queue list is also not showing any data.

7

Since your debugging environment is not already FreeRTOS aware, I would suggest a different strategy. (You can always come back to using a FreeRTOS plug-in later.)

You could start eliminating pieces of your application code until you are left with only one task that sleeps for 15 seconds in a loop. At some point along the way, you should see the expected idle times you expect. :slightly_smiling_face: That process of elimination will help you identify the code that is causing strange expected idle times.

8

Hello @abhilashdevapal! Thanks for reaching out here - this sounds like an interesting one. I agree with Jeff, your delay period seems extremely low.

I just want to eliminate some simple things.

  1. How are you telling the timer to delay for 15 seconds? Are you using the pdMS_TO_TICKS macro when setting the timer period?
  2. How is your timer unblocking your one task which should run? Is it placing something into a queue for the task to consume? Or receiving a notification directly?
9

Another thought - to supplement Jeff’s. would be to start with the simplest possible task. So simple that you even get rid of the timer. You could have a single, simple task with task code that looks something like…

void extremelySimpleDelayTaskCode(  void * pvParameters  )
{
// Busy loop for X seconds
vTaskDelay(pdMS_TO_TICKS(15*1000));
}

Given this task is completely self contained (doesn’t rely on a queue or timer) you can use this to verify the time to tick calculation is correct.

Then you can build up from this and try integrating the timer you want.