Preemption of higher priority task

Kernel
21

ettocap wrote on Wednesday, August 26, 2015:

I set a breakpoint in this function. It never hits. I don’t use OS timer. I use STM32L4 hw timer to send task one event.

Regards.

22

rtel wrote on Wednesday, August 26, 2015:

The timer task is not related to hardware timers, only software timers.
You cannot call the ‘set bits from isr’ function unless the timer task
is being created - and I can see from your code that it is being
created, although at a low priority.

If xEventGroupSetBitsFromISR() is returning pdTRUE, then the ‘set bits’
message is being posted to the daemon task. However, if
vEventGroupSetBitsCallback() is not being called then either the daemon
task is not running, or the daemon task is running but the messages is
not being processed correctly.

You say you have “another task” at priority 2. Is that the timer
service task? Its priority is lower than the priority of your two
application tasks, but your two application tasks both block, so it
should get CPU time all the same. However, as a first experiment try
setting configTIMER_TASK_PRIORITY to ( configMAX_PRIORITIES - 1 ) in
FreeRTOSConfig.h.

Is the break point in vEventGroupSetBitsCallback() hit now?

Regards.

23

ettocap wrote on Wednesday, August 26, 2015:

OK, it works !

Indeed, the other task priority 2 was the timer service task. vEventGroupSetBitsCallback() was never called. Task TWO blocked the timer task.

I set configTIMER_TASK_PRIORITY to ( configMAX_PRIORITIES - 1 ), and it works. Timer service task is executed in priority. vEventGroupSetBitsCallback() is called. Task one is unblocked. (See results in attached .PNG file)

What is the best priority value for timer service task ? the highest value ?

Thanks a lot for your support.
Regards,
Fabien

24

rtel wrote on Wednesday, August 26, 2015:

…in which case the problem seems to be in the call to HAL_Delay(2), or at least, my assumption of what HAL_Delay() was doing.

I assumed HAL_Delay() was calling vTaskDelay() with a block time of 2 ticks. That would of allowed the timer task to execute.

However, looking at the code it appears HAL_Delay() delay is defined as:

__weak void HAL_Delay(uint32_t Delay)
{
  uint32_t tickstart = 0;
  tickstart = HAL_GetTick();
  while((HAL_GetTick() - tickstart) < Delay)
  {
  }
}

So - it is just polling the time and never entering the blocked state - hence it was preventing all lower priority tasks from ever executing at all.

HAL_Delay() is a weak function, so it looks like it should be overridden by an RTOS friendly version, such as:

void HAL_Delay( uint32_t ulTime_ms )
{
vTaskDelay( pdMS_TO_TICKS( ulTime_ms ) );
}

The best priority for the the timer task is dependent on the application - although having it at the highest priority is common, especially if you are using it as a deferred itnerrupt handler.

Regards.

25

ettocap wrote on Wednesday, August 26, 2015:

In my case, I think it’s better to set the highest priority.
In my release code, I rareley use HAL_Delay() and just for 1ms waiting. So, I think that I will not redefine it.
I call it a lot in my freeRTOS test project to measure the impact of an active waiting on OS scheduler.

Thanks for your advices.
Fabien