# Failing configASSERT in xQueueGiveFromISR and vPortEnterCritical on migration to 10.0.0 from 7.3.0 **URL:** \ **Category:** Kernel\ **Created:** [August 6, 2019, 7:34pm UTC](https://forums.freertos.org/t/failing-configassert-in-xqueuegivefromisr-and-vportentercritical-on-migration-to-10-0-0-from-7-3-0/7998 "2019-08-06T19:34:15Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [August 6, 2019, 7:34pm UTC](https://forums.freertos.org/t/failing-configassert-in-xqueuegivefromisr-and-vportentercritical-on-migration-to-10-0-0-from-7-3-0/7998/1 "2019-08-06T19:34:15Z")
**[adityas](https://sourceforge.net/u/adityas/)** wrote on [Tuesday, August 06, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/3307221f7f/#3411): Hi, I have been tasked with migrating to FreeRTOS 10.0.0 on my Atmel SAM4E8C(A) chip which was originally running the 7.3.0 kernel. It has not been as out-of-box replacement as my initial research impressed on me, but bear with me, as I am new to RTOS. I have updated the Atmel Software Framework (ASF) to 3.40 (from 3.34) to upgrade to FreeRTOS 10.0.0 (it does not seem like the ASF supports 10.2.1 yet, otherwise I would have gone for that, though the release notes do not indicate I am missing out for my MCU core). Atmel Studio 7 is my IDE, and I am using the standard Atmel ICE for debugging. 1. Issue: The local\_uart\_handler() has a xSemaphoreGiveFromISR macro that used to be defined as xQueueGenericSendFromISR (7.3.0) and is now xQueueGiveFromISR. While I think this makes sense, the following ASSERT condition is failing. ```auto configASSERT( !( ( pxQueue->uxQueueType == queueQUEUE_IS_MUTEX ) && ( pxQueue->pxMutexHolder != NULL ) ) ); ``` Both the checks evaluate to TRUE, and hence the ASSERT fails. What am I supposed to do here, as these are 3rd party files that I really don’t want to hack around? 1. Issue: I am also failing the Assert condition in the use of vPortEnterCritical(). ```auto configASSERT( ( portNVIC_INT_CTRL_REG & portVECTACTIVE_MASK ) == 0 ); ``` What extra items need to be in place for this to pass in 10.0 that were not required in 7.3.0? Side note: I don’t feel this is relevant, but recognising gaps in my understanding: I found the ASF update did not acquire the correct type folder in …\env\atmel\src\ASF\thirdparty\freertos\freertos-10.0.0\Source\portable\GCC. The original import was for ‘ARM\_CM3’, while this should have been ‘ARM\_CM4F’ (my verification being that the #ifndef **VFP\_FP** check triggered a fail when switched to #ifdef). I directly copied this folder in at the relevant location and pointed the library search path to this. Any help or suggestions would be much appreciated. Thanks. Regards, Aditya ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [August 7, 2019, 1:20am UTC](https://forums.freertos.org/t/failing-configassert-in-xqueuegivefromisr-and-vportentercritical-on-migration-to-10-0-0-from-7-3-0/7998/2 "2019-08-07T01:20:23Z")
**[richard\_damon](https://sourceforge.net/u/richard_damon/)** wrote on [Wednesday, August 07, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/3307221f7f/#ca7e): A Mutex inherently should be taken and then given back by the same task, its owner. I beleive earlier versions of FreeRTOS did not enforce this restriction, but some changes in how priority inhertance worked required it, It really makes no sense for an ISR to give a Mutex, is it doesn’t make sense for it to take it in the first place. The second assert looks to be using a non-ISR API function inside an ISR. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [August 13, 2019, 10:17am UTC](https://forums.freertos.org/t/failing-configassert-in-xqueuegivefromisr-and-vportentercritical-on-migration-to-10-0-0-from-7-3-0/7998/3 "2019-08-13T10:17:52Z")
**[adityas](https://sourceforge.net/u/adityas/)** wrote on [Tuesday, August 13, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/3307221f7f/#48e3): Thank you Richard, especially for the quick response. You are correct. It was actually some interface files provided by Atmel ASF for FreeRTOS that were incorrect in their previous version. In fact, most issues seem to be related to ASF files rather than FreeRTOS. I’ve had to spend a few days sourcing and refactoring these files, and understanding the code structure to a point I can (somewhat) follow what is going on. For the second issue, the code was using vPortEnterCritical()/vPortExitCritical() in an ISR, so swapped that out for portSET\_INTERRUPT\_MASK\_FROM\_ISR() / portCLEAR\_INTERRUPT\_MASK\_FROM\_ISR(). ---
**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:** [August 13, 2019, 1:40pm UTC](https://forums.freertos.org/t/failing-configassert-in-xqueuegivefromisr-and-vportentercritical-on-migration-to-10-0-0-from-7-3-0/7998/4 "2019-08-13T13:40:09Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Tuesday, August 13, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/3307221f7f/#48e3/98ee): The simplest change would be to use a binary semaphore instead of a mutex - that just requires the function used to create the semaphore to be changed. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [September 20, 2019, 3:09pm UTC](https://forums.freertos.org/t/failing-configassert-in-xqueuegivefromisr-and-vportentercritical-on-migration-to-10-0-0-from-7-3-0/7998/5 "2019-09-20T15:09:47Z")
**[adityas](https://sourceforge.net/u/adityas/)** wrote on [Friday, September 20, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/3307221f7f/#070b): Hi, I thought it best to continue this thread, as my question is a resultant of work on this. Hopefully it is explained well enough below. We have a structure on which activity is commenced in a task (after acquiring a mutex) and activity on it is completed in an interrupt handler (which is where the mutex was being released). With 10.0.0, Mutex is not allowed to be given in an interrupt with the newer version of FreeRTOS. But, as far as I can tell right now, conversion to binary semaphore instead of mutex will not be a good idea. I do want to protect the access ot this structure, and ensure completion before it is reset. I have been unable to find (perhaps understand) similar situations. One thought I have is using a deferred interrupt handling that uses a task notification to release the mutex. But this is essentially ending up using a binary semaphore to release a mutex. Is there a better solution? ---
**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:** [September 20, 2019, 3:21pm UTC](https://forums.freertos.org/t/failing-configassert-in-xqueuegivefromisr-and-vportentercritical-on-migration-to-10-0-0-from-7-3-0/7998/6 "2019-09-20T15:21:35Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Friday, September 20, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/3307221f7f/#070b/271e): The only difference between a binary semaphore and a mutex is that mutexes implement a priority inheritance mechanism and binary semaphores don’t. You can protect access to a resource using a binary semaphore too. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [September 30, 2019, 9:50am UTC](https://forums.freertos.org/t/failing-configassert-in-xqueuegivefromisr-and-vportentercritical-on-migration-to-10-0-0-from-7-3-0/7998/7 "2019-09-30T09:50:15Z")
**[adityas](https://sourceforge.net/u/adityas/)** wrote on [Monday, September 30, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/3307221f7f/#0163): ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [September 30, 2019, 9:50am UTC](https://forums.freertos.org/t/failing-configassert-in-xqueuegivefromisr-and-vportentercritical-on-migration-to-10-0-0-from-7-3-0/7998/8 "2019-09-30T09:50:31Z")
**[adityas](https://sourceforge.net/u/adityas/)** wrote on [Monday, September 30, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/3307221f7f/#68ea): ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [September 30, 2019, 9:51am UTC](https://forums.freertos.org/t/failing-configassert-in-xqueuegivefromisr-and-vportentercritical-on-migration-to-10-0-0-from-7-3-0/7998/9 "2019-09-30T09:51:34Z")
**[adityas](https://sourceforge.net/u/adityas/)** wrote on [Monday, September 30, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/3307221f7f/#070b/271e/f57c): Thanks Richard. I probably made a mistake earlier with the give and take of the semaphore. The main line function needing the semaphore is taking now. Though it does seem the timing of my application is a little different from the mutex method from FreeRTOS 7.3.0, based on the debug messages I am getting. I will be implementing a trace facility to verify this. The other problem I had been having turned out (again) to be a bug in the Atmel ASF driver file.