FreeRTOS runtime stats

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

FreeRTOS runtime stats

Jump to solution
4,419 Views
chrispflieger
Contributor IV

Can anyone tell me exactly what the Task List display is looking for in FreeRTOS? The runtime percentages won't come up - just a warning to enable configGENERATE_RUN_TIME_STATS, which is.

I verified that ulRunTimeCounter is present and incrementing in the each TCB, and ulTaskSwitchedInTime is incrementing.

My systick is 1ms, and my portGET_RUN_TIME_COUNTER_VALUE() is ten times that (100us).

All the other task stats are legit, but I think the Runtime calculation is looking for something it can't find, or something is out of line.

And, it did work before when I had a variable I incremented in an ISR, but since then I moved to using StopWatch() as an interface, it stopped.

portGET_RUN_TIME_COUNTER_VALUE() actually calls StopWatch_Start(). This seems like less overhead (no ISR required)

1 Solution
4,302 Views
ErichStyger
Senior Contributor V

In Addition to that:

check your linker map file if the ulTotalRunTime has not been removed.

The FreeRTOS port I'm using works high high optimization settings too, e.g. has the following added:

pastedImage_1.png

If you are using 'plain vanilla' FreeRTOS such cases might not be covered.

Erich

View solution in original post

7 Replies
4,302 Views
chrispflieger
Contributor IV

I just realized who I'm conversing with. :smileywink:

I'll explain my reasoning for what I did. It seemed more efficient to use the 32 bit timer, with a prescaler to get it at 10kHz. That way I don't need an ISR incrementing a variable that gets read, I can just read the timer counter directly and let it continuously up tick.

And with the LPC code, there's already this functionality in stopwatch.h/.c - you just need to adjust the prescale value in that code.

4,304 Views
ErichStyger
Senior Contributor V

Hi Chris,

:-)

I agree: using that timer in such a way is a smart thing. I'm less concerned about the interrupt overhead as in general collecting runtime statistics adds some overhead too, and if I disable it I can get rid of the timer overhead too. The only thing to be aware of is that after around 5 days the 32bit 10 kHz counter will overflow: this is not handled in FreeRTOS.

Erich

0 Kudos
4,304 Views
chrispflieger
Contributor IV

I wondered if that might be it - ulTotalRunTime  is optimized out. ulTaskSwitchedInTime is there...

Placing: __attribute__((used))    above the declaration solved it!

0 Kudos
4,304 Views
ErichStyger
Senior Contributor V

Hi Chris,

see Tutorial: Using Runtime Statistics with Amazon FreeRTOS V10 | MCU on Eclipse  or FreeRTOS Task Runtime Statistics for NXP i.MX RT1064 | MCU on Eclipse .

Basically you need to setup a timer for the most detailed information. The above describes as well a way to use the tick counter instead.

I hope this helps,

Erich

0 Kudos
4,304 Views
chrispflieger
Contributor IV

I read those about twenty times. It describes the basic setup and portGET_RUN_TIME_COUNTER_VALUE() . I have that working. I can verify that the counters in the TCBs work (ulRunTineCounter).

What I don't know is exactly what variables and what calculations MCUXpresso uses to generate the stats it displays. It has to be looking at specific variables and running some calculations on that. There doesn't seem to be any published information on that.

0 Kudos
4,304 Views
ErichStyger
Senior Contributor V

The view reads that ulRunTimeCounter value in the TCB and displays the percentage of this in the view (making a sum of all task values and then calculates the percentage based on that. Could you post a screenshot of what you see?

I think you might have missed a setting or so.

Or can you use one of the examples I have posted on GitHub referenced in these articles?

Erich

0 Kudos
4,303 Views
ErichStyger
Senior Contributor V

In Addition to that:

check your linker map file if the ulTotalRunTime has not been removed.

The FreeRTOS port I'm using works high high optimization settings too, e.g. has the following added:

pastedImage_1.png

If you are using 'plain vanilla' FreeRTOS such cases might not be covered.

Erich