CCS/CC2650STK: How can I measure the code execution time when I run TI RTOS?

Thank you for your help, I tested these time stamp APIs with task_sleep(1000)function, however, the getFreq API always returned 65536 and the execution time for task_sleep(1000) read 0.01s.
I don't think it's necessary to go into detail about this, so can I just use this result as a reference when I measure other code execution time? Or is there something critical wrong here that I must modify?

Jason,

We default the Clock module to 10us in the .cfg file, so the task_sleep(1000) should be 10ms. Which getFreq API are you using...Timestam_getFreq? Do you have a small example project that you could attach? Also, what version of software are you using?

Todd

I used Timestam_getFreq, I used IAR ARM8.11.2, the below is the sample code:

time1=Timestamp_get32
SA_audioDSP(PCMsamples1,yfil);//measure DSP execution time
time2=Timestamp_get32();
Timestamp_getFreq(&Freq);

Hi, I have a question regarding to 10us in the .cfg file, is this the tick period when it only comes to task_sleep(1000)(which means the task_sleep(1000) runs 100 times faster than it should be), or the whole system clock is no longer 1/48MHZ because u defaulted the tick period in the .cfg file?

Plus, if I use the function Timestamp_get64 in the module xdc.runtime,sometime I got the value 3200171710, I think it's because the value overflow, is it true?

Thank you again for your help

The Clock period has no impact on the CPU freq. It's only used by the kernel for timing (Task_sleep, Semphore_pend. etc.).

A timer wrap can occur with the Timestamp module. We handle the wrap though and 64-bits should l not wrap for a long time. 3200171710 is 0xbebebebe in hex which is the value we initialize system and tasks stacks to (so we can find the peak). A value of 0xbebebebe for a Timestamp_get64 is pretty suspicious! Are there any uninitialized variables?

Todd

Thank you for ur help, I used the xdc time module in the following way(I don't know what u mean by"unutilized value"?):

xdc_runtime_Types_Timestamp64 timer_start;
xdc_runtime_Types_Timestamp64 timer_stop;
Timestamp_get64(&timer_start);
//Do something here
Timestamp_get64(&timer_stop);

Sometimes the timer_stop 3200171710

For both the System and Task stacks, before they are used, the kernel sets all stack memory to 0xbebebebe. This way we can look at the top of the stack to see if it is blown. We also can start at the top of the stack and look until a non-0xbebebebe value. This will be the stack peak displayed in ROV.

Todd