xQueueReceive not receiving but xQueueSend returning true

bradgoold wrote on Sunday, July 12, 2015:

Hi, this is one of the first times that I have posted to a forum for support, so go easy :-).
I have a task that sends a struct pointer to a queue using xQueueSend(). The task that receives the this message doesnt get it. The microcontroller I am using is an STM32F103VE.
I debugged with GDB and followed the task that sends through until xQueueSend returns pdPass. The receiving task never receives this message. I set the block time on receive to the maximum to no avail. With a breakpoint set at the receiving line, I can prove that the task is running and waiting for a message on it’s queue. When defining the queue, I check that the return value is not NULL as recommended. So, the queue is created, and is legit, but receives nothing when a message is sent.
My application has quite a bit of IPC, but this one task wont receive. I have checked the queue handle names etc also.

My code is on github at https://github.com/vjval1974/Brew-Machine-MkIV (WebInterface branch) and the queue in question is “xBrewTaskHLTQueue” which doesnt receive on hlt.c line 127. I know my code isnt elegant (to say the least), but I am working on that.

I would love to know any reason why a task can send a message to a queue and the receiver not receive.

Thanks in advance


rtel wrote on Monday, July 13, 2015:

What does your consoleprint() function do? Is it using semihosting? If so that can mess things up - or at least make the code run very slowly. Also, is it using any form of mutual exclusion (such as a mutex) as it seems to be called from several tasks.

Normal questions first: Do you have configASSERT() defined, and have you called NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 ) - which is only necessary on STM32 parts?

I’m afraid I have not studied your code in any detail, but as you are not using Blocking calls (your timeouts are set to 0 - although I note you tried having a timeout as well) then I’m wondering if the task is just being starved out by a higher priority task that is also not blocking. Does the function actually run all the other code, so its definitely executing, it just that it is not receiving from the queue? Or is it just not doing anything.

Which IDE are you using, if any? If you are using IAR or Eclipse then you can register the offending queue, then use the StateViewer plug in to view how many items are in the queue. If the queue is empty, is it possible another task is ready from the wrong queue by mistake? You can also view the queue in the debugger to see how many items are in the queue, and then with a bit of twiddling that I can help you with, how many tasks are waiting for the data. If the queue does not display in the debugger without a cast then try casting it to an xQUEUE* - so in the watch (or expressions) window you would add “(xQUEUE *) xBrewTaskHLTQueue”.

Sorry - a bit of a rambling answer, hopefully something there helps.


bradgoold wrote on Tuesday, July 14, 2015:

Hi Real Time Engineers,

I will try to answer your queries as best as I can:

vConsolePrint just places the string on a queue in a task that uses printf to print back to the console. It causes the strings to be printed in full without being switched out by a context switch mid line if printf is called from the calling task.

configASSERT() is not defined.
NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 ) is being called in the hardware setup in main.c

As far as blocking calls go, I am blocking on most of my receive calls are blocking (sometimes only 10ms). Yes, the function runs all of the code. I stepped through this with GDB (debugger).

I am using Eclipse Juno. I havent heard of the StateViewer plugin, but I will look into that.
Last night I checked the queue with GDB using the (xQUEUE) cast. I found that there was something weird (in my novice eyes). When printing the address of the queue inside xSendToBack() ie with ‘print pxQueue’ the address matches the address when the receiving task calls xQueueReceive. But the contents were different. That is, when using ‘print (xQUEUE)xBrewTaskHLTQueue’, the sending task has the number of items on the queue variable set at one, but the receiving task (pointing to the same variable) has 0 items on the queue.

One thing to note is that the code in the master branch is working, and the code in the WebInterface branch fails. The first thought comes to mind “so whats different between the branches”, but it is quite unrelated code. I added a few files to do with the web interface and added one member to the GenericMessage struct. Pointers to this struct are used by the offending queue.

I will try to gather more details and screenshots later tonight.

Thank you so much for your help.


PS I have the config CheckForStackOverflow set to 2. I also have a mallocfailed hook defined. The hook functions don’t get called during runtime. Can there still be a memory issue or something writing over that memory area? How can I catch this?

davedoors wrote on Tuesday, July 14, 2015:

Defining configASSERT() is easy and really helpful. It might take you right to the issue. I will let Richard reply to the rest.

rtel wrote on Tuesday, July 14, 2015:

You description sounds quite odd, and like you are looking at two different queues. Is the value of the handle the same inside the queue send and queue receive functions? If you inspect the queue from inside queue send function, and it shows the queue as holding an item, and then inspect the same queue inside the queue receive function (assuming the value of the handle is the same) then you are inspecting exactly the same memory so it must also show the queue holding one item. Unless, of course, something else has removed the item from the queue in the mean time.

This is where FreeRTOS+Trace will really help, as that allows you to trace items (view items) going through the queue from sender to receiver.


bradgoold wrote on Tuesday, July 14, 2015:

Hi Guys, thanks for your responses! I have found the problem and learnt a lot in the mean time. I had copy/pasted the queue handle to another task that was receiving. As Real Time Engineers stated “something else has removed the item from the queue”, it had done!
I will be looking at FreeRTOS+Trace after this exercise!
Once again, thanks for your help and guidance!