osTimer Callback Context and Priority

[Soham Jani]

I'm using STM32L152RET with FreeRTOS (cmsis wrapper) for my product.

I'm struggling to understand the priority and context of the freertos "timer interrupt". We use a cmsis wrapper (code generated from CubeMX) and the freertos based timer task is referred to as an "osTimer" in CMSIS wrapper.

Can someone tell me which of this is correct ? The callback function triggered from the os timer

• runs with the priority of the timer task ?
• runs with the priority of the task from which the timer was created ?
• is in interrupt context and hence always the highest priority ?

To share more information :

Our systems has 3 tasks :

• Comm task (for cellular modem) (medium priority)
• AV task ( low priority ) - for scheduling LED and Buzzer PWM
• Service Task (High priority) - central event handling mechanism
• Timer Task ( (Highest - 1) priority as set up by freertos internal defines )

There is a case of priority inversion that I notice in the following scenario -

• The AV TASK calls appropriate LED and Buzzer Drivers and suspends on osTimer
• The Com Task starts executing from a separate event
• When the OS timer times out, it interrupts and triggers a callback function
  • The Callback function does not pend the lower priority Comm Task
  • It only executes after the comm task has completed it's execution
  • This causes the LED and Buzzer pattern to be distorted

The timer callback has the code to handle the pwm for of LED and Buzzer and in turn change the brightness and tone.

I would assume that the timer task has the highest priority and it gets the CPU time,and thus it's callback function will run at the same context and get CPU time, but that does not happen.

Any suggestions on how I can handle this or corrections in my theory ?

Thanks in advance

[Piranha]

In FreeRTOS all timer callback functions are called from timer task and therefore with it's priority. Also FreeRTOS has a priority inheritance mechanism:

Unlike binary semaphores however – mutexes employ priority inheritance. This means that if a high priority task blocks while attempting to obtain a mutex (token) that is currently held by a lower priority task, then the priority of the task holding the token is temporarily raised to that of the blocking task. This mechanism is designed to ensure the higher priority task is kept in the blocked state for the shortest time possible, and in so doing minimise the ‘priority inversion’ that has already occurred.

https://www.freertos.org/Real-time-embedded-RTOS-mutexes.html

> The AV TASK calls appropriate LED and Buzzer Drivers and suspends on osTimer

There is no such concept as suspending on timer.

[Soham Jani]

Piranha,

Thank you for the response. It makes sense that the timer callback function would run with the priority of the timer task.

We are not using a binary semaphore or mutex, so technically there should be no phenomenon of "priority inversion". According yo what you explained, the higher priority task (timer task) should get scheduler time an pend the lower priority task(av task). This is not happening.

Im trying to understand if there is a way I can solve the above problem.