STM32 FreeRTOS port task priority, timeslicing and preemption question

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 USEPREEMPTION and configUSETIMESLICING are set. I do NVICSetPriorityGrouping( NVICPRIORITYGROUP4 ); 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 MXFREERTOSInit. Or is this a misconception of me? That’s so basic I come to think, it is my fault.

STM32 FreeRTOS port task priority, timeslicing and preemption question

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 USEPREEMPTION and configUSETIMESLICING are set. I do NVICSetPriorityGrouping( NVICPRIORITYGROUP4 ); 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.

STM32 FreeRTOS port task priority, timeslicing and preemption question

Thanks for now. Happy 2018!

STM32 FreeRTOS port task priority, timeslicing and preemption question

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.

STM32 FreeRTOS port task priority, timeslicing and preemption question

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.

STM32 FreeRTOS port task priority, timeslicing and preemption question

I know that and it was nothing like that.