Resolution of port GET RUN TIME COUNTER VALUE can cause overflow in run-time stats counters

Kernel
,
#1

We are porting FreeRTOS to our R5F based platform. We see that portGET_RUN_TIME_COUNTER_VALUE returns a 32b and that is accumulated in pxCurrentTCB->ulRunTimeCounter,

further
*pulTotalRunTime = portGET_RUN_TIME_COUNTER_VALUE();

is used to get total time and then report task load numbers as %.

However in modern systems we do tend to switch tasks pretty rapidly so we want to use a high res timer, like 1us or 10us resolution.

But at 32b variables, @ 1us , the variables used by freertos will overflow in ~ 1hr and @ 10us in about 10 hrs and so.

A better solution would have been to define a type for this counters and then let the porting layer or application decide the type as uint32_t or uint64_t

Is my understanding correct this is a limitation in FreeRTOS run-time stats counting ?
Is there is a solution that can be used without modifying the FreeRTOS kernel ?

regards
Kedar

#2

Yes, my understanding is that FreeRTOS is limited to just a 32bit counter for run time states. I agree that it would be nice if this could be configured.

One thing to point out, is that with a slower run time counter, as long as nothing in the system actually can get synchronized to it, by the time you fill much of the counter, the fineness of the counter isn’t as important as you make it out.

If a routine is run for say 10us at a time, a 1us counter will catch 10 counts in it, a 10us counter will count it once per execution, and a 100us second counter will likely catch it one time in 10, so over many invocation, all will indicate about the same amount of time.

Another option is to create an add-on routine with the extenstion capability of tasks.c to add a clear stats function to FreeRTOS so you can build up the stats for a short period of time (so as to not overflow the counter) at the times you want to.

#3

We have had a few requests to add a feature that allows the run time counter value to be reset - would that help in your case or is a long term count required?

Making the type user configurable would be a simple change, we will do that. For now, it may be possible for you to add your own implementation into the code using the traceTASK_SWITCHED_IN macro - see https://www.freertos.org/rtos-trace-macros.html. It may also be possible using the application task tag https://www.freertos.org/xTaskCallApplicationTaskHook.html although the hook macro would be leaner.

[edit - the code that formats the run time counter to human readable ascii may have to be considered more if the type holding the count is configurable]

#4

Thanks for the tips.

Yes, we will look at using the traceTASK_SWITCHED_IN with application task tag.
Yes, we will need to provide our own formatting code but we can base it off vTaskGetRunTimeStats so this should be fine (it does not access kernel structures directly, so we can still be portable to new kernel versions).

The only constraint I see is that we also use FreeRTOS+POSIX in some cases, and that also uses application tags, so we may need tweak the code a bit in FreeRTOS_POSIX_pthread.c

Let me play around a bit and see how it goes.

My main doubt was to confirm if the overflow condition can indeed happen, so thanks for the quick responses and pointers to potential solutions.

regards
Kedar