• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 435 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

STS_delta() retrieving bogus information

armando3047
Intellectual 470 points


Hi all,

I'm using an OMAP3630 and the DSP/BIOS version 5.33.04, I'm trying to get the time that an very symple funtion takes to be exectuted, this function only performs a couple of sums and two comparations, to sum up, looking at the assembly code in this function only a couple of ADD and CMPLTU assembly instructions are performed. This make me thing that the function will take very few millisecons, even nanoseconds, but I get surprised that the STS viewer reports an average of 500 ms and a maximum value of 18 seconds!! how is this possible if the execution of the program only takes 2 seconds??

Below are the steps I followed to configure my STS object:

1. TCONF configuration:

 var dmmCheckTimingStats = prog.module("STS").create("dmmCheckTimingStats");
 dmmCheckTimingStats.comment = "DMM Check API timing statistics";
 dmmCheckTimingStats.unitType = "Low resolution time based";

2. C source file:

cregister volatile unsigned int TSCL;

extern STS_Obj dmmCheckTimingStats;

STS_set(&dmmCheckTimingStats, TSCL);
myfunction ( data1, data2);
STS_delta(&dmmCheckTimingStats, TSCL);

Why Im getting so high times?

Do you have any clue what Im doing wrong?

Thanks and best regards,

Armando

 

 

  • 0
    TI__Guru*** 125430 points

    I was looking at the definitions of STS_set and STS_delta.  It looks like they are defined such that the second argument is an integer (signed).  I wonder if that's creating the issue.  When it rolls over you would end up with a small number minus a very large negative number resulting in a huge positive number (18 seconds?).

    Try this alternate implementation:

    cregister volatile unsigned int TSCL;

    unsigned int start, stop;

    extern STS_Obj dmmCheckTimingStats;

    start = TSCL;
    myfunction ( data1, data2);
    stop = TSCL; 
    STS_add(&dmmCheckTimingStats, stop-start);

    Also, keep in mind that if an interrupt occurs during the processing of myfunction then the ISR execution time will be factored into the reported time.  I agree that 18 seconds seems a bit of stretch!  :)

  • 0 in reply to Brad Griffis
    Intellectual 470 points

    Hi Brad,

    Thanks for looking at this.

    I was thinking about that, please see the below calculations:

    The TSCL is 32 bits wide, and on my environment the freq is 430MHz.
     
    (2^32)/430,000,000 is about 10 seconds of time before it wraps around. As long as the time between any pair is not longer than this time the difference will be correct even if it wraps back to 0. Thus if the program only takes 2 seconds to run to comlpetion we have enough time before the timer wraps around.
    Will the STS_add() act in the same way that the STS_delta(), I mean will i meassure time my function takes by calling the STS_add?
    Great thanks!
    Armando
  • 0 in reply to armando3047
    TI__Guru*** 125430 points

    If you look at the description of STS_delta you'll see that it simply subtracts the value that was specified during STS_set() and then it calls STS_add().  So you've been doing an STS_add "under the hood" the whole time.  My proposal takes the subtraction out of STS_delta and puts it into the app.  That way we can do an unsigned subtraction.  This is such an easy change -- please try it and let us know how it goes.  If it solves the issue perhaps I'll propose a couple new APIs, e.g. STS_setu() and STS_deltau() that use unsigned integers.