Trace Hook Macros Issue

tekkkon wrote on Tuesday, March 08, 2011:

Hi all,

I read the tutorial for Trace Hook Macros and got a couple of questions.

In the example 2, how does the “reasonBLOCKING_ON_QUEUE_READ” defined? And how does the “log_event()” function logging the task execution? Is there any specific example in the Demo that logging task execution sequences, task timing, kernel events? 

I ported it to CORTEX_LM3Sxxxx Rowley, and suspect one of my task stopped working and the RTOS is locking up for some reason. So I’m trying to figure it out by API call logging. Thank you in advance!

/* traceBLOCKING_ON_QUEUE_RECEIVE() is just one of the macros that can be used to record why
a context switch is about to occur. */
#define traceBLOCKING_ON_QUEUE_RECEIVE(pxQueue)     \
    ulSwitchReason = reasonBLOCKING_ON_QUEUE_READ;

/* log_event() is an application defined function that logs which tasks ran when, and why. */
#define traceTASK_SWITCHED_OUT()                    \
    log_event( pxCurrentTCB, ulSwitchReason );

rtel wrote on Tuesday, March 08, 2011:

I think you are referring to the page about trace hook macros on the web site?  Three of the five FreeRTOS tutorial books have already been updated to include a section on using the trace macros, with quite a comprehensive example included too (another book has also been updated, but the example not yet ported).

how does the “reasonBLOCKING_ON_QUEUE_READ” defined

reasonBLOCKING_ON_QUEUE_READ is supposed to be just a unique constant that indicates that the context switch that is about to occur is occurring because the current task blocked on a queue read.  In a real application, it would just be a number, nothing else.  It is a hypothetical example so the definition of reasonBLOCKING_ON_QUEUE_READ is not given.

And how does the “log_event()” function logging the task execution?

Again, its a hypothetical example, so log_event() is not doing anything.  It is up to the application to decide how you want to log an event.  It could be write to a RAM disk for example, but ideally it would be to communicate with a kernel aware debugger.  The Cortex-M3 can output trace information in real time in a non intrusive manner, so if that was how the trace was output, log_event() would simply be a macro that wrote to the trace port.