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.

LMK04828: PLL 1 and PLL 2 will not lock.

Part Number: LMK04828


We are having an issue with our PLL's not locking. We have checked our "lock count" value according to 10.2.1.1 of the datasheet and allowed adequate time for the PLL's to lock. 

We are attempting to run in dual PLL mode. With a clock input on CLKin1 of 10MHz. And an OSCin frequency of 500MHz. We are using DCLKout2, 4, and 6 as a 100MHz output. 

Here are the values for our loop filters:

PLL1 Loop Filter:

R0 (INIT)	0x000090
R0	0x000000
R2	0x000200
R3	0x000306
R4	0x0004D0
R5	0x00055B
R6	0x000600
R12	0x000C51
R13	0x000D04
R256	0x010003
R257	0x010155
R258	0x010255
R259	0x010301
R260	0x010402
R261	0x010500
R262	0x0106F9
R263	0x010700
R264	0x010878
R265	0x010922
R266	0x010A55
R267	0x010B01
R268	0x010C42
R269	0x010D00
R270	0x010E31
R271	0x010F05
R272	0x011078
R273	0x011122
R274	0x011255
R275	0x011301
R276	0x011442
R277	0x011500
R278	0x011631
R279	0x011705
R280	0x011878
R281	0x011922
R282	0x011A55
R283	0x011B01
R284	0x011C42
R285	0x011D00
R286	0x011E31
R287	0x011F05
R288	0x012018
R289	0x012155
R290	0x012255
R291	0x012300
R292	0x012402
R293	0x012500
R294	0x012679
R295	0x012705
R296	0x012808
R297	0x012955
R298	0x012A55
R299	0x012B00
R300	0x012C02
R301	0x012D00
R302	0x012E79
R303	0x012F00
R304	0x013006
R305	0x013155
R306	0x013255
R307	0x013300
R308	0x013402
R309	0x013500
R310	0x0136F9
R311	0x013700
R312	0x013800
R313	0x013900
R314	0x013A0C
R315	0x013B00
R316	0x013C00
R317	0x013D08
R318	0x013E03
R319	0x013F06
R320	0x01400D
R321	0x014100
R322	0x014200
R323	0x014311
R324	0x01449E
R325	0x01457F
R326	0x014612
R327	0x01471B
R328	0x014802
R329	0x014902
R330	0x014A02
R331	0x014B16
R332	0x014C00
R333	0x014D00
R334	0x014EC0
R335	0x014F7F
R336	0x015000
R337	0x015102
R338	0x015200
R339	0x015300
R340	0x015478
R341	0x015500
R342	0x015602
R343	0x015700
R344	0x015896
R345	0x015900
R346	0x015A64
R347	0x015BC4
R348	0x015C20
R349	0x015D00
R350	0x015E00
R351	0x015F0B
R352	0x016000
R353	0x016105
R354	0x016224
R355	0x016300
R356	0x016400
R357	0x01650C
R369	0x0171AA
R370	0x017202
R380	0x017C15
R381	0x017D33
R358	0x016600
R359	0x016700
R360	0x01680C
R361	0x016959
R362	0x016A20
R363	0x016B00
R364	0x016C00
R365	0x016D00
R366	0x016E13
R371	0x017300
R8189	0x1FFD00
R8190	0x1FFE00
R8191	0x1FFF53

R2: 1.5KOmhs

C2: 5.6uF

C1: 120nF

PLL2 Loop FIlter:

R2: 820 Omhs

C2: 2.2nF

C1: 47pF

I also attached the hex values for the 

  • Just for clarification. The link is not the Loop filter values. The link got misplaced while I was uploading the hex values. Not sure how it got placed in the middle of the page. Anyway, the link has all of the register hex values. 

    Thanks for looking.  

  • Hi Scott,

    Thanks for providing the hex values, it makes it very easy to see how the PLL was configured. I see two things that are likely causing problems:

    1. I entered the values you specified into PLLatinum Sim, and I calculate that your loop bandwidth is around 10 Hz. Given that the phase detector frequency is almost six orders of magnitude faster, I suspect PLL1 is cycle slipping. A quick way to check this is to set the STATUS_LDx pins to display the PLL1 N/2 and PLL1 R/2 output values, and probe them on an oscilloscope. You can also configure PLL2 as an OSCout buffer, and use this to monitor the behavior of the VCXO with a frequency counter or a phase noise analyzer transient measurement. If you do see cycle slipping causing problems, the quickest resolution is to increase the loop bandwidth.
    2. You are operating OSCin very close to the datasheet maximum frequency rating. Technically, if there is any positive frequency offset on the 10 MHz input, the OSCin spec is being violated. Operating this close to the OSCin maximum frequency rating is not recommended, and I strongly suggest picking a lower frequency VCXO if possible. And for performance reasons, a 500 MHz VCXO may not be optimal anyway: the close-in noise of a VCXO tends to degrade with increasing frequency. So it is often a better idea to use the lowest VCXO frequency needed to achieve a reasonable PLL2 phase detector frequency (e.g. 100 MHz or 50 MHz with doubler enabled).

    If neither cycle slipping or the OSCin frequency range are the source of the problem, we can continue debugging.

    Regards,

  • Hi Derek,

    Thank you for your reply. We unfortunately don't have access to the STATUS_LDx pins. We have been reading the registers 0x182 and 0x183 to confirm lock on PLL 1 and PLL 2.

    At this point we have shifted our focus off of PLL1 and on to PLL2. We removed the 500MHz clock off of our board and attached a function generator to supply our clock into OSCin*. This is single ended. We adjusted our values in TICS Pro for a 100MHz clock, keeping the same values for the loop filters. At this point when querying registers 0x182 and 0x183, we now see that we have the lost lock bit engaged. Meaning that we had lock but lost it. This is an improvement, but we need lock. 

    I Uploaded a picture of a portion schematic which shows the loop filters and the oscillator. Like I said earlier, we did remove the VCSO on one of our boards and attached a function generator to allow for different frequencies. 

  • Hi Scott,

    https://e2e.ti.com/support/clock-and-timing/f/48/p/829826/3070798#3070798 In this post it sounds like you are preparing to do another board revision. Is there any further debugging you would like to attempt with this revision?

    Regards,

  • Hi Scott,

    It sounds like this thread is no longer current, so I'm marking it as resolved.

    Regards,