xQueueReceive – cannot empty queue

Hi guys, We encountered a strange behavior of xQueueReceive function, it goes as follows:
  1. We created a Queue using xQueueCreate function.
  2. We created a task using xTaskCreate function, this task is waiting on the queue with xTickToWait=portMAX_DELAY which means it’s blocking without timeout till a message is inserted to the queue.
  3. The problem is that from time to time when our device comes back from reset, the queue message counter is showing 1 although there are already 2 messages in the queue (the last message and the one before it). This creates a sort of continuous 1 message delay (instead of picking msg[N] we always pick up msg[N-1]).
  4. We’ve tried several workarounds:
* We used xQueueReset in order to “re-start” the queue, with no help – the message counter goes to 0, but the queue still had the previous message inside it. * We called xQueueReceive() with xTickToWait=0 in order to empty the queue but that did not help either. It seems like the queue message counter is somehow missing the “1’st time message”, not incrementing itself and this cannot be cleaned until reset. Any idea will be appreciated. Thanks in advance!

xQueueReceive – cannot empty queue

When you say:
when our device comes back from reset
do you mean it works the first time, but not after a reset. I so, is this a hard or soft reset, and is the C start up code correctly clearing the .bss segment when the system comes out of reset?

xQueueReceive – cannot empty queue

Hi, Reset = soft reset Also, please note that it is does not happen after every reset, it is quite random. Once it happens it remains until next reset, if it is OK – it will remain OK at least until the next reset.

xQueueReceive – cannot empty queue

From your description it sounds like the soft resets are not functioning as you expect them to. At a guess I would say your C start up code is not clearing RAM as you expect after a soft reset. I would guess that the problem never occurs after a hard reset – if that is the case then I’m not sure this is actually a FreeRTOS issue.