SYSBIOS: SYSBIOS Default Clock Tick Source

Hi,

This issue is belongs to sys-bios package, So we will check with sys-bios team and get back to you.

Thanks & Regards

Gaviraju

Enver,

I'm not sure why the SDK recommends configuring the Clock module to use TickSource_USER.

By default, TickSource_TIMER is used and the Clock timer delegate is the ti.sysbios.timers.dmtimer.Timer module.

As far as I know the default configuration should work.

What behavior are you seeing when you use the default configuration?

Alan

With the default configuration the tick for Clock module are always zero. This is observed in ROV view in CCS and also shown in my application by calling Task_sleep(1) which never returns.

There are no Clock or Timer specific changes in the .cfg file besides these lines:

var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
var Clock = xdc.useModule("ti.sysbios.knl.Clock");
Timer.checkFrequency = false;

//Enver

Enver,

I assume you've disabled Timer.checkFrequency because an error is raised when checkFrequency is enabled.

The error indicates that there is a mismatch between what the software is being told the timer frequency is and what the timer frequency actually is.

The checkFrequency feature was added because this mismatch occurred quite often. Specifically, the timer is thought to be clocked at a very high frequency (ie 20mbps) while actually being clocked at 32KHz. The result of this mismatch is that an extremely large period is set in the timer (ie ~20,000 for a 1ms tick) but because the timer is actually clocked at 32KHz, the timeout takes a very long time to expire. So long that it appears that Task_sleep() never returns.

You must resolve this mismatch and set the timer frequency accordingly.

The actual frequency of the clock driving the timer can be set as below:

    Timer.intFreq.lo = 32768;  /* for instance if the frequency is actually 32,768Hz */

Alan

Hi Alan,

Well that setting lingered on since we basically used SDK examples. I Just tried to remove that settings which means that we have only two lines left:

var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
var Clock = xdc.useModule("ti.sysbios.knl.Clock");

And in application I use: Task_sleep(1); . The behavior is the same, the application will not go further than Task_sleep(1) and the ROV view says "No

data to display" in Clock and Timer modules.

//Enver

Try configuring the Clock module to explicitly use the same timer as it uses in the example .cfg file.

I believe that is Timer #6.

This can be done by setting:

    Clock.timerId = 6;

You will probably have to enable selection of that timer by adding the following also:

 var TimerSupport = xdc.useModule('ti.sysbios.family.shared.vayu.TimerSupport');
 TimerSupport.availMask = 0x00C0;

Alan

I just tried you suggestion with the clock id and timer support value, the behavior is the same as before. About the mask 0x00C0 from what I can see in the TimerSupport doc bios_6_46_06_00/docs/cdoc/ti/sysbios/family/shared/vayu/TimerSupport.html the mask you suggested is for ARP32. Therefor I also tried mask 0x0030 which should be DSP timer 5 and 6.

Would it be possible for you to replicate this issue I'm seeing on your end? I mean could you put together a small sysbios example with one task for example?

//Enver

We run weekly BIOS regressions on the TDA3xxx board.

We use no special configuration for the Clock and Timer modules and all of our tests run correctly.

Timer 1 is being used for all these tests as that is the default configuration.

I suspect that your application puts the C66 core into a low power mode when Task_sleep() is called.

And in this lower power mode, I suspect that the Timer overflow interrupt won't wake the C66 core unless the ovf_wup_ena bit is set in the 'twer'.

To test this hypothesis, locate and make a back up copy of the ti/sysbios/timers/dmtimer/Timer.xs file in your BIOS installation.

Then change this code:

obj.twer = (params.twer.mat_wup_ena << 0) |
   (params.twer.ovf_wup_ena << 1) |
   (params.twer.tcar_wup_ena << 2);

to this:

obj.twer = (params.twer.mat_wup_ena << 0) |
   (params.tier.ovf_it_ena << 1) |
   (params.twer.tcar_wup_ena << 2);

Then rebuild your application using the default Clock settings.

This change will always enable the ovf_wup_ena bit when the corresponding ovf_it_ena bit is set in the 'tier'.

Alan

I see!

I found a mistake on my end, Clock.TickSource_NULL was used in the configuration. That is now eliminated.

I tried with the suggested changes. It seems the application does not reach main, because of the default setting 'Timer.checkFrequency = true;'

The application is stuck in file Timer.c and function Timer_getCount(Timer_Object *obj) and no error is raised.

The cpu frequency is set to 750 000 000 Hz using the Bios module and the actual cpu frequency is set with the help of GEL files.

//Enver

Envar,

Please share your GEL files and your .cfg file.

I'm suspecting that your GEL files are not configuring the clock source to Timer 1 in the same way our GEL files are or that the PRCM configuration is being performed at runtime AFTER the checkFrequency function is invoked.

If the timer clock sources are being configured at runtime to 19.2Mhz (which is what our Timer module code assumes), you might try disabling the checkFrequency feature again just to see if the fix I proposed in my previous email has any effect.

If the clock source to Timer 1 is not being configured either by GEL code or at runtime, you should try using the "Clock.timerId = 6" setting in the configuration as I think that is the timer your example wants to use to drive the Clock. Presumably something is configuring the clock source to that timer.

Alan

GEL files used are the ones which comes with CCS 9.3.0.00012. We do modify two of them according to TDA3 RVP board instrunctions, I will share these two.

Right now we are relining on GEL files to set up the Sysbios clock and Core clock.

With you suggested changes in Timer.xs and checkFrequnecy set to false we do reach the application but still stuck in Task_sleep(1). It looks like the Clock module is set up to use GPTimer1, take a look in the shared .png files.

I suppose you meant GPTimer6 which has id 5 right? I added these two line in the .cfg:
_TimerSupport.availMask = 0x0030;
_Clock.timerId = 5;

I got a bit of different behavior where we reach main, and we do reach Task_sleep(1) totally three times. On the third time the application is stuck in Idle run.

//Enver

Shared_Files.zip

Are any of the cores halted while you're running the DSP core?

I'm wondering about the 'emufree' bit in the Timer's tiocpCfg register.

By default this is cleared which means that if any cores are halted, the timer will also halt.

Alan

That's good news!

Does it still work without the modification to Timer.xs I suggested?

Alan

Yes it does!

Thanks for your help!

//Enver