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.

Clock issues with Sysbios on A15

Other Parts Discussed in Thread: SYSBIOS

Hi there.

I have been trying to run Sysbios on one of the A15's in my DRA7XX evm board. I have looked at the following forum posts for reference:

http://e2e.ti.com/support/embedded/bios/f/355/p/290067/1012089.aspx#1012089

http://e2e.ti.com/support/embedded/bios/f/355/t/301033.aspx

Everything seems to work fine except for the clock and timer modules. I have a task pending on a semaphore which is posted from a clock function, but it seems the clock runs at a rate much faster than what I specify (the semaphore always overflows). When I look at the clock module from the ROV window, it seems the ticks increment by some arbitrary number between clock function calls and they keep incrementing even when the target is halted.

What am I missing here?

Thanks,

Raphael

0755.A15_Sysbios_Clock.zip

  • Which version of SYS/BIOS and XDCTools are you using?  

    By default the Clock module should increment every 1ms.  Can you use ROV and run the target for 10 seconds?   Look at the Clock module in ROV and you should see the increment of 10,000 after 10 seconds.

    You might also try using TI Resource Explorer and build one of the product examples.  We have a Clock example.  Does that work?

  • Sorry, I should have specified the versions. I am running Sysbios 6.37.0.20 along with XDCTools 3.25.4.88.

    I tried importing the following project from the resource explorer: sys/bios->arm->omap3->omap3630->gnu target examples->clock example. Then during the import, on the platform selection dialog, I change the target from gnu.targets.arm.A8F to gnu.targets.arm.A15F so I can select the correct platform file for my evm (ti.platforms.evmDRA7XX). I set a hardware breakpoint inside each clock function where it reads the clock ticks into a variable so I can see the values on the variables window. It seems like the ticks increase even when the target is halted, i.e. the ticks values are bigger if I step slower and smaller if I step faster.

    When I run the same example on one of the board's DSPs (sys/bios->c6000->DRA7xx->-DRA7xx>generic examples->clock example), the ticks only increase when the program is running and the values are always the same in every run (regardless of whether I step through slowly or don't set breakpoints at all).

  • Hi Raphael,

    The default A15 Timer delegate uses the A15 Generic Timer. Generic Timer does not stop ticking when the A15 core is halted.

    If you would like the timer to halt when you halt the A15 core to help with debug then you can use the DM Timer delegate. In order to change the default timer delegate you can add the below code to your app's *.cfg file:

    var Timer = xdc.useModule('ti.sysbios.hal.Timer');
    Timer.TimerProxy = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');

    Since the clock internally uses the hal timer APIs to create a timer, once you change the hal timer delegate, the clock module will start using the DM Timers instead of Generic Timers.

    Raphael said:

    Everything seems to work fine except for the clock and timer modules. I have a task pending on a semaphore which is posted from a clock function, but it seems the clock runs at a rate much faster than what I specify (the semaphore always overflows).

    By "Semaphore always overflows" do you mean that the Semaphore is posted multiple times and the semaphore count variable overflows ? Also, another thing to check is that what frequency is the A15 on your board actually running at and does it match the BIOS.cpuFreq that SYS/BIOS uses ? You can check the CPU frequency that SYS/BIOS is using through the ROV->BIOS->Module view.

    Best,

    Ashish

  • Using the DM Timer delegate did the trick. My guess is when I halted for debugging the timer would keep on ticking and the clock function would get queued up to run many times and I misinterpreted that as the clock running too fast.

    Anyways, I am not having any issues stepping through code now and everything seems to be working.

    Thanks everyone for the help.

    Raphael

  • Yes, that is true. When the A15 core is halted, the Generic Timer ticks accumulate and when the core is run again, the timer interrupts (for all pending ticks) are serviced back to back which has the effect of calling the clock function multiple times.

    Glad to know everything works well with the DM Timer delegate.

    Best,

    Ashish