• State Resolved
  • Replies 7 replies
  • Subscribers 81 subscribers
  • Views 129 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

TMS320F2800157: Configuring INTOSC2 to be source for TIMER2

Blake Carpenter
Expert 6475 points
Part Number: TMS320F2800157
Other Parts Discussed in Thread: SYSCONFIG

Hi Support, 

My Assigned Focus Customer notes:

We’re not using Sysconfig, and I am setting the TMR2CLKCTL to the correct setting (using a DriverLib call to CPUTimer_selectClockSource, with a clock source of CPUTIMER_CLOCK_SOURCE_INTOSC2).

After boot, we setup our system to use INTOSC1 as the clock source for the PLL. We use a call to SysCtl_setClock to produce a SYSCLK of 120MH. No problem with any of that.

Later in the code, we setup TIMER0 (using SYSCLK as its source) to produce a 1 kHz tick. No problem with any of that.

And if I setup TIMER2 the same way (SYSCLK as source), the timer output is correct. 

When I switch TIMER2 to use INTOSC1 as it’s source (CPUTimer_selectClockSource w/ clock source of CPUTIMER_CLOCK_SOURCE_INTOSC1) and use the calculated period of 10000, everything is OK – I get the 1 kHz tick, a timer period of 1 ms. 

Things start getting strange when I change the code to use INTOSC2 as the TIMER2 source. Same setup as when using INTOSC1. The only change is in the call to CPUTimer_selectClockSource – I change the CPUTIMER_CLOCK_SOURCE_INTOSC1 to be CPUTIMER_CLOCK_SOURCE_INTOSC2. And using the same period count, I end up with TIMER2 firing every 450 ms. A little math and I arrive at a new “period count” of 22. When I use that value instead of the calculated value (10000), I get the desired 1 ms period / 1 kHz tick.

-------------

Your initial reply got me thinking, so I halted the system in the middle of operation and confirmed that TMR2CLKCTL.TMR2CLKSRCSEL was 2, so the call to CPUTimer_selectClockSource seems to do what I expect.

BTW – I also modified one of the simple example apps for the F2800157 (timer_ex1_cputimers) to configure the timers in a similar manner and got the same results, so I’m reasonably confident that it’s not something we’re doing here. I think it’s more likely something we’re not doing, but needs to be done.

I can get some code from the customer offline and send it to you for evaluation, but wanted to get your sanity check first.

Thanks!

Best Regards, 

Blake

  • 0
    TI__Guru 71835 points

    Blake,

    Take a look at the below and let's see if this is the issue: from the F280015 TRM page 137(below is screen shot of it as well)  (there is a small typo in the example, is should just say SYSCLK  = 100MHz)  Customer can substitute their sysclk value to get the correct cycle count delay.  I thought DriverLIB should take of this, but if customer can check the function call that make modification to CPUTIMER2CTL to verify this is the case, or they need to insert the delay manually.

    I also saw where SYSCLK = 120MHz,  in the above, I'm assuming this hasn't changed even when customer is changing clock source for TIMERs; there is also this restriction in the TRM (page 117 from the same link as above)

    Finally, and a bit tangential, after we resolve this issue we may want to have a discussion on the final clock source for SYSCLK, etc.  The default option from boot is INTOSC2; and alot of assumptions for missing clock actions revolve around switching to INTOSC1 if there is an issue.  If INTOSC1 is used as the main clock for the system, I'm not sure these provisions will work, i.e. if INTOSC1 were to go missing it can't switch to itself, etc.  Again we can drill down on this later once we resolve the above; but wanted to mention it as a best practice, etc.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Expert 6475 points

    Hi Matthew, 

    I'm knocked out...what a well researched and thorough answer provided quickly.  I really appreciate the help.

    I'll hold off on "this resolved my issue" until hearing back from the customer (should be today or Monday latest).

    Have a great weekend!

    Best Regards, Blake

  • 0 in reply to MatthewPate
    TI__Expert 6475 points

    Hi Matthew, 

    The customer gave it a try - feedback below:

    If I read the stuff above correctly, it’s saying that there needs to be a ( 3 * ( 120 / 10 ) ) + 9 = 45 SYSCLK pause between any accesses to the registers specified in table 4-18. 

    I went into the DriverLib code and checked for the delay in function CPUTimer_selectClockSource. There were no delays there, so I added a     asm(“ RPT #45 || NOP”)   after every access to the TMR2CLKCTL register.

     Alas, no change.

    Here’s some additional observations that may help.

    If I comment out the call to SysCtl_setClock in our startup code, and use the XCLKOUT pin GPIO18, with an XCLKOUT divisor of 8, I can confirm that SYSCLK is 25 MHz, and INTOSC1 is 25 MHz. However, when I route INTOSC2 to XCLKOUT, what I see on my scope is nuts. A lot of jitter, and a frequency that is not anywhere close to 10 MHz.

    When I change our DEVICE_SETCLOCK_CFG to use INTOSC2 instead of INTOSC1, the system craps out in SysCtl_setClock, at the ESTOP0 on line 522.

    If I switch DEVICE_SETCLOCK_CFG back to using INTOSC1, I can confirm (on XCLKOUT) INTOSC1 is 10MHz. However, if I change XCLKOUT to be INTOSC2, again, lots of jitter and a frequency no where in the 10 MHz range.

    I’ll update you as I learn more.

    Thanks for your help!  Have a great weekend.

    Blake

  • 0 in reply to Blake Carpenter
    TI__Guru 71835 points

    Blake,

    I'm a bit behind on this one, please give me another day to see if I can piece things together.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Expert 6475 points

    Sure thing Matt.  Thanks!

    Blake

  • 0 in reply to MatthewPate
    TI__Expert 6475 points

    Hi Matt,

    The customer clarified:

    -------------

    To clarify what my expectations are in regard to TIMER2+INTOSC2 – we can live with it working the way it appears to be working, as long as I can document why it works that way. The alternative (and ideal solution) is to figure out how to make it work the way the reference manual indicates it should work.

    -------------

    Best Regards,

    Blake

  • +1 in reply to Blake Carpenter
    TI__Guru 71835 points

    I'm replying back to the main thread after we had some offline discussions/debug.  The material involved was an early revision 0 version of the device; where there were some issues with INTOSC2.  These are/were resolved when we took this device to production, and current silicon has no issues.  

    Best,

    Matthew