I would like to use vTaskStartTrace in such a way that in the end the result would be sent out to a terminal using uart_0 and saving it as a file using the tracecon.exe to convert this file something like this //———————————————————– // Variable for debug #define BUFFER_SIZE ( ( unsigned portSHORT ) 512 ) static signed portCHAR pcWriteBuffer1[BUFFER_SIZE]={0}; // some were in the code vTaskStartTrace(  pcWriteBuffer1, BUFFER_SIZE);    . . . // end trace ulTaskEndTrace(); // write to terminal    for (i=1;i<=BUFFER_SIZE;i++)      print_dbg_char( pcWriteBuffer1[i]); //———————————————————– then pointing the terminal to transfer it to file and using tracecon over this file using HyperTerminal and trying any print_dbg function (print_dbg_char, print_dbg_ulong, print_dbg_hex) the tracecon.exe didn’t work for me (got zero size file) any suggestions regards

I have been tring some more staff using it like that know for (i=0;i<BUFFER_SIZE;i=i+4) { //print_dbg("0x"); // create number as seen in memory window of avr32studio print_dbg_hex( (pcWriteBuffer1[i]<<(6*4))+(pcWriteBuffer1[i+1]<<(4*4))+(pcWriteBuffer1[i+2]<<(2*4))+ ( (unsigned portCHAR) pcWriteBuffer1[i+3])); print_dbg("rn"); }         in avr32studio I can see the memory of pcWriteBuffer1 ( &pcWriteBuffer1 = 0xbd4) 0x00000bd4 : 0xBD4 <Hex>   Address   0 – 3     4 – 7     8 – B     C – F                 00000BC0  00000000  00000000  00000000  00000000            00000BD0  00000081  00001388  00000001  00001389            00000BE0  00000003  0000138D  00000000  0000138D            00000BF0  00000001  0000138D  00000003  00001392            00000C00  00000000  00001392  00000001  00001392            00000C10  00000003  00001397  00000000  00001397            00000C20  00000001  00001397  00000003  0000139C            00000C30  00000000  0000139C  00000001  0000139C            00000C40  00000003  000013A1  00000000  000013A1            00000C50  00000001  000013A1  00000003  000013A6   which is indenticl to the file from the terminal named Trace.hex (but is writen as txt)  00001388 00000001 00001389 00000003 0000138D 00000000 0000138D 00000001 0000138D 00000003 00001392 00000000 00001392 00000001 00001392 00000003 00001397 00000000 00001397 00000001 00001397 00000003 0000139C 00000000 0000139C 00000001 0000139C 00000003 000013A1 00000000 000013A1 00000001 000013A1 00000003 000013A6   then using hex2bin over this text file (named Trace.hex) giving back zero size file (Trace.bin) this made me think that hex2bin is not reading txt files with hex numbers but something else can some one help?  

The data should be tick count followed by task number, so the data looks like it could be real.  However, when I open a trace buffer I see the data the other way around, little endian format.  Maybe the bytes are being transmit in the wrong order?  When looking at pure binary data I would expect it to look more like. Your data | Expected data 00001388  | 88130000 00000001  | 01000000 00001389  | 89130000 00000003  | 03000000 0000138D  | 8D130000 00000000  | 00000000 0000138D  | 8D130000 00000001  | 01000000 Etc. Regards.

sorry I didn’t understand your response - does it mean I am getting the right trace data - tick count of the RTOS program I am using is 5000 ( 5 tick/msec).   so the trace result dosen’t look right, for example task 1 is running 0x1388 = 5000 tick   which is one sec, but the task is schedualed for every msec.   in my case I also have a counter in the task which show me that this task is runnig each msec then each sec. - still I don’t know way the hex2bin give me back 0 size file is some one used vTaskStartTrace with terminal? Regards

let me see if I got it right (as it not writeen anywere) 0x00001388 = 5000 00000001 0x 00001389 = 5001 00000003 0x 0000138D = 5005 00000000 0x 0000138D = 5005 00000001 0x 0000138D = 5005 00000003 0x 00001392 = 5100 00000000 task 1 started at tick 5000 until tick 5001 task 3 started at tick 5001 until tick 5005 task 0 started at tick 5005 until tick 5005 task 1 started at tick 5005 until tick 5005 task 1 started at tick 5005 until tick 5010 task 0 started at tick 5010 until tick … tell me if I got it right for my program it is 5000 tick per second 1) the tick are absolute tick count and not delta tick count. 2) if so how come task (1,0) took zero tick to run (5005 to 5005), shouldn’t it be at least one tick. 3) if those are the numbers field in the pcWriteBuffer1 way one need the hex2bin.exe and tracecon.exe to get the   data. 4) can it be I got wrong pcWriteBuffer1 5) I changed the portCHAR pcWriteBuffer1 to the right hex numbers using this code (shifting places)    // create number as seen in memory window of avr32studio    print_dbg_hex( (pcWriteBuffer1[i]<<(6*4))+(pcWriteBuffer1[i+1]<<(4*4))+(pcWriteBuffer1[i+2]<<(2*4))+                 ( (unsigned portCHAR) pcWriteBuffer1[i+3]));    as you can see the pcWriteBuffer1[i+3] is converted to unsigned as it is the only number with FFFF    the rest are already positive    how come? should it be like that? regards   

2) if so how come task (1,0) took zero tick to run (5005 to 5005), shouldn’t it be at least one tick. If a running task blocks on a semaphore or queue, it can run for less than a tick before another task executes.

The timing used by default is the tick count, so any context switches that occur with a higher frequency than that do not have accurate timing information – although the order of execution shown is correct.  When I use the utility I change the behaviour to use a high resolution free running timer, but the timer used depends on the processor on which it is running so this is not portable and cannot therefore be the default behaviour. Regards.