xQueueReceive - cannot empty queue

Kernel
1

motico123 wrote on Thursday, June 09, 2016:

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!

2

rtel wrote on Thursday, June 09, 2016:

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?

3

motico123 wrote on Thursday, June 09, 2016:

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.

4

rtel wrote on Friday, June 10, 2016:

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.