Run time statistics with tasks suspended before scheduler start

Kernel
1

I’m using FreeRTOS kernel V10.5.0, and I’m running into an issue where shortly after starting the scheduler the combined runtime% for my tasks significantly exceeds 100%.

I believe to have tracked down the cause of this to a task that is suspended before the scheduler is started. In vTaskSuspend it will do a context switch if the task that is being suspend is the one pointed to by pxCurrentTCB. The context switch will then attempt to update the runtime statistics by calling portGET_RUN_TIME_COUNTER_VALUE. However, the value returned by the macro is invalid because portCONFIGURE_TIMER_FOR_RUN_TIME_STATS is only called when starting the scheduler.

For now I can prevent the statistics from being invalid by checking in portGET_RUN_TIME_COUNTER_VALUE if portCONFIGURE_TIMER_FOR_RUN_TIME_STATS has already been called.
But I’m still wondering if this is a known issue, or if there is a flaw in my approach

2

Your assessment is correct.

Your workaround also seems correct.

Suspend/Resume is generally not recommended. Is there a reason to use suspend?

3

We have some tasks that require initialization that depends on the scheduler being started. So when creating the tasks they are immediately suspended to then be started by another task after the scheduler is started and initialization is done

4

There are some other ways you can consider to achieve the same:

  1. You can create a task at the highest priority which does all the initialization. No other task can run until this initialization task is done because it is the highest priority task.
  2. If you are using timers, you can set configTIMER_TASK_PRIORITY to the highest priority and use Daemon Task Startup Hook for initialization.