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.

Sys/Bios' Clock Not Running

Expert 2430 points
Other Parts Discussed in Thread: SYSBIOS

I don't actually expect anyone will be able to help, but I figure it doesn't hurt to ask while I continue investigating.

OS:         Sys/Bios v.6.42.3.45

Processor:  C6455

So I just recently discovered that my application, which has been in the field now for seven years, doesn't have a internal clock (timer tick) running!  It used to, but I suspect it stopped working when I upgraded from BIOS5 to Sys/Bios 6.  (I never noticed because I never actually timeout on anything.)


What's odd is I can't figure out why.  Other than ensuring that the device speed is set correctly in the platform configuration (or just initializing directly BIOS' configuration), no actual user setup is actually required.  So it's not like I'm setting it incorrectly:  it's setup by the kernel itself.  For my other applications, the Sys/Bios handles setting up its internal clock just fine.  Even on this device, I can create a "Hello World" app, and the clock is running just fine:  semaphores timeout as they should, Clock_getTick() properly returns increasing values each time it's called, etc.

But on this application, nada, even though the Sys/Bios initialization code and configuration file is identical (as far as clocks and timers are concerned meaning NEITHER have any specific initialization code related to the clock).  I looked at the clock, timer, and SWI modules in ROV (at run-time) for both this and my working "Hello World" app, and everything is identical.

Shot in the dark, I know, but anyone have clue where else I might look for issues?  Maybe the timer's interrupt is being disabled?  But shouldn't BIOS handle re-enabling it in or after BIOS_start() when it's configuring the timer? Tomorrow I guess I'll try implementing a custom clock and call Clock_tick() manually, but I'm still puzzled why I need to do that.

 

  • Can you share both .cfg files (Hello World's, and your application's)?
    BIOS automatically enables the timer interrupt associated with the Clock module. Is it possible that your application code is inadvertently disabling the Timer's interrupt within the IER? Using the CCS debugger, you can see the IER register content to confirm whether the timer interrupt is enabled.
    Where is the code that enables the clocks to the timers? Is that being done explicitly by your application, or is that being done by GEL code within CCS?
    When you say that in the Hello World example the Clock module runs correctly, is that only being run from within the context of the CCS debugger?

    Alan
  • No, unfortunately, I can't share the file.  The S/W as a whole is classified, and it is illegal for me to bring anything out of the SCIF other than the final encrypted binary I use to flash the systems.

    It wouldn't be of any value to you, though.  As I stated, no configuration is being performed on the clocks or timers.

    The "Hello World" one you can get just by creating a new CCS project and use TI's sample Sys/Bios template.  That's all I did.

    I can, but I'm not running this through the debugger.  GEL files do not apply.  (Even so, my GEL file doesn't configure much of anything, either.  It expects the bootloader to have already handled all that.)

    Anyway, as I stated in my original message, I was already going to check the interrupts today.  Any other suggestions?  Doing some more offline research, I'm still somewhat baffled by this.

  • As an update, if I use a custom clock and create my own timer (1 ms period and Clock_tick() as its callback), everything works: tick count increases, semaphores timeout, sleep calls wake up, etc.

    Before I implemented the above, I did track down the source of the problem: Bios is not setting up the H/W timer at all. All the timer control registers were zeroed out. It creates the framework (callbacks, SWI handlers, etc.), but it just doesn't bother to actually initialize the timer itself.

    Since I can create a working H/W timer myself, I am not sure why BIOS seems to be having a problem.

    Well, at least I have a workaround until I solve this puzzle.
  • When you say you "create my own timer", are you using one of the BIOS provided Timer modules or are you "rolling your own" timer code?

    Alan
  • Yeah, I should have been more clear.  Sorry.  I meant that I'm just using Sys/Bios' Create_timer() function to create the new timer, hence why I am perplexed why it can create and initialize it fine when I do it that way manually but seems not to be able to it automatically (as it should).

    The only parameter I set is the period.  For the timer ID, I used Timer_ANY.  And for the callback, I passed it a pointer to Clock_tick() as opposed to writing my wrapper function.  That's it.

  • I installed BIOS 6.42.03.35, imported this Clock example:

    Then I built and ran it successfully on my dsk6455 evaluation board. This example automatically (as one would expect) creates and starts a Timer instance for use by the Clock module.


    Are you able to import and run this example on your board as well?

    Alan

  • Well, I don't have that DSK branch available in my install, but like I stated originally, I created another sample one (the UIA stair step one, I think), and it worked fine. I even tried the simple "Typical" Sys/Bios one, and it worked fine, too. Also, for several other independent projects for different products, I have no issues. (Of course, I suppose on those I am technically using different versions of Sys/Bios, XCDTools, etc. and different variants of this DSP: C6474 and C6674.)


    There's just something special about this one particular application. It's very curious, too, because it's very non-peripheral oriented, and the only H/W interrupts I'm using are 5 & 6 (for DMA) and 13 (for a GPIO line). No Ethernet, no SRIO. Nothing that can be causing a conflict. *shrug*


    I tweaked my new SysBios_ClkCfg() function to allow me to specify either timer 0 or timer 1 (the only two available on this device), and both work fine.  Specifying Timer_Any (~0) and letting Bios choose works, too, of course.  I was just verifying that Bios could create a Timer using either one.


    Well, thanks for trying to help. I doubt there's more you can do without actually seeing the code which is not possible as explained above. I have a viable workaround, so I'm not blocked anymore. I'm just curious to solve this puzzle.

  • In the non-working configuration, try adding this line to your .cfg file to see if it corrects the problem:

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

    Alan
  • I already include that.  And related to that, I already tried the reverse and utilized the generic, HAL-only version (and let the RTSC builder sort it out and link in the correct module), and that didn't resolve the issue either.

    Edit:  You are probably on the right path, though.  I didn't mention it, but oddly, can't create my custom timer and clock in the configuration file as shown in the clock module's help file.  I have to do it dynamically in the application.  (I do it in main() before I call BIOS_start().)

  • Is there any chance that you have "BIOS.clockEnabled = false;" in your non-working .cfg file?
    Alan
  • So I finally tracked down the issue.   Long story short, the peripheral control register was being improperly initialized (by the application).  The module's author intent was just to ensure that the GPIO peripheral was enabled, so he set that bit (bit 10).  Unfortunately, he left all the other bits zero.  This disabled the two timers.

    Bios apparently re-enables these (in Bios_start()) because as I indicated above, I can create working timers just fine manually, but BIOS sets up its H/W timer before main(), so it had no way of knowing that the timer control registers had been nullified by the application when it inadvertently disabled the peripheral itself.

    Anyway, thanks for trying to help!

    (For reference, reference to Section 3.2 "Peripheral Configuration at Device Reset" in the c6455 data sheet.)

  • Whew! I'm glad you sorted this out!