vTaskGetRunTimeStats returning odd values

I managed to get FreeRTOS working properly on a 2148 (I’m still banging my head with the interrupts on the 2478, sigh), and have set up a task to retrieve the activity stats (great new feature by the way!).  I’m getting some weird results, though: Stats        31902        3953 IDLE        4294930780    5317615 LEDs        5146        637 As you can see I only have two tasks running.  According to this page (/fr-content-src/uploads/2019/07/index.html?http://www.freertos.org/a00021.html), I was expecting activity values in %, and clearly that third column is way out of wack.  Do I need to be dividng that third column by total ticks, or something similar, to get a %? It may also be that I haven’t configured the timer properly as well.  This is the code I’m using is as follows, based on an example on the website, but there is one register I wasn’t sure about (see comments below): // Run Time Statistics (declared in FreeRTOSConfig.h) #include <lpc214x.h> #include "FreeRTOS.h" #include "task.h" #include "stats/stats.h" int statsHits = 0; void statsSetupRunTimeStats( void ) {     // ToDo: Fix this … it isn’t working at present     const unsigned long TCR_COUNT_RESET = 2, CTCR_CTM_TIMER = 0x00, TCR_COUNT_ENABLE = 0x01;     /* Power up and feed the timer with a clock. */     SCB_PCONP |= SCB_PCONP_PCTIM1;     // ??? (this register doesn’t exist on the 2148 … equivalent?     // SCB_PCLKSEL0 = (SCB_PCLKSEL0 & (~(0x3<<2))) | (0x01 << 2);     // ???     /* Reset Timer 0 */     T1_TCR = TCR_COUNT_RESET;     /* Just count up. */     T1_CTCR = CTCR_CTM_TIMER;     /* Prescale to a frequency that is good enough to get a decent resolution,     but not too fast so as to overflow all the time. */     T1_PR =  ( configCPU_CLOCK_HZ / 10000UL ) – 1UL;     /* Start the counter. */     T1_TCR = TCR_COUNT_ENABLE; } void statsEnable (void) {   // ToDo } void statsDisable (void) {   // ToDo } // LED Task Handler portTASK_FUNCTION (vStatsTask, pvParameters __attribute__ ((unused))) {   statsSetupRunTimeStats();   char statsBuffer[100];   const portTickType xStatsDelay = 500 / portTICK_RATE_MS;   for (;;)   {     vTaskGetRunTimeStats(statsBuffer);     debug_printf(statsBuffer);     statsHits++;     vTaskDelay(xStatsDelay);   } }

vTaskGetRunTimeStats returning odd values

This is a better page to view http://www.freertos.org/rtos-run-time-stats.html Is statsBuffer big enough? Is the stack of the task big enough to hold a 100 byte buffer (do you have stack overflow checking turned on?)? The register that is missing is providing either the power or the clock to the timer peripheral. Your timer must be running otherwise everything would be 0.

vTaskGetRunTimeStats returning odd values

The buffers and stack are big enough.  I was just looking through the source code for "prvGenerateRunTimeStatsForTasksInList" (tasks.c), and it should indeed be generating percentages … I’m not really sure what’s up: The three output possibilities are: - sprintf( pcStatsString, ( portCHAR * ) "%stt0tt0%%rn", pxNextTCB->pcTaskName ); - sprintf( pcStatsString, ( portCHAR * ) "%stt%utt%u%%rn", pxNextTCB->pcTaskName, ( unsigned int ) pxNextTCB->ulRunTimeCounter, ( unsigned int ) ulStatsAsPercentage ); - sprintf( pcStatsString, ( portCHAR * ) "%stt%utt<1%%rn", pxNextTCB->pcTaskName, ( unsigned int ) pxNextTCB->ulRunTimeCounter ); I’m kind of scratching my head at the output I’m getting versus what the sprintf should be spitting out (they all contain the "%" character, for example). Kevin.

vTaskGetRunTimeStats returning odd values

First I would check that the timer is incrementing at the rate you expect by simply reading the timer values into an array, maybe from within the tick interrupt.  For example you could have a tick hook function that does something like: static long lIndex = 0; static unsigned long ulTimerValues[ 500 ] = { 0 }; void vApplicationTickHook( void ) { ____if( lIndex < 500 ) ____{ ________ulTimerValues[ lIndex++ ] = portGET_RUN_TIME_COUNTER_VALUE(); ____} } configUSE_TICK_HOOK and configGENERATE_RUN_TIME_STATS would both have to be set to 1. Second I would look at the sprintf() implementation.  Many that come with embedded compilers can be cut down to the bone and may not support the format specifiers you are using. Regards.