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.

Measured time deviated from the Clock period on SYS/BIOS

Other Parts Discussed in Thread: OMAPL138, SYSBIOS

Hi,

I am seeing some deviation in the time achieved using SYS/BIOS Clock module.
(SYS/BIOS 6_21_0_21, CCS 4.2, CG Tools 6.1.20, OMAPL138, Blackhawk Emulator)

Following is the code for clock creation.

Clock_Params_init(&clkParams);
clkParams.period = 500;
clkParams.startFlag = TRUE;
clkParams.arg = (UArg)0x5555;
Clock_create(clk0Fxn, 3000, &clkParams, NULL);

In clk0Fxn function, I am toggling a GPIO line and I am probing that on the CRO.
Following are times recorded for different clock periods.

set_period Time_measured_on_CRO
30  27
60  53.3
100  88.8
500  445

I am seeing around 10% deviation to the time set for the clock.
Is this expected?

thanks, Durga

  • Durga,

    I suspect that the timer used by the Clock module is not being clocked at the frequency SYS/BIOS thinks it is.

    By default, SYS/BIOS configures the 1ms timer period based on an assumed 24MHz input clock frequency.

    If the input clock frequency is higher than that (ie 27MHz) then the configured period will yield an actual tick period that is shorter than expected.

    To test this theory, try adding the following to your config script and see if you get better results:

    var Timer = xdc.useModule('ti.sysbios.timers.timer64.Timer');

    Timer.intFreqs[0].lo = 27000000;

    Timer.intFreqs[1].lo = 27000000;

    Timer.intFreqs[2].lo = 27000000;

    Timer.intFreqs[3].lo = 27000000;

    If you know the timer clock frequency precisely, substitute the correct number in the above script code.

    Alan

  • Hi Alan,
    Thank you for the reply. That helped.
    I had to give following with SYS/BIOS 6_21_03_21.
    var Timer = xdc.useModule('ti.sysbios.timers.timer64.Timer');
    Timer.intFreq.lo = 27000000;

    1. I have checked the SYS/BIOS user guide(SPRUEX3F), I see an example to set frequency of the timer. Is there any other documentation?
    2. Do we need to configure frequency for all other peripherals as well? Or is there any way to tell SYS/BIOS to configure its Clock Input frquency (PLL's input)? (I see that we can configure CPU's clock to 300Mhz in .cfg file. But where can we configure PLL?)
    3. When I use System_printf to print the time stamp in a Clock function with period 30msec, I see prints "30 60 90 120" etc., But System_printf itself is taking around 20msec which is not shown in the time stamp. Why it that?

    Please anwser these.

    thanks, Durga

  • Durga,

    The configuration settings I provided were for newer versions of SYS/BIOS (6.32/6.33) that do NOT support the module level Timer frequency setting. Beware of this if/when you upgrade to to a newer SYS/BIOS.

    1) The CDOC associated with your SYS/BIOS release provides additional configuration information:

        http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/6_21_03_21/exports/docs/docs/cdoc/index.html

    2) SYS/BIOS currently does NOT perform ANY PRCM initialization. That function is left to either the host CPU (the ARM) or GEL scripts. When you 'configure' the frequency of the timers, you're simply informing the SYS/BIOS Timer module about the frequency that the timers are being clocked at.

    3) I'm assuming that by "print the time stamp" you mean you are printing the value returned by Clock_getTicks(). The actual printing of the arguments to System_printf() is what takes all the time but the fetching of the current Clock tick occurs before the time consuming part of System_printf(). The invocation of System_print() is preceded by the call to Clock_getTicks() (which takes very little time) so it probably occurs before any subsequent Clock tick interrupts.

    Alan

  • Hi Alan,

    2) If SYS/BIOS does not perform PRCM initialization, then how to configure clock when I want to run SYS/BIOS on both ARM and DSP of OMAPL138. Is there any other way than GEL files.

    3) Check the following code.

        maintask()
        {
            while (1)
            {
                time = Clock_getTicks();
                System_printf("System time in clk0Fxn = %lu\n", (ULong)time);
                Task_Sleep(30);
            }
        }

        Here assuming Clock_getTicks gives 0 for the first time, System_printf prints 0, and then task sleeps for 30msec.
        Now when task wakes up (ie. second time), Clock_getTicks function should include the time taken by System_printf which is around 20msec as well and System_printf should print 50. But I am seeing 30.

    thanks, Durga

  • Durga,

    2) Several function hooks are provided in strategic places during the system climbup sequence for this purpose.

    You can install custom hardware initialization functions:

    • before C runtime initialization
    • before and after RTSC module initialization
    • within the BIOS_start() thread before tasks are started.

    Section 3.1 of the SYS/BIOS User's Guide describes the climbup sequence and the various hooks:

        http://www.ti.com/lit/ug/spruex3j/spruex3j.pdf

    3) Your initial post said you were calling System_print() from within a Clock function. In that case I expected the printed times to be 30, 60, 90 since the Clock function would be called every 30 ticks regardless of how long the function took to execute.

    In your maintask() above, assuming it is executing within a Task thread (which the Task_sleep() function requires), I would expect the printed times to be offset by the time it takes to execute the System_printf() function.

    How are you measuring the time it takes to execute System_printf()? Are you calling Clock_getTicks() before and after the call?

    Alan

  • Hi Alan,

    Even I expected the same, but System_printf gives 30, 60, 90 etc., with Task_delay(30). Time taken by the System_printf is not included.
    I am measuring the time by toggling a GPIO line and probing on the CRO which shows around 50msec period.

    thanks, Durga

  • I'm still not sure how you're measuring the System_printf() time.

    From the code snippet you provided, it appears to me that you are changing the state of an I/O pin after the System_print() call. 

    Are you then measuring the time between transitions of this I/O pin?

    If so, then you are NOT measuring the duration of System_printf(). You are are measuring the time between the returns from System_printf(), which is really the same as measuring the time between calls to your Clock function.

    This leads me to thinking that the timers are STILL not being clocked at the frequency that SYS/BIOS thinks they are being clocked at.

    30 Clock ticks equals 50ms.Which means that SYS/BIOS thinks the clocks are running 66% faster than they actually are. Is that possible?

    Alan

  • Hi Alan,

    That is correct.
    I am measuring the time between IO pin transitions. It gives around 50msec from which I am assuming that System_printf is taking around 20msec.
    I am not measuring the actual time System_printf is taking.

    If I comment System_printf statment and measure the time, I am getting 30msec period. So clocks running at different frquency may not be the problem.

    thanks, Durga

  • Durga,

    I'd be interested in observing the waveform if you toggled the i/o pin before and after the call to System_printf() in maintask().

    Unless the clock tick interrupts are somehow being disabled throughout the call to System_printf() I don't see how the 'time' variable can be 30, 60, 90, etc...

    Alan