Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS