Hi All,

I did not find or was unable to find this info...

I have an application using several tasks of the same priority using/waiting for Mutexes. I was debugging for hours and then, two or more tasks stopped wainting for something. I am sure it's a deadlock of badly using those Mutexes.
But that's not the main problem.

What is the way to know where in the task, the task is stopped ? and what resource is it waiting for ?
My tasks are quite complex and could have stopped in several points and waiting for different resources (mutexes).

I am using Eclipse, codesourcery and Jlink debugger.. I can't stop and run the program (only one task is running), but I could not figure out by myself where the tasks are stopped.

Thanks for any help!!
Regards,
Sergio Sider

You can get this information from the Eclipse FreeRTOS plug in, which is a free download. Go to http://www.highintegritysystems.com and follow the links to the downloads.

Hi edwards,

I have the plugin, and now I registered my Mutexes in the FreeRTOS registry so I can see them in the "Queue Table" tab.

I found that the plugin shows the mutex name in the "Event Object" column of the task that appears to have gained the Mutex. It looks like a "dedly embrace", but I still do not know where in the program the tasks are waiting.
I suppose it's possible to find this info in the stack of the task or in another place, but did not figured out.

I could, and I probably will, put some debug routines to help me find it, but it would help a lot in the future to know how to go directly to the "offending line" of the task.

Regards,
Sergio.

Something else you can do is provide some trace macros. Take a look at http://www.freertos.org/rtos-trace-macros.html then search through queue.c for the word "trace". You can log when a task takes or gives a semaphore, so when your crash happens you know what the task did last.

The simple approach: Use global variables. There are not that many points where your tasks could be stuck, so looking the value of the global volatile variable of task1tracepoint in a debugger should be informative.

Hi guys,

Thanks for the suggestions. Actually I found the bug that caused the deadly embrace (and it was not a deadly embrace... was a deadly stupidity: the same task was trying to get a Mutex already taken by itself... :-( )

I don't want to sound whinny, but it would be great to have the knowledge to get the "Program Counter" of a blocked task.

Thanks again,
Sergio.

FreeRTOS also supports recursive semaphores, if that would help?

sergioside, you will probably find that the "Program Counter" that the task last suspended at isn't all that useful, as the main thing this will tell you is which api function suspended the task, but not information about where in the task that call was, or which object (Semaphore, etc) it was called on. That would require a much more complicate parsing of the stack, or saving additional information somewhere task specific.

Hi All,

Thanks for your help!

Now, I am convinced that the "program counter" idea is problematic and debugging techniques are the way to go in that case ;-)

Regards,
Sergio.