FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [April 2015 Threads]
Hi tasker,
as the change started in FREERTOS, I start here as well.
Problem:
In queue.c there is a new (compared to 8.2.0) assert in:
BaseTypet xQueueGiveFromISR( QueueHandlet xQueue, BaseType_t * const pxHigherPriorityTaskWoken )
*...
*/ Normally a mutex would not be given from an interrupt, and doing so is
* definitely wrong if there is a mutex holder as priority inheritance makes no
* sense for an interrupts, only tasks. */
*configASSERT( !( ( pxQueue->uxQueueType == queueQUEUEISMUTEX ) && ( pxQueue->pxMutexHolder != NULL ) ) );
*...
unfortunately, Atmels ASF "freertosspimaster.c" (3.21.0) uses this and the assertion fails:
static void localspihandler(const portBASETYPE spiindex)
*...
*/ If the driver is supporting multi-threading, then return the access mutex. */
* if (txdmacontrol[spiindex].peripheralaccessmutex != NULL) {
* xSemaphoreGiveFromISR(
* txdmacontrol[spiindex].peripheralaccessmutex,
* &higherprioritytask_woken);
* }
*...
I used "freertosspimaster.c" and FR 8.2.0 w/o any problems (having HIGH SPI volume) so: what is the danger here if I would deactivate the assertion (of course in a first step!); I will ask the Atmel team as well in parallel (or is s/o from Atmel listening here?)
Best and thanks, Stephan
Hmm. Are you using the version of FreeRTOS that came with the ASF?
Some changes were made to the mutexes to allow the priority inheritance to work better when more than one mutex was held. Also a new function was introduced specifically for giving semaphores in interrupts (for better performance). Probably the ASF code needs to be updated. I can talk with Atmel about this. In the mean time I would suggest updating the driver to use a binary semaphore created with xSemaphoreCreateBinary() rather than a mutex created with xSemaphoreCreateMutex().
Regards.
Are you using the version of FreeRTOS that came with the ASF?
nope; the FreeRTOS Version that comes with ASF 3.21.0 is "8.0.1"...
I can talk with Atmel about this.
That would be really nice!
Thanks and good night, Stephan
Richard, I appear to be having this issue as well with ASF 3.26.0 and FreeRTOS 8.2.2 except in the TWI service for FreeRTOS, I haven't tried with the SPI version yet. Are you aware of any resolution regarding this? For the time being it appears the FreeRTOS services in ASFwill not work with any FreeRTOS version newer than 8.1.2.
PS - also experiencing this with ASF 3.20.1
I think the only way around this is to update the code so it uses a binary semaphore instead of mutex.
Do you have any specific recommendation on how to best accomplish this with the ASF examples?
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.