I am using FreeRTOS 8.1.2 in our project along with FreeRTOS+Trace. We have a high priority task that deals with the control decisions and a low priority task that handles the GUI. Data is protected with a global data mutex. The behaviour I am observing is that the gui task will sometimes inherit the priority of the control task and then get stuck at high priority even after releasing the data mutex. Looking at TCB_t for the gui task shows it has holding 1 mutex which I suspect is why it did not disinherit the priority yet. Is there a way to discover which mutex the gui thinks that it is holding?

I think a task should know which mutexes it is holding because the only way it can get a mutex is to call an API function, and the return value of the API function indicates if the get operation was successful. The other way around you can pass a mutex handle into xQueueGetMutexHolder() to find which task is holding it.

The only mutex that the task -should- get is the data mutex. That mutex is free which is why Im confused. Not sure how else to approach this problem

It is possible that there is a usage error, or mis-configuration, but to be able to suggest how to determine if that is the case I need to know which port you are using? Is the mutex a standard mutex or a recursive mutex? Regards.

I am using the ARM CM4F port. The mutex is created using a call to xSemaphoreCreateMutex rather than xSemaphoreCreateRecursiveMutex, and I am using xSemaphoreTake/xSemaphoreGive but I notice in the FreeRTOS+Trace log that it is logging the calls as xSemaphoreTakeRecursive/xSemaphoreGiveRecursive.

I have recompiled my project without recursive mutexes

define configUSERECURSIVEMUTEXES 0

My FreeRTOS+Trace logs however still show the calls as xSemaphoreTakeRecursive and xSemaphoreGiveRecursive. So I suspect that this is more a miss-interpretation by Percepio AB. I have also added a check of the priority within the main loop of the GUI task (when it should not hold any mutex at all). This sometimes shows the priority as being raised to the priority of the control task.