• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 21 subscribers
  • Views 484 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.

CDCE62005 AUX_IN

Thomas Demming
Prodigy 215 points
Other Parts Discussed in Thread: CDCE62005

One question on the AUX_IN input:

http://www.ti.com/lit/an/scaa096/scaa096.pdf states that the AUX_IN is a third reference input that targets applications that need a backup or holdover function.

The same application note also mentiones XTAL1 and XTAL2 pins, which are not mentioned in the CDCE62005 datasheet.

Now coming to the point:

In our application we have set
PRISEL = 1
SECSEL = 1
AUXSEL = 1
EECLKSEL = 1

Synthesizer source indicator bit indicates that Primary Input is used.

So far, so good...

When we probe the AUX_IN pin with a passive probe while the CDCE62005 is locked to the primary input, we see that none of the output clocks is in phase with the primary input anymore and the PLL_LOCK pin transits to LOW.

QUESTION: What other internal purposes (except being an input to the SMART MUX) does the clock at AUX_IN serve?

  • 0
    TI__Expert 3985 points

    Hi Thomas,

    thanks for point out the mismatch between the Apps Report and the D/S. Please refer to the D/S where it is mention that AUX_IN is the pin where the XTAL needs to be connected. Internally we have a Colpitts oscillator stage which needs only one connection to the XTAL.

    The AUX_IN does not have any other purpose rather than being the crystal oscillator stage input. What was the purpose of probing the AUX_IN pin while the device is locked to the primary? was a crystal attached to that pin?

    Regards,

    Leandro

  • 0 in reply to Leandro_z
    Prodigy 215 points

    Hi Leandro,

    thanks for the clarification about the AUX_IN.

    About the background: Our production has had some issueds during module testing and we think it might be related to the crystal that is attached to AUX_IN.

    BUT: During production test the CDCE62005 is running on PRI_REF and the SMART_MUX mode is set to automatic. So there should not be any influence of the AUX_IN input to any of the output signals, right?

    Our observation is: Although CDCE62005 is running on PRI_REF we loose PLL lock in case we touch the AUX_IN signal line with an oscilloscope probe.
    That is the point we do not understand at the moment......

    BR, Thomas

  • 0 in reply to Thomas Demming
    TI__Expert 3985 points

    Hi Thomas,

    I attached some slide where I explain how the SmartMUX works and what could be the reason of the Lock Condition loss, you experienced when you touch the AUX_IN pin with the scope probe.

    I also suggest you a couple of solutions to your case.

    BR, Leandro

    CDCE62005_SmartMux.pdf