Quality RTOS & Embedded Software

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


xTaskPriorityDisinherit fails in configAssert

Posted by davidlcamlin on November 24, 2015

Hello, We upgraded FreeRTOS from v8.0.1 to v8.2.3 and now for a priority mutex (created using xSemaphoreCreateMutex) it triggers an assert in xTaskPriorityDisinherit function, this configASSERT( pxTCB == pxCurrentTCB ) line 3495 was not present in previous version of FreeRTOS. The way we use this mutex is we call:

Thread1 (low priority): xSemaphoreTake(handle, 0) //0 timeout to clear a delayed give from Thread2 -do some processing and set timeout to 600ms xSemaphoreTake(handle, timeout) -continue processing.

Thread2 (high priority): -process response xSemaphoreGive(handle).

pxTCB is Thread1 and pxCurrentTCB is Thread2. Basically we are trying to use it as an event to continue processing in Thread1 when the mutex was given in Thread2. Any idea what's wrong with this assert and why was it introduced?

Best regards, David.

xTaskPriorityDisinherit fails in configAssert

Posted by rtel on November 24, 2015

It was introduced after some optimisation in the code that gives a mutex from an ISR. One of the sub, sub functions called by the disinherit function is not safe to call from an ISR and a task simultaneously, hence the assert was added to allert people to this.

In this case though I'm not sure that you need to be using a mutex - can you use a binary semaphore instead? If you are just signalling one task from another you might even be able to use a direct to task notification, which is available in V8.2.3 (http://www.freertos.org/RTOS-task-notifications.html)


xTaskPriorityDisinherit fails in configAssert

Posted by davidlcamlin on November 24, 2015

But the assert shouldn't fail since we are calling from different threads. Maybe that assert should be ISR aware or not called at all? Indeed we could use a different mechanism but this means many changes to a code that was working and I believe we need the priority change of the mutex. Aren't binary semaphores supposed to be used for ISRs and not mutexes, as I've seen in their documentation? Best regards, David.

xTaskPriorityDisinherit fails in configAssert

Posted by rtel on November 24, 2015

Apologies - ignore the last post - I was talking about a different assert(), and the reply was not relevant.

You are talking about this assert(), right?


/* A task can only have an inherited priority if it holds the mutex. If the mutex is held by a task then it cannot be given from an interrupt, and if a mutex is given by the holding task then it must be the running state task. */ configASSERT( pxTCB == pxCurrentTCB );


This is actually another place where some code enhancements were made, in this case allowing a task to hold multiple mutexes, and ensuring it only disinherited a priority when it had given all the mutexes it was holding back (and not when it just gave the first one back).

A mutex is intended to be used as a mechanism for mutual exclusion. When used for mutual exclusion a task will take the mutex before it accesses a resource, and then must give the mutex back after it has finished accessing the resource in order to allow other tasks the possibility of accessing the same resource. In this scenario it is always expected that the task giving the mutex back is the task that took the mutex in the first place (something a lot of RTOSes insist on) - and the enhanced implementation assumes this is the case.

The priority inheritance mechanism is the only difference between a binary semaphore and a mutex, and the priority inheritance mechanism is only useful when using a mutex to guard access to a shared resource. If you are not using a mutex in that scenario then use a binary semaphore instead - your code should not need to change other than the function used to create the semaphore in the first place.


xTaskPriorityDisinherit fails in configAssert

Posted by davidlcamlin on November 24, 2015

Yes, that was the line of code that was triggering the assert. I've changed to binary semaphore and seems to be working fine now. Thank you for additional clarification for when to be used binary semaphore versus mutex. Best regards, David.

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

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.

Free TCP/IP and file system demos for the RTOS

Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists