# Giving back an already Taken Mutex ends with a null uxMutexesHeld

**URL:** <https://forums.freertos.org/t/giving-back-an-already-taken-mutex-ends-with-a-null-uxmutexesheld/6830>\
**Category:** Kernel\
**Created:** [October 27, 2017, 4:02pm UTC](https://forums.freertos.org/t/giving-back-an-already-taken-mutex-ends-with-a-null-uxmutexesheld/6830 "2017-10-27T16:02:07Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [October 27, 2017, 4:02pm UTC](https://forums.freertos.org/t/giving-back-an-already-taken-mutex-ends-with-a-null-uxmutexesheld/6830/1 "2017-10-27T16:02:07Z")

</div>

**[hmnewsteo](https://sourceforge.net/u/hmnewsteo/)** wrote on [Friday, October 27, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/9998484b/#603a):

Hi

In a CortexM3 SiLabs EZR32, I use FreeRTOS (V7.5.2 provided with the IDE of my microcontroller) and a SPI port sharing five SPI devices : a SRAM, a FLASH, an accelerometer, an RF driver and a 3G Modem.  
The firmware periodically accesses to all of those devices.  
To protect access to the SPI port, I’ve used a mutex “xSPIMutex”.  
So before each acces to an SPI device, I call xSemaphoreTake(xSPIMutex, portMAX\_DELAY), and after each access I call xSemaphoreGive(xSPIMutex).  
SPI port is never used in an interrupt subroutine, but only called from a task.  
One of the tasks accessing to the PSI port has a higher priorty for the use of SPI. That’s why I added in this task :  
xSemaphoreTake(xSPIMutex, portMAX\_DELAY);  
vTaskPrioritySet(xTaskGetCurrentTaskHandle(), TASK\_USUAL\_PRIORITY + 1);  
before any access to the SPI port, and  
vTaskPrioritySet(xTaskGetCurrentTaskHandle(), TASK\_USUAL\_PRIORITY);  
xSemaphoreGive(xSPIMutex);  
after each acces.

My problem is that after a few seconds and a few volleys of access to the SPI port, a xSemaphoreGive(xSPIMutex) ends with a uxMutexesHeld = 0 :

- xSemaphoreGive(xSPIMutex) calls xQueueGenericSend
- xQueueGenericSend calls prvCopyDataToQueue
- prvCopyDataToQueue calls xTaskPriorityDisinherit
- xTaskPriorityDisinherit finds a blank pxTCB-\>uxMutexesHeld so when it calls configASSERT it enters a while(1); loop.

The problem does not occurin the task in which the priority is higher.

Here’s a part of FreeRTOSConfig.h :  
define configMAX\_PRIORITIES ( 4 )  
define configMINIMAL\_STACK\_SIZE (( unsigned short ) 140)  
define configTOTAL\_HEAP\_SIZE (( size\_t )(10000))  
define configMAX\_TASK\_NAME\_LEN ( 10 )  
define configUSE\_TRACE\_FACILITY ( 0 )  
define configUSE\_16\_BIT\_TICKS ( 0 )  
define configIDLE\_SHOULD\_YIELD ( 0 )  
define configUSE\_MUTEXES ( 1 )  
define configUSE\_RECURSIVE\_MUTEXES ( 0 )  
define configUSE\_COUNTING\_SEMAPHORES ( 0 )  
define configUSE\_ALTERNATIVE\_API ( 0 )/\* Deprecated! \*/  
define configQUEUE\_REGISTRY\_SIZE ( 10 )  
define configUSE\_QUEUE\_SETS ( 0 )

I’ve tried to increase “configQUEUE\_REGISTRY\_SIZE” and “configMINIMAL\_STACK\_SIZE” with no effect.  
“configTOTAL\_HEAP\_SIZE” can not be higher, as all available RAM seems to be already used.

For each SPI device, I’ve written a device\_select() and a device\_unselect() function where I take then give the mutex.  
Those functions are called before and after each access to SPI.

Could anyone help me ?

Thank you for any help.

Herve

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [October 27, 2017, 5:44pm UTC](https://forums.freertos.org/t/giving-back-an-already-taken-mutex-ends-with-a-null-uxmutexesheld/6830/2 "2017-10-27T17:44:54Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Friday, October 27, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/9998484b/#603a/d22b):

A problem here is that you are using a very old version of FreeRTOS so  
its difficult to give a definitive answer. However, it _might_ be  
because you are changing the task’s priority while it has the mutex.  
Mutexes have a built in priority inheritance mechanism which records the  
priority of the mutex holder and I’m not sure what would happen if you  
were to change the priority while the mutex was held - if nothing else  
the there would be an inconsistency in the data structures. The  
priority inheritance mechanism would probably make your manual  
manipulation of the priority obsolete in any case.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [November 7, 2017, 3:27pm UTC](https://forums.freertos.org/t/giving-back-an-already-taken-mutex-ends-with-a-null-uxmutexesheld/6830/3 "2017-11-07T15:27:54Z")

</div>

**[hmnewsteo](https://sourceforge.net/u/hmnewsteo/)** wrote on [Tuesday, November 07, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/9998484b/#6eba):

Hi  
Thank you for this answer.

In fact I already wanted to keep the same priority when I take and give the semaphore. Here’s the sequence : I take the semaphore, increase priority, use SPI, decrease priority and give back the semaphore. All other tasks that use this semaphore run with the same priority (I’ve tried to always be in the same priority when I take and give this semaphore).  
Now the problem is not on the SPI semaphore, but on the semaphore which protects the modem accesses.

I’ve just run my firmware without the priority change. I have the same problem : a xSemaphoreGive generates a null uxMutexesHeld.

Anyway, I’ve replaced all the FreeRTOS source files of my firmware by all the files of the last FreeRTOS version (V9.0.0, downloaded here : [https://sourceforge.net/projects/freertos/?source=typ\_redirect](https://sourceforge.net/projects/freertos/?source=typ_redirect)).  
I have not changed FreeRTOSConfig.h  
The project compiles.  
The problem is still there.

I’ve removed the xSemaphore Take and Give for the modem accesses and I’ve made sure that no other task could access the modem, and… I don’t have the problem any more.  
It’s very strange because the function only sends a simple ASCII command to the modem and what it does is :  
xSemaphoreTake(xModemMutex, portMAX\_DELAY);  
manage modem reception  
send radio frame (ASCII command to modem)  
send command to modem and wait for response  
send radio frame (ASCII response of the modem)  
wait 100ms  
xSemaphoreGive(xModemMutex); \<- the problem occurs here

Any idea ?  
Thank you !

Best Regards,  
Herve

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [November 7, 2017, 6:33pm UTC](https://forums.freertos.org/t/giving-back-an-already-taken-mutex-ends-with-a-null-uxmutexesheld/6830/4 "2017-11-07T18:33:31Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Tuesday, November 07, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/9998484b/#6eba/2426):

I suppose it could just be some form of data corruption clobbering the  
data structure?

You can find some quite detailed mutex tests in this file:  
[https://sourceforge.net/p/freertos/code/HEAD/tree/trunk/FreeRTOS/Demo/Common/Minimal/GenQTest.c](https://sourceforge.net/p/freertos/code/HEAD/tree/trunk/FreeRTOS/Demo/Common/Minimal/GenQTest.c)

- see functions such as prvHighPriorityTimeout(),  
prvTakeTwoMutexesReturnInDifferentOrder(),  
prvTakeTwoMutexesReturnInSameOrder(), prvLowPriorityMutexTask(), etc.