I work at STMicroelectronics and maintain a port for an internal core called STxP70, the compiler is an Open64-based.
To test this port, I use the Demo example provided with FreeRTOS, I run this Demo on various targets, hardware, simulators, TLM.
During the update to the latest version (8.0.1), some tests failed when using the cooperative scheduler (in this mode, I increment the timer in the IDLE task hook).
I analyze the issue for the recursive mutexes test (Demo\Common\Minimal\recmutex.c).
Version 8.0.1 of the scheduler introduces the new define taskYIELD_IF_USING_PREEMPTION that prevents a low priority task to yield if a higher priority task becomes ready.
The test fails in prvRecursiveMutexPollingTask task in the following sequence of code:/* We can resume the other tasks here even though they have a higher priority than the polling task. When they execute they will attempt to obtain the mutex but fail because the polling task is still the mutex holder. The polling task (this task) will then inherit the higher priority. The Blocking task will block indefinitely when it attempts to obtain the mutex, the Controlling task will only block for a fixed period and an error will be latched if the polling task has not returned the mutex by the time this fixed period has expired. */ vTaskResume( xBlockingTaskHandle ); vTaskResume( xControllingTaskHandle );
/* The other two tasks should now have executed and no longer
be suspended. */
if( ( xBlockingIsSuspended == pdTRUE ) || ( xControllingIsSuspended == pdTRUE ) )
xErrorOccurred = pdTRUE;
The calls to vTaskResume set the BlockingTask and ControllingTask tasks to the ready queue but the kernel does not schedule them because of the taskYIELD_IF_USING_PREEMPTION.
As a result, the Booleans xBlockingIsSuspended and xControllingIsSuspended are still to the pdFALSE value and the test fails.
The prvRecursiveMutexPollingTask task performs other checks on priority inheritance that also failed because the higher priority tasks do not try to get the mutex (as there are not scheduled).
According to my tests, there is a similar issue with AltQTest.c test.
Should I consider that this test can no more be performed using the cooperative scheduler ?
What is the goal of preventing a higher priority task to be scheduled in cooperative scheduler ?
Thank you for your support.