• State
  • Locked Locked
  • Replies 19 replies
  • Subscribers 34 subscribers
  • Views 2594 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C129 with 120 MHz external clock

Brad Rodriguez
Intellectual 630 points
Other Parts Discussed in Thread: TM4C1294NCPDT

Hello.  We are planning to use a TM4C1294NCPDT with a 120 MHz external clock oscillator.  According to section 5.2.5.1 of  the TM4C1294NCPDT Microcontroller Data Sheet this is permissible, and also according to section 27.9.5 (Main Oscillator Specifications) when "PLL in BYPASS mode".

However, the Main Clock Tree in Figure 5-5 shows that the USB is clocked exclusively by the PLL's VCO output.  Section 5.2.5.2 under "USB Clock Control" says "When the USB module uses the integrated USB PHY, the MOSC must be the clock source, either with or without using the PLL, and the system clock must be at least 30 MHz."

My questions:

1. Is it necessary to activate the PLL in this configuration, or can the 120 MHz MOSC/SYSCLK be routed to the USB?

2. If it is necessary to activate the PLL, can this be done with a 120 MHz MOSC?  I see no specifications for the maximum PLL reference frequency, or for the PLL's input divider (prescaler).  Normally I would be conservative and use the Q divider to reduce the 120 MHz input frequency to a 24 MHz reference frequency (which I know from Table 5-7 the PLL will accept), and then multiply that back up to 480 MHz VCO output, which I know the USB module will accept.

3. On that subject, should the PLL equation  fIN = fXTAL / (Q+1) (N+1) be interpreted as fIN = fXTAL / ((Q+1) (N+1)), or as fIN = (fXTAL / (Q+1)) * (N+1) ?  (In other words, is N+1 a dividing or a multiplying factor?)  Is there a more detailed diagram of the PLL available anywhere?

Thanks,
Brad

  • 0
    TI__Mastermind 22715 points

    Brad,

    While our design expert is opn vacation, I am trying to answer your question from a user's perspective.

    (1) You will have to enable the PLL to generate the 60Mhz clock to USB.

    (2) Both Q and P are the settings for dividers.

    I am wondering why you want to use a 120 MHz external oscillator. Do you have any concerns on emission? Are you using the same 120 MHz signal elsewhere? The board layout could be a challenge.

    Thanks and regards,

    Zhaohong

  • 0 in reply to Zhaohong Zhang
    Guru 117855 points

    May I agree w/Mr. Zhang in the (unusual) use of "so high" (that's VHF) an external oscillator frequency.   (you are just 24MHz shy of the 2M ham band)

    Indeed - if this targets a commercial product - good luck w/agency approval!

    It must be that this frequency is needed elsewhere (FPGA) but in 10 years solid ARM MCU design (4 vendors) - "never" have we seen so high a frequency supplied to an ARM MCU!   Usually the upper limit peaks @ 25-30MHz - and the well designed MCU PLLs then, "dial that up."   

    May I hazard the guess that you're "well beyond the pack"...or... this is a BAD idea?    (we vote the latter)

  • 0 in reply to Zhaohong Zhang
    Intellectual 630 points
    Zhaohong, thank you for the reply. To answer your question, we are hoping to do some complex timing with the TM4C's timer outputs. Our first prototype uses the PLL-generated 120 MHz, but we are seeing too much timing jitter, thus the interest in a stable external clock. (Either that, or switch to an MCU from a different manufacturer, possibly moving the timing logic to an FPGA.)

    We also need to synchronize another subsystem with the MCU, and this is greatly simplified with an external clock. And yes, we are aware of the issues of clock distribution and board layout.

    It's not a problem for us to use the PLL for the USB interface, but can the PLL accept a 120 MHz MOSC? Does the Q divider precede the N divider, or is it the other way around?
  • 0 in reply to Brad Rodriguez
    TI__Mastermind 22715 points
    Brad,

    According to the datasheet, I think that PLL can take 120 MHz as input. I do not know the order of the Q and P divider.

    However, I would suggest you to re-evaluate the sync requirement in your application. I feel really uneasy if something needs to be synchronized to a 120MHz clock. I saw people using a common oscillator to reduce the emission and noise on the board but not for synchronization. It is preferred to keep the high frequency operation inside the chip. The operation of the subsystems are normally synchronized by "event" instead of clocks. To make the design robust and easier to debug, the common practice is to make the operation of each sub system as decoupled as possible.

    Thanks and regards,

    Zhaohong
  • 0 in reply to Zhaohong Zhang
    Intellectual 630 points

    Zhaohong, thanks.  Can you tell me where in the datasheet you found (or deduced) that spec?

    It may be that we can generate a suitable sync signal from one of the TM4C's timer outputs.  But we still desire a more stable clock source than the TM4C's PLL.  I expect that placing a 120 MHz oscillator next to the TM4C's OSC0 pin won't pose any insurmountable problems.

    Brad

  • 0 in reply to Brad Rodriguez
    Intellectual 750 points

    According to the TM4C129x data sheet, section 28.9.1, the maximum clock input to the PLL is 25 MHz.

    I am quite surprised you have significant timing jitter using the PLL.  How are you measuring this?


    Randy

  • 0 in reply to Randy Ott
    Guru 47900 points
    Let the record show that this is the 2nd "objection" to MCU clock input exceeding 25-30MHz!
  • 0 in reply to Randy Ott
    Intellectual 630 points
    Hi Randy, thanks. I did see that spec in the TM4C1294NCPDT data sheet, but it seemed to imply that that was the range for the PLL reference frequency (after the prescaler) rather than the input frequency (before the prescaler). Thus my request for clarification.

    At the moment I am using a TM4C timer to generate a regular 50 usec pulse, triggering on the leading edge, and observing the trailing edge with a digital 'scope. I see about 8 ns of jitter on the trailing edge, of which 2.5 ns can be attributed to the 'scope. I have a request in for a high-resolution counter/timer, so I hope to have some more precise numbers next week. (I grant that one limitation I am facing is that I am testing with a TM4C1294 Launchpad, which probably has a cheap crystal rather than a precise one.)

    Brad
  • 0 in reply to cb1
    Intellectual 630 points
    cb1, you'll have to believe me when I say that a few mW at 120 MHz is the *least* of the RF on this board.
  • 0 in reply to Brad Rodriguez
    Intellectual 750 points
    I wouldn't be too quick about blaming the PLL for the observed jitter. 8 nS is very close to the 8.333 nS period of the 120 MHz clock. This can also be explained by other factors such as program execution and flow, interrupt latency, etc...
    Are you generating this timing using the capture/compare facilities of the timer or some other means?
    The PLL really should not jitter that much.
  • 0 in reply to Brad Rodriguez
    Guru 27665 points
    160ppm,I'd at least investigate the crystal. Maybe you need an oven controlled oscillator?

    Robert
  • 0 in reply to Robert Adsett
    Intellectual 750 points
    Now we are talking about something completely different. Frequency accuracy and short term stability (jitter) are not the same thing.

    Randy
  • 0 in reply to Randy Ott
    Guru 27665 points
    We are talking the same thing, crystals have stability as well as accuracy ratings and that is definitely within the common range of stability specs for crystals. OCXO stability ranges are about 3 orders of magnitude better.

    You'd have to check the data sheets to see what conditions that spec might narrow for on a particular crystal.

    The oscillator circuit on the micro will have a certain contribution to the stability as well, another reason to consider an oscillator instead.

    Robert
  • 0 in reply to Brad Rodriguez
    Guru 47900 points

    Thanks for your response.

    I do not limit my concern to RF - but to the potentially "uncharted waters" which such "external VHF signal entry" imposes upon the entirety of your MCU.   I greatly doubt that this MCU has been (fully) tested/characterized in this manner - thus subjecting you to multiple, "unknowns!"

  • 0 in reply to Randy Ott
    Intellectual 630 points
    Randy, I have the timer set up in PWM mode. No program execution is involved once the timer is started.

    Robert, it is possible that the crystal is to blame. But usually (as Randy has noted) the problem with crystals is frequency drift -- especially with temperature -- not jitter. For our application absolute frequency accuracy is not as important as pulse width *repeatability*. To use a contrived example: if we get 50.1 usec rather than 50 usec we can compensate, as long as we consistently get 50.100 usec on each pulse. In our earlier hardware, using an FPGA for timing, we managed quite well with a +/-10ppm oscillator, no oven.

    It was my hope -- perhaps I should say my hare-brained idea -- that, given the timer capabilities of the TM4C, we could dispense with the FPGA. I'm beginning to suspect that we can't.

    cb1, T.I. has specified that the chip can accept a 120 MHz external oscillator. I don't know how fully they have tested or characterized that, but I would expect that the published number is based on *something*.
  • 0 in reply to Brad Rodriguez
    Guru 47900 points

    Brad Rodriguez said:
    I don't know how fully they have tested or characterized that, but I would expect that the published number is based on *something*.

    Having past worked at a similar - semi "giant" - may I note that such extreme "minority use-case/application" - as described here - may not have enjoyed "strict" compliance & performance test/verification.     You may note the presence of "errata" - primarily impacting device's "major use-cases" - which receive in-depth test/compliance verification.     "Cling" to "something" seems frail - more wish/hope than acceptance of reality...

    As always - I urge you to repeat such tests over a broader board/device population - to (positively) rule out single board/device anomaly...

  • 0 in reply to Brad Rodriguez
    Intellectual 750 points
    Yes, the PWM should be rock solid, no pun intended.
    The 8 nS stood out to me since this is the clock period.
    Using a stable external 120 MHz. source is certainly worth the effort just to satisfy the uncertainty of the PLL.
    If this is the answer, you do have to give up a lot of functionality with regard to USB, Ethernet, boot loaders, etc.
    Power supply decoupling especially on the LDO can be a factor too. Not sure the Launchpad is the best layout for this.
    An FPGA can be very handy to have sometimes.

    Randy
  • 0 in reply to Brad Rodriguez
    Guru 27665 points

    Brad Rodriguez said:
    But usually (as Randy has noted) the problem with crystals is frequency drift -- especially with temperature -- not jitter

    That's what I would expect as well, but I've been stung by such expectations before (not with a xtal). 

    In my case there was a manufacturer's spec on offset uncertainty of a sensor. THe value was in the usual range for such sensors and I thought nothing of it since the uncertainty depends in part of strain from assembly to the PCB.  In actual use what I expected to be a relatively stable offset as I expected and experienced from similar sensors varied over the offset uncertainty range over a period of minutes.  My lesson was just because that's what you expect from experience and design don't assume that the quoted variance comes over the full operating range and is smaller over a subset of the range. If you depend on that behaviour verify the device behaves as you expect.

    I do notice that my data sheet at least does not seem to specify the jitter for either the PLL or the oscillator. Although the jitter on the oscillator probably depends on the Q of the crystal.

    Robert

  • 0 in reply to Randy Ott
    Intellectual 630 points

    An update: I am now testing with a high resolution timer, and I am seeing jitter under 1 nsec -- with or without the PLL.  So I think the 8 nsec I was seeing earlier was from my 'scope, not from the MCU.

    (Big sigh of relief.)