STM32 - Find out why queue is running full w/o FreeRTOS+ Trace?

dueringa wrote on Tuesday, April 15, 2014:

Hi there,

I’m using a STM32F103ZG, Keil µVision (4.21) as Development Environment. The FreeRTOS version I’m using is 8.0.0.
I have a project consisting of multiple tasks (about 20). My problem is, the queue of one task (responsible for triggering ADC measurements and taking the values) is running full. I think this might be either a timing or priority problem.
The queue size is 20 elements, Tick frequency is set to 100. Every 50ms, two elements are written to the queue to trigger the measurements.

I defined some assert functions for traceQUEUE_SEND_FAILED and traceQUEUE_SEND_FROM_ISR_FAILED which consist of
__breakpoint(0) followed by a while() loop so I actually notice that.

My main question here is: Is there a possibility to find out why this is happening without the use of FreeRTOS+ Trace?
What’s driving me crazy: As soon as I include FreeRTOS+ Trace in my build to find out which other task might be responsible for this (by needing too much runtime, having a wrong priority, etc) - the problem is gone! It just doesn’t occur anymore.
I’m pretty much confused about this right now. I have an additinoal build configuration for including the Recorder Library from Perceptio. Only thing it does additionally is setting queue/semaphore names, and also calls to vTraceStoreISRBegin and vTraceStoreISREnd inside ISRs.

So, is there achance for me to find out why this is happening? I don’t see a way now.
Increasing the queue size surely won’t help, it will only delay the problem.

Thanks in advance!

rtel wrote on Tuesday, April 15, 2014:

Does the queue become full because the task that is supposed to be draining the queue stalled somehow (maybe in an infinite loop, or blocked on an event that does not happen, etc.)?

Trace would be the easiest way, but I note that is not helping in this case as it seems to cure the problem. The fact it cures the problem could be a queue however as with the trace code built in the execution times will be slightly longer as the trace code is running in addition to the application code.

Unfortunately the plug-ins for the Keil IDE got abandoned as every new release of uVision broke the previous plug-in - however you can still manually collect run time stats and view the results in the debugger or write the results out to a serial port. That would give you a very rough indication of which tasks were using the most CPU time, if nothing else. Other than that trail and error with making adjustments to priorities and the like is all I can suggest.


dueringa wrote on Tuesday, April 15, 2014:


thanks for your reply.
In the meantime, the problem also occurred in the Trace Recorder build.

The problem was:
The task which is responsible for writing in the queue got stuck in a long-running calculation (which is done inside a loop, using ambient conditions - various combinations of ambient conditions results in different runtimes of the calculation). In the meantime, a timer ISR wrote a lot of messages in the task’s queue.
After the calculation finished, the task wrote all “Trigger ADC measurement” messages to the ADC queue which it received from the timer ISR.

Those were about 20 messages, which entirely filled the queue.

The solution now was to further limit the number of iterations in the loop and also raising the size of items for the ADC queue.

With best regards,