LMK04828: PLL2 unlocked

We have two LMK04828 chips on a board that are programmed the same. One of the chips does not lock consistently lock on PLL2 and it seems to be thermally related, with problems arising when cooling the board.

The voltage at CPout2 is constant at 1.23V. Writing to register 0x168 to force re-calibration does not solve the problem. Changing CP current does not help.

The reference clock is 10MHz, PLL1 runs at 100MHz, and PLL2 is at 2.4GHz.

Correction: PLL1 PFD is at 10 MHz with a VCO at 100MHz, and PLL2 PFD is at 100MHz with VCO at 2.4GHz.

We have seen this problem on both chips with it more prevalent on the one in the center of the board (possibly because it is hotter before cooling).

PLL1 is unlocks intermittently.

With guidance from the National Semiconductor Clock Design Tool I have loop filters:

PLL1 C1: 18 nF

PLL1 C2: 820 nF

PLL1 R1: 3.9 kOhm

PLL2 C1: 56 pF

PLL2 C2: 1.8 nF

PLL2 R2:  2.2 kOhm

Hi John,

I checked your loop filter configurations, and they look stable. Can we get the register programming? That will help me look for the straightforward possible explanations first.

As in the linked thread, the fact that CPout2 is stable suggests that the PLL should indicate it is locked, with the exceptions of charge pump leakage or open-loop mode. When you lose lock on PLL1, do you know what the CPout1 voltage is? Do you have holdover mode enabled?

Regards,

Hi Derek,

Here is the register programming:

0x00: 0x0010 0x0000 0x0000
0x100: 0x0001 0x0044 0x0055 0x0002
0x104: 0x0028 0x001b 0x00b2 0x0015
0x108: 0x0001 0x0044 0x0055 0x0002
0x10c: 0x0028 0x001b 0x00b2 0x0015
0x110: 0x0001 0x0044 0x0055 0x0002
0x114: 0x0028 0x001b 0x00b2 0x0015
0x118: 0x0001 0x0000 0x0055 0x0002
0x11c: 0x0028 0x001b 0x00b2 0x0015
0x120: 0x0001 0x0044 0x0055 0x0002
0x124: 0x0028 0x001b 0x00b2 0x0015
0x128: 0x0001 0x0044 0x0055 0x0002
0x12c: 0x0028 0x001b 0x00b2 0x0015
0x130: 0x0001 0x0044 0x0055 0x0002
0x134: 0x0028 0x001b 0x00b2 0x0015
0x138: 0x0000 0x0002 0x000c 0x0000
0x13c: 0x0000 0x0008 0x0003 0x0013
0x140: 0x0000 0x0000 0x0006 0x005e
0x144: 0x00ff 0x007f 0x0020 0x0020
0x148: 0x0002 0x0042 0x0000 0x0016
0x14c: 0x0000 0x0000 0x00c0 0x007f
0x150: 0x0003 0x0002 0x0000 0x0000
0x154: 0x0001 0x0000 0x0001 0x0000
0x158: 0x0001 0x0000 0x000a 0x001e
0x15c: 0x001b 0x000a 0x0000 0x003b
0x160: 0x0000 0x0001 0x00c4 0x0000
0x164: 0x0000 0x0004 0x0000 0x0000
0x168: 0x0018 0x0059 0x001f 0x00bd
0x16c: 0x0012 0x0000 0x001b 0x0020
0x170: 0x00a8 0x00aa 0x0002 0x0000
0x174: 0x0000 0x0000 0x0000 0x0000
0x178: 0x0040 0x0000 0x0005 0x0097
0x17c: 0x0015 0x0033 0x0000 0x0005
0x180: 0x0080 0x0000 0x0002 0x0000
0x184: 0x00a0 0x0048 0x0000 0x0000


I do not have a CPout1 voltage measurement for when PLL1 loses lock yet. Tracked holdover mode is enabled.

Thanks for your answer,
John

When I force PLL1 to unlock by removing the reference signal, CPout1 gets pulled up to 3.3V.

Hi John,

One thing I don't think I mentioned: if CPout2 voltage remains "constant", this isn't always a good indicator that PLL2 is remaining locked. For example, if the VCXO tuning range for PLL1 is ±5kHz (±50ppm), the PLL2 VCO sees maybe ±120kHz difference across the entire tuning range, which corresponds to about 6mV difference in tuning voltage (estimated from kVCO in the datasheet). On the other hand, this does suggest that there is no problem with the OSCin connection, since CPout2 voltage would swing to the rails if the input signal were interrupted.

I looked at your register programming, and although I see that you have holdover enabled, you don't have any of the holdover entry detection mechanisms enabled, so you are never actually entering holdover. This makes sense, since CPout1 is pulled to the rail when the reference signal is removed. I think this explains why PLL2 lock is unstable: any time PLL1 loses an input signal or falls out of lock, PLL2 sees a large transient on OSCin phase.

The holdover entry detection bits can potentially provide a way to debug the problem. By routing the Holdover Status output to one of the status pins, HOLDOVER_LOS_DET (coupled with LOS_EN and the LOS_TIMEOUT settings) can help indicate if the LMK04828 detects loss of the input signal. If the input signal is being lost, maybe something about the thermal cycling is causing the input connection to fail intermittently.

I also noticed that PLL2 loop filter is programmed with the integrated R3/R4 set to 2kΩ. I checked the values using PLLatinumSim, and I found that this creates significant peaking, bringing the phase margin of the loop down to about 40°. With the temperature cycling, I suspect the loop filter values may be changing enough to affect loop stability. You should consider decreasing R3/R4 to 200Ω each instead; this reduces peaking, bumps the phase margin up to about 50°, and improves phase noise as well. This can be changed in software, so it's useful as a quick debugging check to see if loop stability relates to the issues you are seeing. If the phase margin does relate to this behavior, and you are okay with restricting the loop bandwidth a bit (600kHz vs 680kHz), you could also reduce R2 to 1.8kΩ which (combined with R3/R4 changes) gets you up to 58°.

Regards,

Hi Derek,

Thank you for your response. I used PLLatinum Sim to design a more robust PLL2 filter, (including reduced values for R3 and R4) and I am no longer seeing PLL2 come unlocked while PLL1 is locked.

Now, my problem is that PLL1 unlocks and PLL2 unlocks along with it. When this happens CPout1 is pulled up to 3.3V. I suspect these unlocks are caused by noise on the Clkin2 (reference clk) or OSCin pins. Do you have any tips for identifying a problem between those, or other ideas for causes of the unlock case?

John