CCS: Hal timer versus Clock

Robert Wolfe

Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

Hello,

I'm confused about the hal timer, versus the clock module. I've attached two pictures from the sys-bios ROV, one showing the Timer configuration, and the Clock configuration. Couple questions:

1) why is the period of the hal timer 24000. My cpu osc is 336,000,000. That would give a tick rate of 71.4 uS?

2) Both the hal and clock timers are ID 0. Is that right?

3) I've set the clock period to 1000. That is 1 ms?

4) Is there anyway to get the hal timer and clock handles, so I can make calls querying their values

5) when I make a call to xdc_runtime_Timestamp_get32(), is it using the clock or hal timer. And are the counts from that call of ( 1 / 336,000,000) in increments?

6) do I really need to use the clock, when the hal timer is already there?

Here are my .cfg settings. I don't know if they are right for what I'm after, but was just trying things out

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

Clock.timerId = 0;
Clock.swiPriority = 5;
Clock.tickPeriod = 1000;
Clock.tickSource = Clock.TickSource_TIMER;

Thanks,

Robert

over 7 years ago

0 ToddMullanix over 7 years ago

TI__Guru* 96960 points

Hi Robert,

What device are you using?

Todd

0 Robert Wolfe over 7 years ago in reply to ToddMullanix

Mastermind 7860 points

Hi. C6746

0 ToddMullanix over 7 years ago in reply to Robert Wolfe

TI__Guru* 96960 points

Thanks. Someone is going to answer the thread. In the meantime, I'm going to move it to the processors forum. This is just a book keeping action so we can track things better.

Todd

0 judahvang over 7 years ago

TI__Mastermind 32475 points

1. BIOS assumes some default CPU rate for your device based on some TI EVM board. If your running at a different frequency you need to let BIOS know that your CPU is running at 336 Mhz.
Do the following in your .cfg file:

BIOS.cpuFreq = 336000000;

2. Clock uses Timer as its source. What you picture above is not the "Hal" Timer. Its the actual Timer on your device and its being use to drive clock.

3. Yes, 1000 for the clock period means 1 ms.

4. You did not create an instance of Clock so there is no handle to get. You configured just the module properties. There are Clock module functions that you can call. See the SYSBIOS cdoc documentation for a list of APIs you can call. The particular Timer instance you see was internally created so you cannot get the handle to that Timer instance.

5. Timestamp uses a different timer/counter for the C66 devices. It does not use Clock or Timer and it does run at the CPU frequency speed. So yes the granularity would by based upon your cpu frequency.

6. Again, Clock and Timer are not the same. Clock is driver by the Timer. If there is timing in your code then yes, you need Clock. For examples, Task_sleep() needs Clock to know how long to sleep before waking up.

0 Robert Wolfe over 7 years ago in reply to judahvang

Mastermind 7860 points

judahvang said:
1. BIOS assumes some default CPU rate for your device based on some TI EVM board. If your running at a different frequency you need to let BIOS know that your CPU is running at 336 Mhz.
Do the following in your .cfg file:

BIOS.cpuFreq = 336000000;

The statement above generated a compile error

js: "one.cfg", line 225: XDC runtime error: ti.sysbios.BIOS/cpuFreq: incompatible assignment: 3.36E8
"./package/cfg/one_pe674.cfg", line 188

However, I had this in my .cfg file

BIOS.cpuFreq.hi = 0;

BIOS.cpuFreq.lo = 336000000;

which may have the same effect? In that case, the 24000 period for the hal timer remains unexplained.

judahvang said:

4. You did not create an instance of Clock so there is no handle to get. You configured just the module properties. There are Clock module functions that you can call. See the SYSBIOS cdoc documentation for a list of APIs you can call. The particular Timer instance you see was internally created so you cannot get the handle to that Timer instance.

Even though I didn't create an instance, there is a Clock active on my system (based off Timer 0)? It is always there, regardless whether I create an instance of Clock? Or do I need to create an instance, for there to be a Clock?

judahvang said:

5. Timestamp uses a different timer/counter for the C66 devices. It does not use Clock or Timer and it does run at the CPU frequency speed. So yes the granularity would by based upon your cpu frequency.

Is it one of the standard Timers, i.e. 0, 1 or 2? Or I don't need to be concerned about that? (using a Timer already consumed by the Timestamp functionality).

judahvang said:

6. Again, Clock and Timer are not the same. Clock is driver by the Timer. If there is timing in your code then yes, you need Clock. For examples, Task_sleep() needs Clock to know how long to sleep before waking up.

I need it, per use of things like Task_sleep(). But back to my question above ... do I need to create an Clock instance, for it to be there?

Thanks,

Robert

0 judahvang over 7 years ago in reply to Robert Wolfe

TI__Mastermind 32475 points

That is correct, BIOS has clock enabled by default. You can disable it but most systems running an RTOS need timing.

Is it one of the standard Timers, i.e. 0, 1 or 2? Or I don't need to be concerned about that? (using a Timer already consumed by the Timestamp functionality).

On The C6x, the timestamp is a special counter dedicated just for this purpose. It isn't one of the general purpose timers 0, 1, 2, etc...

You do not need to create a Clock instance for the Clock to be enabled.

Been trying to figure out the 24000 period for the Timer (This is a 10 year old chip so had to find some old docs).
I think I finally understand it but its very possible it is not correct for your setup.
The frequency for Timer 0 and 1 are not tied to your CPU frequency for these devices. They are tied to the AUXCLK.
The AUXCLK is derived from the OSCIN which is the frequency of the crystal oscillator (internal or external depending on CLKMODE bit in PLLCTL).
BIOS is setting this to a default value of 24Mhz (probably because there was a device with this as the default) that's why you see the 24000 in the period for the Timer.

If you know what your OSCIN value is, you can hack a BIOS file to make it right for your device.

In your BIOS installation, edit: packages/ti/sysbios/timers/timer64/Timer.xs
Search for a device called "DA850"
Modify the intFreq.lo field

0 Robert Wolfe over 7 years ago in reply to judahvang

Mastermind 7860 points

judahvang said:

On The C6x, the timestamp is a special counter dedicated just for this purpose. It isn't one of the general purpose timers 0, 1, 2, etc...

That runs counter to my experience with DSP-BIOS. There you had to indicate which timer is used for the OS clock, as shown in the pic below. Has SYS-BIOS somehow changed that?

judahvang said:

Been trying to figure out the 24000 period for the Timer (This is a 10 year old chip so had to find some old docs).
I think I finally understand it but its very possible it is not correct for your setup.
The frequency for Timer 0 and 1 are not tied to your CPU frequency for these devices. They are tied to the AUXCLK.
The AUXCLK is derived from the OSCIN which is the frequency of the crystal oscillator (internal or external depending on CLKMODE bit in PLLCTL).
BIOS is setting this to a default value of 24Mhz (probably because there was a device with this as the default) that's why you see the 24000 in the period for the Timer.

If you know what your OSCIN value is, you can hack a BIOS file to make it right for your device.

In your BIOS installation, edit: packages/ti/sysbios/timers/timer64/Timer.xs
Search for a device called "DA850"
Modify the intFreq.lo field

Thanks for that info. Here's a thread showing an alternative method in the .cfg file, to do same thing. Guy initiating the thread, though, wasn't real happy that information is not apparent to the user, who might be using a different OSC than the default 24 Mhz, as am I (16 Mhz). I can see why, since it took a while for me to discover that as well. And that thread was 5 years ago ;)

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

Timer.intFreqs[Timer_Id].lo = 1600000;
Timer.intFreqs[Timer_Id].hi = 0;

Robert

0 judahvang over 7 years ago in reply to Robert Wolfe

TI__Mastermind 32475 points

Robert,

I should have said C64x+ and later devices. Early C62 and C64 devices did not have this.

Yes, that's a better way to modify the same field.

Judah

0 Robert Wolfe over 7 years ago in reply to judahvang

Mastermind 7860 points

judahvang said:
Robert,

I should have said C64x+ and later devices. Early C62 and C64 devices did not have this.

Ok, thanks for the update.

So in that case, do I need to create a timer or clock instance, to drive that BIOS clock? I am doing everything via my .cfg file (not XGCONF), so any discussion of what's needed would be appreciated.

Right now, I'm not creating any instances of clock or timers in that .cfg file. I'm also getting exceptions/crash when running the code, and I'm wondering if the two are related.

Robert

0 judahvang over 7 years ago in reply to Robert Wolfe

TI__Mastermind 32475 points

Robert,

By default the BIOS clock manager should be enabled which creates a Timer to drive the clock. You shouldn't need to create a Clock Instance or Timer Instance for timing to be enabled in your system.

FYI: Timestamp is driven off a time-stamp counter on the chip. You always get this regardless of the Clock Manager being enabled and/or Timer instance being created. In older C62/C64 parts, timestamp was driven off the same timer used to drive Clock....This is not the case for c64x+ parts which is what you have.

Judah

0 Robert Wolfe over 7 years ago in reply to judahvang

Mastermind 7860 points

judahvang said:
Robert,

By default the BIOS clock manager should be enabled which creates a Timer to drive the clock. You shouldn't need to create a Clock Instance or Timer Instance for timing to be enabled in your system.

Great, is there any way I can confirm that is the case?

So, my understanding is that:

1) the C6746 still needs a timer to drive the clock, but SYS-BIOS does it automatically. DSP-BIOS did not, per the picture I send previously.

2) the C6746 is one of the newer c64x+ parts (even though 10 years old!, as you indicated), that has a timestamp driven off a counter on the chip. And that has been the case, even when I had previously been using DSP-BIOS.

Can you please confirm those two statements to be correct?

Robert

0 judahvang over 7 years ago in reply to Robert Wolfe

TI__Mastermind 32475 points

The ROV view that you posted earlier in this thread confirmed it for me. Your Clock Manager was enabled and a created a Timer (see the Timer handle field) which matches the Timer instance.

1. DSP-BIOS did not have a "Timer" module but internally the CLK module programmed up a Timer and hooked it to an HWI interrupt. We allowed you some basic Timer configuration via the CLK Manager properties. This is what your picture shows. So DSP-BIOS still automatically creates a default Timer to drive the Clock.

2. Yes, that is correct. I confirmed this looking at the source code.

0 Robert Wolfe over 7 years ago in reply to judahvang

Mastermind 7860 points

Thanks,
Robert

Processors

Processors forum

CCS: Hal timer versus Clock