Unwise default for FreeRTOS Timer Task Priority. ST Employees might want to read this.

[DOsbo]

Hi All,

With CMSIS V1 the default priority for the FreeRTOS Timer Task is set to 2. In CMSIS V1 that is the highest priority for a thread (low numbers = high priority). In CMSIS V2 the priority scheme was reversed (high numbers = high priority). However the default priority for the Timer Task remained at 2. That means the Timer Task is now the lowest priority thread in the system (excluding idle).

The job of the Timer Task is to unblock higher priority threads. So unless I'm wrong, using the current default priority of 2 effectively disables much of its preemption capabilities.

I discovered this when my highest priority thread could not preempt low priority threads. It sometimes took several seconds to wake up when there was high demand from the lower threads.

So I think for CMSIS V2 the FreeRTOS Timer Task priority setting should be (MAX_PRIORITIES - 1) not 2.

Note, the change can make the threads much more responsive, but also have an unforeseen impact if the design relies on a delayed response.

Cheers

David

[KnarfB]

Sorry, I don't get your point. The timer task "Tmr Svc" is created in FreeRTOS, not CMSIS. It gets FreeRTOS priority 2. IIRR FreeRTOS priorities haven't changed for a long time. That timer task is used for handling FreeRTOS software timers, not task scheduling / unblocking. Right?

hth

KnarfB

[DOsbo]

Sorry you're right, FreeRTOS creates the timer task and hasn't got anything to do with CMSIS. That just means the timer task priority has been wrong from the start. This scenario fails because of the timer task low priority

void interrupt()
{
 xEventGroupSetBitsFromISR() // queue flag change to timer task
}
 
 
void high_priority_task()
{
 generate_interrupt();
 
 xEventGroupWaitBits() // <-- only wakes up when timer task has recieved the flag change.
 // Since timer task is the lowest priority, other tasks can prevent it
 // from processing the flag and the preemption
}

Sorry CMSIS people. When you changed your priority scheme I incorrectly assumed that was the cause of this issue.

[Piranha]

Probably you are using the wrong FreeRTOS primitive for the particular goal. If possible, task notifications should be the first choice.

https://www.freertos.org/RTOS_Task_Notification_As_Event_Group.html

xTaskNotifyFromISR() has significant performance benefits when compared to xEventGroupSetBitsFromISR() because xTaskNotifyFromISR() executes entirely in the ISR, whereas xEventGroupSetBitsFromISR() must defer some processing to the RTOS daemon task.

[KnarfB]

Allright. Sometimes we all mix things up. Since configTIMER_TASK_PRIORITY is defined in FreeRTOSConfig.h, you are free to set it to your needs. See also https://www.freertos.org/Configuring-a-real-time-RTOS-application-to-use-software-timers.html

[DOsbo]

I did change the timer task priority to 55 and my high priority tasks immediately got a 15% performance boost and latencies dropped from seconds down to a few milliseconds.

However, lets face it, most devs will accept the default value of 2.