To a running system (STM32F103) 4 tasks, FreeRTOS 10.3.1, CMSIS-Rtos v. 2.00,CMSISv2, I added a fifth task. When the system is running I can set a breakpoint in any of the 4 tasks (osPriorityNormal) and the BP is hit immediately. The fifth task happened to got set to osPriorityLow when I added it in the CubeMX IDE.
I’m wondering why this (osPriorityLow) task never gets hit. When I set it to the same priority (osPriorityNormal) as the other 4 tasks, the BP gets hit.
I noticed another bad thing happening: my task (which had a different name than the standard StartTask5, it was named KeyboardTask) got overwritten by the IDE code generation and wiped out my routine placed there (in the appropriate section)
/* USER CODE BEGIN Header_KeyboardTask */
/**
* @brief Function implementing the Task5 thread.
* @param argument: Not used
* @retval None
*/
/* USER CODE END Header_KeyboardTask */
void KeyboardTask(void *argument)
{
/* USER CODE BEGIN KeyboardTask */
/* Infinite loop */
for(;;)
{
osDelay(1);
}
/* USER CODE END KeyboardTask */
}
A FreeRTOS task is never scheduled if there is even one task is running with higher priority. This 5th task of yours will be scheduled only if all of the 4 other task of yours are delayed or in wait lists (e.g. waiting for a queue or semaphore or so).
As apal says, the issue is likely that one of your normal priority tasks never blocks, but is just in an Infinite polling loop. You mention the Cube, and much if its I/O routines are not really designed for use with an RTOS, as they will sit in polling loops.
Another possible issue is that you never reach a point where all the normal priority tasks will block at the same time, as the pass off “work” from one to another.
The only way a Low priority task runs is that ALL higher priority tasks are blocked
To analyse the scheduling of your FreeRTOS application, have a look at our tool Percepio View (Download View | Traceviewer). This is a free of charge community version of Percepio Tracealyzer.
