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 localuarthandler() 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. ~~~ configASSERT( !( ( pxQueue->uxQueueType == queueQUEUEISMUTEX ) && ( 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().

~~~ configASSERT( ( portNVICINTCTRLREG & portVECTACTIVEMASK ) == 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 …envatmelsrcASFthirdpartyfreertosfreertos-10.0.0SourceportableGCC. The original import was for ‘ARMCM3′, while this should have been ‘ARMCM4F’ (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

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.

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 portSETINTERRUPTMASKFROMISR() / portCLEARINTERRUPTMASKFROMISR().

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.