SYSBIOS and Timers for the OMAPL138

Bruce,

Which version of SYSBIOS are you using?

For Timers on OMAPL138, there is a upper 32-bit half and lower 32-bit half.  So its possible to have Linux/BIOS share a timer with each using a different half.  Having said that, it does make it a bit trickey because if you do that then you need a coordinated effort for releasing the timer from reset.

For #1, you can change the Clock.timerId.  This will change the default timer used by BIOS

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

     Clock.timerId = 2;    // this changes the default Timer used by BIOS to 2.

For #2, See the BIOS timer cdoc documentation in your BIOS installation for details  but I'll try to explain what I know.

In the ti.sysbios.timers.timer64.Timer module there is a module wide configuration parameter intFreqs[].  This parameter is an array of the lenght of the number of timers.  You can set this if your frequency is different from the default frequency.

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

    Timer.intFreqs[2].lo = 24000000;    // Setting Timer to 24 Mhz.

    Timer.intFreqs[2].hi = 0;

Judah

Judah,

Thanks for your suggestions.  This looks pretty straightforward.  I am currently using CCSv5.03 and SYSBIOS 6.31.04.27, but I plan to migrate fairly soon to CCSv5.1 with SYSBIOS 6.32.03.43.

Right now, I have a DSP project that was migrated from DSP/BIOS.  I have not converted any of my legacy API calls yet.  Will the method you described above work correctly for the legacy APIs like CLK_getltime, CLK_countspms, etc?  I can provide you with my existing bios.cfg file if that will help.

The code above should work even with your legacy APIs.

Judah

Judah,

On further testing with my target board, here is what I see.  I put these statements in my bois.cfg file:

var Clock = xdc.useModule('ti.sysbios.knl.Clock');
Clock.timerId = 2;    // this changes the default Timer used by BIOS to 2.

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

Timer.intFreqs[2].lo = 149500000;    // Setting Timer to 149.5 Mhz.

Timer.intFreqs[2].hi = 0;

Then in my application code, I checked CLK_countspms:

Ticks = CLK_countspms();

The value for Ticks is 299000.  I tried changing the Timer.intFreqs[2].lo = 50000000 to effect a change, but Ticks remained 299000.  Interestingly, this is the CPU frequency in kHz, or CPU cycles per ms.

Is there something I am missing?

Bruce,

Some of the CLK APIs are based on Timestamp and others are based on the configured Timer.  In BIOS 6.x we have separated the APIs into two different module namely Clock and Timestamp.  In BIOS 5.x it was all under CLK.

I believe on all C64+ devices the Timestamp counter runs at the CPU frequency.  This is not affected by the Timer frequency.

CLK_countspms() - is based upon the Timestamp counter that's why you see the CPU frequency.

Judah

After my last post, I was looking at the source that implements CLK, and I came to the same conclusion.  However, this raises a new question:  None of the hardware timers in the OMAPL138 run at the CPU frequency. This makes me wonder where Timestamp gets its reference clock frequency for the OMAPL138 implementation.  If you know where to direct me to look in the documentation, I would appreciate it.  I will keep looking also.

I think I found the answer -- There is a special Time-stamp counter in the C674x DSP in the OMAPL138.  It is a free-running counter the runs at the CPU frequency.  I'm pretty sure that this is what Timestamp is using.  Let me know if this is correct.