i have stats like this:
USBRX-T429491617015069881%
IDLE429496209515070042%
CONVERT700324%
REFRESH44681156%
Tmr Svc866030%
SCANKEY314311%
MINIPRN73<1%
PRINTER67<1%
START686224%
KEYBOAR1436850%
POWEROF3<1%
MESSAGE3<1%

What i am doing wrong if i have functions and macro defined as below:

//in main.c
void vConfigureTimerForRunTimeStats( void )
{
PR4=0;// set period (doesnt matter cause i am using prescaller to get TMR4 as counter
TMR4=0;//clear timer register
T4CONSET=BIT_6|BIT_5|BIT_4;//timer prescaler 256, 10000000/256=39kHz
T4CONSET =BIT_15;//enable Timer
}

//in FreeRTOSconfig.h


#define configGENERATE_RUN_TIME_STATS1
//void vConfigureTimerForRunTimeStats( void );
#define portCONFIGURE_TIMER_FOR_RUN_TIME_STATS() vConfigureTimerForRunTimeStats()
#define portGET_RUN_TIME_COUNTER_VALUE() TMR4

That's all, buffer is sent through usb to pc, and results are from terminal...

I would guess, and it is a guess, that somehow two consecutive time readings show the time going backwards rather than forwards. Is it possible that a time reading occurs before the run time counter has been initialised? Can you put a break point in the function that calculated/returns the run time counter value to see what values are being returned the first few times it is called?

It might be easier even to buffer the first few returned values. You could create a temporary array of say 50 places, then the first 50 times the function that calculates/returns the time value is called have it also write the value into the next array slot. Then pause the program and view what was written to the array.

Regards.

time readings are made by FreeRTOS, initialization is made by FreeRTOS, I dont know if timer is read before initialization:)
But i think i have the answer: TMR4 is 16 bit long... i must check what FreeRTOS expect it to be... and if it expect to be 32 bit long, there is an option to set it to 16 bit?

If i could set FreeRTOS counter to 16 bit long, then i won't have to use interrupt to create my timer counter instead using TMR4 with prescaler.

One technique with 16 bit timers is to configure the timer to generate an interrupt at a high frequency (10K Hz?), then have the ISR just increment a 32 bit variable. The 32 bit variable is then your run time stats base.

This is not a particularly efficient method because of the high interrupt overhead. If you really know the PIC32, you could use the fast interrupt shadow registers to minimise the effect (don't ask me about that though! I've never used them myself).

Regards.

Thanx, now with prescaler i have 39kHz timer with 1kHz task rate. I think that 16 bit timer at 39kHz is good enough to do its job. There is no problem to make interupt and increment timer by 1 every tick.... by what for??? if i could force FreeRTOS to use stats with 16 bit long counters.... but how??? If such change is not worth the time then i will write interrupt :( but if you could tell me if it is possible i would be honoured :) thanx

one notice to freertos examples about stats:
you cannot declare 'extern' in FreeRTOSconfig.h because that header is included in assembler file (ISR_Support.h) in PIC32 port

This is normally easy to work around. For example, the IAR demos use the code below in FreeRTOSConfig.h

#ifdef __ICCARM__
#include 
extern uint32_t SystemCoreClock;
#endif

Ok, now is all working as it should (had to use interrupt to get 32 bit long counter):

USBRX-T1108<1%
IDLE77095891%
Tmr Svc1453<1%
CONVERT1530<1%
REFRESH486435%
SCANKEY86571%
POWEROF1<1%
MESSAGE2<1%
MINIPRN71<1%
PRINTER67<1%
KEYBOAR4166<1%
START2940<1%

What's the order of tasks in stats report? from the last active to the earliest?

Look at the definition of vTaskList() in FreeRTOS\Source\tasks.c.