TL;DR: is there a reason why the design pattern below would cause me to fall foul of the assert configASSERT( pxTCB == pxCurrentTCB )
in xTaskPriorityDisinherit()
on a particular platform and, if so, what might I do about it?
Detail
My application needs to be able to create and destroy tasks dynamically. In order to organise task creation/deletion I’ve implemented a protocol which goes something like this:
Main Task Task A
--------- -------
creates queue A
creates mutex A
creates task A takes mutex A
<does stuff, taking data and commands from queue A>
...
sends "terminate" event on queue A
waits on mutex A
receives the "terminate" event on queue A
releases mutex A
destroys itself
releases mutex A
yields to idle for clean-up
This way the main task can know that Task A has been destroyed, everything is nice and organised and it can be repeated as required. It also relies on simple OS primitives so I can run it on any RTOS. This works on Espressif ESP32 (FreeRTOS V8.2.0 with their mods) and Nordic NRF52840 (FreeRTOS V10.0.0).
However I’ve just ported it to STM32F4 (FreeRTOS V10.2.1 and a much faster processor) and I’m now hitting the assert near the top of xTaskPriorityDisinherit()
:
configASSERT( pxTCB == pxCurrentTCB );
This is happening near the end of the procedure, according to the debugger at the point where the main task is trying to release mutex A. Not always but in certain task/priority/timing combinations which I haven’t yet figured out. The TCBs look perfectly valid when the assert is hit; the two tasks are Task A as pxTCB
(which has a higher priority than the main task and, I guess, has not been cleared up yet) and the main task as pxCurrentTCB
. All code is task code, no RTOS interrupt stuff going on (at least, not by my code).