Hello Everyone,
I'm using the Event Recorder for the first time to analyze the performance of the RTX threads, my purpose is to get an evaluation of the percentage of each thread's execution time.
In my projects where I use FreeRTOS, I have been using the vTaskGetRunTimeStats function to get the thread execution time information.
I've enabled the Event Recorder support in the RTX config file, but probably I misinterpreted the stats generated by the Event Recorder:
System Analyzer tells me (more than once) that my MLXTask is running for a very long time (36ms)
I have checked if there is a configuration error or a design error, but I have not found anything that explains the results I saw in the Event Recorder stats: the Event Recorder timestamp is configured correctly and I have checked the execution time for each thread with GPIO debug pins.
The MLXTask, in fact, runs no later than 300us every 3ms (I use the osDelayUntil function).
The MLXTask is only an example, the Event Recorder stats report me strange result when compared with the real performance.
Do you have any idea why I see this mismatch from Event Recorder stats and real performance?
Thanks for your help,
Flavio
One thing to check is, if the Event Recorder reports "missed events": https://developer.arm.com/documentation/101407/0541/Debugging/Debug-Windows-and-Dialogs/Event-Recorder/Event-Recorder-Window?lang=en. If yes, it can help, and if there is RAM free, to increase the "Number of Records" in the EventRecorderConf.h.
Thanks Andreas Barth for you suggestion,
I tried to run the event record section again as reported in my previous post, and you're right, I have a huge number of missed events.
In accordance with the help page link to me, I have:
Since I am only interested in the computation time of each task, so I've enabled only the events regarding the Thread Component, in order to catch every Thread Switch event.
The results are now a lot more reasonable:
Now the time report is more reasonable, although it seems way too optimistic to me.
By enabling only the thread components, could I "miss" a few events that impact on an estimated thread time ?
Thanks again,
For monitoring the thread active time, the thread create and thread switched events should be sufficient. If you enable also other events for e. g. thread flags, then the System Analyzer can e.g. also indicate blocking reason, when waiting for a flag.
If unsure about the timing, you might also want to check this article: developer.arm.com/.../