STM32 FreeRTOS port task priority, timeslicing and preemption question

Kernel
#1

straubm2610 wrote on Sunday, December 31, 2017:

Hi,

I’m on STM32L443, AC6 OpenSTM32 and FreeRTOS 10.0.

I assumed a blocked task of higher priority DOES NOT block any tasks, even of lower priority. They should happily run and be timesliced.

config USE_PREEMPTION and configUSE_TIME_SLICING are set.
I do NVIC_SetPriorityGrouping( NVIC_PRIORITYGROUP_4 );

So my (test and learning) configuration is:

TaskA (Prio 0) runs and creates TaskB (Prio 1), which immediately goes wait at a message buffer portMAX_DELAY.

Boom! System blocked. The xTaskCreate call creating TaskB not even returns. SysTick_Handler is never called.

Why? TaskB is Prio1, higher than TaskA, ok, but then it is blocked waiting at the message buffer.

TaskA is created by main.c before the scheduler is started, but that should not matter. SysTick should run BEFORE any tasks or anything are created in MX_FREERTOS_Init. Or is this a misconception of me?

That’s so basic I come to think, it is my fault.

#2

rtel wrote on Sunday, December 31, 2017:

I assumed a blocked task of higher priority DOES NOT block any tasks,
even of lower priority. They should happily run and be timesliced.

The scheduler will always run the highest priority task that is able to
run. So a higher priority task WILL ALWAYS block a lower priority task
any time it is not in the Blocked or Suspended state. I would recommend
having a look through this book to get an understanding of the
scheduling behaviour: https://www.freertos.org/Documentation/RTOS_book.html

config USE_PREEMPTION and configUSE_TIME_SLICING are set.
I do NVIC_SetPriorityGrouping( NVIC_PRIORITYGROUP_4 );

So my (test and learning) configuration is:

TaskA (Prio 0) runs and creates TaskB (Prio 1), which immediately goes
wait at a messagebuffer portMAX_DELAY.

Which means TaskB is in the Blocked state, and so TaskA should run again.

Boom! System blocked. The xTaskCreate call creating TaskB not even
returns. SysTick_Handler is never called.

So it seems the problem here is in fact that SysTick_Handler is never
called. Have you installed the FreeRTOS interrupt handlers? Are you
entering a critical section that you never exit?

Have a look at the “Special note for ARM Cortex-M users” section in the
answer to Q1 on this page of the FAQ: https://www.freertos.org/FAQHelp.html

If that doesn’t help please post the code of TaskB.

#3

straubm2610 wrote on Sunday, December 31, 2017:

Thanks for now. Happy 2018!

#4

straubm2610 wrote on Monday, January 01, 2018:

Solved.

Cutting a long story short: I had a spaghetti task structure and ended up with two tasks waiting at the same message buffer.

I still do not see how this could block out systick, but then … solved.

#5

richard_damon wrote on Monday, January 01, 2018:

If you mean the new message buffers, I think they have an assert to trap on that condition, and that assert disables interrupts and loops, which would stop the syystick. You should have noticed being stuck in the loop if you used a debugger.

#6

straubm2610 wrote on Tuesday, January 02, 2018:

I know that and it was nothing like that.