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.