XQueueSendToFront known issues

znatok wrote on Thursday, February 06, 2014:

I would like to ask if there are any known issues with xQueueSendToFront API call on CortexM3?
If I use xQueueSend insted of xQueueSendToFront everything works fine in my code, otherwise I see symptoms of memory leakage (code flow goes wild and change it’s behavior if I move pieces of code). In my test I send messages to empty Queue so logically there should be no difference between these two functions.
I’m using version 7.4.2. Memory allocation heap4.
Queue death is 16 elements. I send messages with 0 wait time.

rtel wrote on Thursday, February 06, 2014:

I am not aware of any issues, and nobody has ever mentioned anything particular to sending to the front of a queue before. That said, sending to the front is not use that much, so has less exercise. Most of the function is identical though, it is only the short sequence of instructions that actually copies the data to the queue that is different.

Are you able to re-produce the issue in a small program?
Are there any particular pre-conditions that must exist for the issue to arise, for example, for the queue to start empty?

Most Cortex-M issues actually result from misconfiguration of the interrupt priorities. There is lots written on the FreeRTOS.org website about this (start with the "my application does not run what could be wrong FAQ and follow your nose to the Cortex-M specific information). The easiest first step would be to upgrade your FreeRTOS version then ensure configASSERT() is defined because the later versions have addition assert() statements that are placed specifically to catch the most common interrupt priority issues.