The problem in a nutshell: My queue tells me there are no items, but the read/write pointers, as well as a debug counter tell me the buffer has 1-2 items left. Furthermore, looking at the raw uart traffic, it appears that some sort of corruption is possibly occuring with uxMessagesWaiting.
I am currently implementing a UART buffer using a freeRTOS queue. The bytes are received in an interrupt, and pushed to the back of the queue
if ( xQueueSendToBackFromISR(m_UartQueue,(void *)&InByte,
&pxHigherPriorityTaskWoken) == pdTRUE )
where InByte is a uint8_t.
They are being popped off the queue in another thread.
xQueueReceive(mUartQueue, (void *)Byte, UARTRECEIVEWAITTIME);
where byte is a uint8_t pointer.
I am finding by creating my own debug counter to compare to uxMessagesWaiting that the value differs from what my debug counters say. Within the interrupt the uxMessagesWaiting is often reporting 1 less than what I would expect.
I have verified that the interrupt priority of the interrupt is appropriately set relative to configmaxsyscallinterrupt_priority.
Baud rate is 38400, the buffer size is 256. 39 byte packets are being received.
I am out of ideas. Any advice is appreciated.
First - unless the bytes are arriving very slowing (for example, characters typed into a command console), then a queue is a very inefficient way of passing data out of an ISR. It would be better to use a DMA, or circular buffer and a direct to task communication to unblock a task when the buffer contains a complete message (http://www.freertos.org/vTaskNotifyGiveFromISR.html)
Which chip are you using? Do you have stack overflow detection turned on, and configASSERT() defined?
Thanks for the response. I am using the SAM4SD32C. I do have stack overflow detection turned on. I also have configassert defined. I will look into the alternative function you mentioned.