• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 21 subscribers
  • Views 418 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 Frequency Inaccuracy

StuartT
Prodigy 250 points
Other Parts Discussed in Thread: CDCE62005

Hi,

We’re currently having problems with the CDCE62005 not outputting the expected frequency correctly on our board.

The board is set up with a 25MHz crystal on AUX IN and configured to generate 100MHz on Output 0 and 150MHz on Output 3 (both LVDS).

However, the 150MHz output is either 150.533MHz (which exceeds our expected tolerance) or 149.994MHz (which is withn spec). No measurements have been made on the 100MHz output.

The device will lock to either of these frequencies and remain locked. This causes an issue if it locks at 150.533MHz (as measured on a timer/counter).

Recalibrating at this point does not correct the frequency deviation.

Register settings:

Reg0 = EB02_0320

Reg1 = 6884_0301

Reg2 = 6884_0302

Reg3 = EB84_0303

Reg4 = 6886_0314

Reg5 = 6000_8BF5

Reg6 = 80BE_02A6

Reg6cal = 84BE_02A6

Reg7 = 8D00_37F7

Reg8 = 0000_0000

This problem is not seen when using the CDCE62005 eval card and loading our register contents – recalibrating gives 149.987MHz consistently (which isn't the same, but is considered adequate)..

Can you advise please?

Thanks

Stuart

  • 0
    TI__Guru* 81035 points

    Hi Stuart,

    Try making these changes to Registers 6 and 7. I think the loop filter is not setup correctly and this should improve the stability.

    6              808e02a6

    7              8d9bbde7

    Best regards,

    Matt

  • 0
    TI__Expert 4150 points

    Hi Stuart,

    Your register 8 value should have an 8 as the last byte, not 0.

    You have your input mux set to AUTO. This means that the Primary input is prioritized over secondary, over XTAL. THerefore, if you have no signal but enough noise on the primary on secondary input, your device might (theoretically) toggle to these inputs and try to lock to them. If you don't use PRI and SEC input, please set disable automux by setting the SmartMUX to AUX SEL only. If however you want the device to switch to PRI or SEC input when the signal becomes available, then you are ok with the SMARTMUX settings.

     

    The true problem with your settings however is your loop filter setting. It is unstable and therefore you can not safely achieve lock. Your phase margin is 89%, that is too high, you want something near 65%. Your loop BW is too high with 6MHz. The highest loop BW possible is around 1MHz, but you should aim for maybe 300-400kHz in your case. I recommend to change the following component values:

    C1: from 0.01pF to 18pF

    R2: from 20k to 4k

    C3: keep 473.5pF

    R3: from 10k to 5k

    C3: from 0.01pF to 8pF

    ChargePump current: from 2mA to 750μA

     

    Here is the screenshot of the loop filter tool with the recommended settings.

     

  • 0 in reply to Fritz
    TI__Expert 4150 points

    PS: Stuart, I forgot to add: if you want to force a calibration by writing to Reg 6 twice, please make sure to write the second time after you wrote to register 7, so the device has all setting accurate before initiating a calibration.

  • 0 in reply to Matt Sunna
    Prodigy 250 points

    Hi

    Thanks for your help. I have a query regarding the upper bits of  Reg 7 being suggested (8d9bbde7) by Matt.

    When I decode this value using Table 13 in the CDCE62005 datasheet (Rev D) this gives some queries:

    Bit 24 is set to a 0, but the datasheet says must be a ‘1’

    Bits 25 and 23 – should the values of these bits (SEL_DEL1 and SEL_DEL2) match each other?

    Allthough I can now see my filter settings were wrong, this query is also applicable for my earlier Reg 7 value, the contents of which were generated by the GUI (v1.4.4) , and bits (27:21) were the same. Is there an error in the datasheet (Table 13)?

    Thanks

    Stuart