Tracing of FreeRTOS Tasks Execution

[ManCla]

Hi Bitcraze team!

I am interested in tracing the execution of the different FreeRTOS tasks that run on the Crazyflie. By tracing I mean that I'd like to retrieve a timed trace of which task is executing. I see that there has been some work on this in the past, what I found is:

• https://www.bitcraze.io/2013/03/debugging-enhancement/
• https://forum.bitcraze.io/viewtopic.php?p=2282&hilit=task+trace#p2282
• https://www.bitcraze.io/2012/04/some-progress-on-the-software-side/

especially the last one seems rather close to what I am after. However all of those links are very outdated, they all come from 2012-2013.
I also see some commented code that seems to have served this purpose in the past, but, looking at its blame history, it also seems to be about 10 years old.

The FreeRTOS macro traceTASK_SWITCHED_IN() is exactly what I would like to use. My idea is to log a timestamp of a precise timer (of the order of microseconds, therefore much faster than the FreeRTOS tick) together with a task identifier. I was thinking of logging to the USDdeck in order to minimize the overhead and interference that could be caused by remote communication.

Is there something like this still functional for the Crazyflie?

Cheers,
Claudio

[evoggy]

Hi!

This sounds interesting! There's a micro-second timer available that you could use for this if you would like to test it out. I'm not sure if the throughput will be enough to log each task switch, but it's worth a try and it would be nice to have these statistics. One thing to note though, is that although a task is switched in, a significant amount of time can be spent servicing interrupts and this will not be seen.

I've been interested in this lately as well and I've been doing some testing using external hardware. Since the amount of data being generated by the system is pretty large when it's running, I've been using a Saleae logical analyzer together with SWO to capture task switches as well as interrupts running. I've made a few code changes (instrumenting the code for ISRs) and a plugin for the Saleae to decode the data coming out. Note that this is far from done and might not be what you wanted, but let me know if you're interested and I'll happily share my code.

Here's a screenshot of the proof-of-concept I made. It shows a packet being received via syslink. The bars on H2 is each byte being received and the last one that's a bit longer is the actual queuing of the data of the syslink packet which triggers the taskswtich to the syslink task.