wrong use of #defines in xQUEUE type, v9.0.0

~~~ In queue.c, typedef struct QueueDefinition #if ( configUSETRACEFACILITY == 1 ) UBaseTypet uxQueueNumber; uint8t ucQueueType; //<– Line 162 #endif } xQUEUE; In xQueueGenericReceive(), line 1279 #if ( configUSEMUTEXES == 1 ) { if( pxQueue->uxQueueType == queueQUEUEIS_MUTEX ) { In my FreeRTOSConfig.h:

define configUSE_MUTEXES ( 1 )

define configUSETRACEFACILITY ( 0 )

~~~ I’m not sure how this even compiles, but it does with GNU ARM 4.9.3. The result is that illegal memory is written with unpredictable consequences. cheers Knut

wrong use of #defines in xQUEUE type, v9.0.0

Please have a look at the large comment around line 97, and these defines : ~~~

define pxMutexHolder pcTail

define uxQueueType pcHead

~~~ In case a queue object is in fact a mutex, the two fields are not used in their normal way (head, tail). These are pointers, not characters. uxQueueType will be set to NULL (queueQUEUE_IS_MUTEX). It may look a bit confusing, but it is entirely local to tasks.c. I’m sure it was done to save a few bytes of RAM. In another C project a union could be used for this, but union‘s are not supported by all compilers that are used to compile the FreeRTOS kernel. The member used when tracing: ucQueueType is indeed an 8-bit field that holds a copy of ‘ucQueueType’ that was used during creation. In short: there is nothing wrong with it.

wrong use of #defines in xQUEUE type, v9.0.0

but it is entirely local to tasks.c
Sorry, not task.c but queue.c of course. Cheers.

wrong use of #defines in xQUEUE type, v9.0.0

wow. Missed that. Thanks. The good news is that FreeRTOS works, the bad news is that something else is messing up my stack…