I'm having one of those days where I'm missing the blinding obvious..
Using FreeRTOS V5.3.0, IAR 5.41.2, JLink, AT91SAM7S256
We have lots of comms on a singe SPI port. I thought it sensible to convert my (old and working I hope) binary
semaphore to a (new and improved) mutex.
I have a global declaration..
static xSemaphoreHandle semaphore_spi_guard;
Simple.. change the line where it is initialised..
semaphore_spi_guard = xSemaphoreCreateMutex(
As described in
#define configUSE_MUTEXES 1 in FreeRTOSConfig.h
is all present and correct.
The help says..
"Mutexes created using this macro can be accessed using the xSemaphoreTake() and xSemaphoreGive() macros"
Great.. I need not alter any of my code because this is the way I give and take my (old) binary SPI semaphore.
Reality was different..
I was disappointed to find every give or take of the mutex fails.. time to start investigating..
I put breakpoints in a few different locations..
This is when started to really scratch my head and get confused..
xQueueHandle xQueueCreateMutex( void
The following values are end up as follows:
pxNewQueue->pcWriteTo = NULL;
pxNewQueue->pcReadFrom = NULL;
.. OK, so unlike a queue, we don’t set these to the 'head' of a queue.. So far so good.
Then every time we come to give or take the mutex I arrive at xQueueGenericSend or xQueueGenericReceive.
The very first few lines perform a check that always fails - and I cant work out why it does the check and how it can pass..
This check is..
if (!pxQueue || !pxQueue->pcHead) // extended check for valid Queue
Well of course it fails with
I get back to my give / take mutex having don’t nothing and returning a fail..
Please help.. I’m very confused!
I don't think there has ever been an error code errQUEUE_UNDEF, so can only assume that you are not using an official version of FreeRTOS, or that somebody at your end has added this code. Try comparing your queue.c to one from the official release - although your version is not up to date you can still download all the previous versions from SourceForge.
That is indeed correct, and as I suspected, obvious. Thankyou.