Hello, 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. Thanks, Gary

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.