CLK_gethtime() not incrementing when stopped in debugger

Hi John,

Are you using the legacy support package in SYS/BIOS ? Why I ask is because CLK_gethtime() is a DSP/BIOS API. Also, do you see that the clock never increments or it only stops incrementing when the core is halted ?

Best,
Ashish

The Clock does increment and I can observe it rolling over periodically after 32 bits of CPU ticks go by. If I read the clock twice in a row and stop after both reading I see <100 ticks go by. If I stop on the first read in the debugger and wait a while before reading the clock again, the same number of ticks has elapsed. What is the recommended time/tscl api to use? I also use the tscl function directly and saw the same behavior.

It does look like our RTSC/XDC setup is using "TI-RTOS for C6000, 2.0.1.23" vs the "SYS/BIOS 6.33.6.50" product (I inherited this project from other developers). Is TI-RTOS the same things as DSP/BIOS? Would you recommend we switch over to the SYS/BIOS from TI-RTOS?

Hi John,

TSCL counts CPU cycles and is therefore expected to stop counting when the core is halted.

If you need the timestamp to keep incrementing while the core is halted, you can try using Timer64 based Timestamp provider. In order to use Timer64 based Timestamp provider, you will need to make it the support proxy for Timestamping and also change its emulation mode so it does not stop running when the core is halted (by default, we configure the timer to halt on an emulation suspend event).

Here's some example config code you can add to your application's *.cfg file to select Timer64 based Timestamp provider:

*.cfg

var Timestamp = xdc.useModule("xdc.runtime.Timestamp");
Timestamp.SupportProxy = xdc.useModule("ti.sysbios.timers.timer64.TimestampProvider");

And here's *.c and *.cfg code to change the emulation mode for Timer64:

*.cfg:

var Timer64Timestamp = xdc.useModule("ti.sysbios.timers.timer64.TimestampProvider");
Timer64Timestamp.timerId = <Timer Id>; // If you select Timer Id 1 for example, the timer base address is 0x2210000 in changeTimer64EmuMode.

// See Timer mapping table for mapping between timerIds and their base addresses

// get handle to xdc Startup module
var Startup = xdc.useModule('xdc.runtime.Startup');

// install a "last function"
var len = Startup.lastFxns.length
Startup.lastFxns.length++;
Startup.lastFxns[len] = '&changeTimer64EmuMode';

*.c:

void changeTimer64EmuMode()
{

    // See Timer mapping table for mapping between timer Ids and base addresses
    volatile uint32_t *emumgt_clkspd = (uint32_t *)(TimerN_BaseAddress + 0x4);
    *emumgt_clkspd = 0x1;
}

Best,

Ashish

Thank you for the info, this seems to have had the desired effect. I do have a follow on question now that I am using the timer64 module. I have included some snippets from our app.cfg file for reference.

After adding the timer64 stuff to our app.cfg has changed the behavior of our tick to wall time conversion functions. Does using the timer64 package require modification to the conversion from CPU ticks(CLK_gethtime)  to wall clock time? For an example, two subsequent CLK_gethtime return the following values

2335040856 - 2126706857 = 208333999 * (1/1250e6) = 0.1666671922 seconds instead of the 1 second we are expecting. Using an external clock source that we trust I can confirm that the actual clock is running at about 1 second (actually 0.931885 seconds). The discrepency between 1 sec vs 0.9318 is a separate issue that we are still investigating). My HW engineer has already verified that the DSP Clock is running at 1250MHz so we are not questioning our PLL setup at this point.

var Clock             = xdc.useModule('ti.sysbios.knl.Clock');

var Timestamp         = xdc.useModule('xdc.runtime.Timestamp');
Timestamp.SupportProxy = xdc.useModule('ti.sysbios.timers.timer64.TimestampProvider');
var Timer64Timestamp = xdc.useModule('ti.sysbios.timers.timer64.TimestampProvider');

Timer64Timestamp.timerId = 14; // attempting to use timerId 0 results in a "Timer0 is already in use or reserved (check availMask/availMaskHigh)" build error.

BIOS.cpuFreq.lo = 1250000000;

Clock.tickPeriod = 1000;

var clock2Params = new Clock.Params();
clock2Params.instance.name = "readTimeClock";
clock2Params.period = 1000;
clock2Params.startFlag = true;
Program.global.readTimeClock = Clock.create("&readTimePeriodicCallBack", 10, clock2Params);

Apologies - Quick bump of this post since it fell down to the 7th page on the forum today due to an unusually high volume of other posts.

Hi John,

Timer64 runs at a frequency of (CPU Freq / 6). If the DSP PLL clock is running at 1250 MHz then the Timer clock will run at 208.33MHz frequency. At that timer frequency the math works out.

2335040856 - 2126706857 = 208333999 * (1 / 208.33MHz) = 1sec

Best,
Ashish