FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2014 Threads] How can I identify what mutex a task is holding?Posted by gingernuts on October 24, 2014 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?
How can I identify what mutex a task is holding?Posted by davedoors on October 25, 2014 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.
How can I identify what mutex a task is holding?Posted by gingernuts on October 27, 2014 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
How can I identify what mutex a task is holding?Posted by rtel on October 27, 2014 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.
How can I identify what mutex a task is holding?Posted by gingernuts on October 27, 2014 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.
How can I identify what mutex a task is holding?Posted by gingernuts on October 30, 2014 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|