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.

LMK03328: Loss lock behavior at PLL1 during PLL2 register setting change with LMK03328

Part Number: LMK03328

Hi team,

My customer is using our LMK03328 and would like to consult with you about the user case as below.

Currently encountered when the normal switch to mode1 (setting files such as attachments),

normal.txt
R0	0x0010
R1	0x010b
R2	0x0232
R3	0x0301
R4	0x0401
R5	0x0500
R6	0x06d8
R7	0x0724
R8	0x0802
R9	0x0900
R10	0x0aae
R11	0x0b00
R12	0x0cdf
R13	0x0d00
R14	0x0e00
R15	0x0f00
R16	0x1000
R17	0x1100
R18	0x1200
R19	0x1300
R20	0x14ff
R21	0x15ff
R22	0x16ff
R23	0x1702
R24	0x1800
R25	0x19f5
R26	0x1a00
R27	0x1b20
R28	0x1c20
R29	0x1d2a
R30	0x1e50
R31	0x1f28
R32	0x2000
R33	0x2111
R34	0x2228
R35	0x2300
R36	0x2411
R37	0x2514
R38	0x2623
R39	0x2714
R40	0x2808
R41	0x2900
R42	0x2a00
R43	0x2b14
R44	0x2c08
R45	0x2d0a
R46	0x2e00
R47	0x2f00
R48	0x30ff
R49	0x3100
R50	0x329f
R51	0x3303
R52	0x3400
R53	0x3500
R54	0x3600
R55	0x3700
R56	0x3806
R57	0x3918
R58	0x3a00
R59	0x3b64
R60	0x3c00
R61	0x3d00
R62	0x3e00
R63	0x3f04
R64	0x401e
R65	0x41b0
R66	0x420f
R67	0x4301
R68	0x4401
R69	0x4505
R70	0x4607
R71	0x4706
R72	0x4818
R73	0x4900
R74	0x4a64
R75	0x4b00
R76	0x4c00
R77	0x4d00
R78	0x4e04
R79	0x4f1e
R80	0x50b0
R81	0x510f
R82	0x5201
R83	0x5301
R84	0x5405
R85	0x5507
R86	0x5600
R87	0x5700
R88	0x5800
R89	0x59de
R90	0x5a01
R91	0x5b18
R92	0x5c01
R93	0x5d4b
R94	0x5e01
R95	0x5f86
R96	0x6001
R97	0x61be
R98	0x6201
R99	0x63fe
R100	0x6402
R101	0x6547
R102	0x6602
R103	0x679e
R104	0x6800
R105	0x6900
R106	0x6a05
R107	0x6b0f
R108	0x6c0f
R109	0x6d0f
R110	0x6e0f
R111	0x6f00
R112	0x7000
R113	0x7100
R114	0x7200
R115	0x7308
R116	0x7419
R117	0x7580
R118	0x7607
R119	0x7705
R120	0x7800
R121	0x790f
R122	0x7a0f
R123	0x7b0f
R124	0x7c0f
R125	0x7d00
R126	0x7e00
R127	0x7f00
R128	0x8000
R129	0x8108
R130	0x8219
R131	0x8380
R132	0x8407
R133	0x8505
R134	0x8600
R135	0x87a6
R136	0x8801
R137	0x8912
R138	0x8a00
R139	0x8b00
R140	0x8c00
R141	0x8d00
R142	0x8eff
R143	0x8f00
R144	0x9000
R145	0x9100
R146	0x9200
R147	0x9300
R148	0x9400
R149	0x9500

mode1.txt
R0	0x0010
R1	0x010b
R2	0x0232
R3	0x0301
R4	0x0401
R5	0x0500
R6	0x06d8
R7	0x0724
R8	0x0802
R9	0x0900
R10	0x0aae
R11	0x0b00
R12	0x0cdf
R13	0x0d00
R14	0x0e00
R15	0x0f00
R16	0x1000
R17	0x1100
R18	0x1200
R19	0x1300
R20	0x14ff
R21	0x15ff
R22	0x16ff
R23	0x1702
R24	0x1800
R25	0x19f5
R26	0x1a00
R27	0x1b20
R28	0x1c20
R29	0x1d2a
R30	0x1e50
R31	0x1f28
R32	0x2000
R33	0x2111
R34	0x22a8
R35	0x2300
R36	0x2411
R37	0x2554
R38	0x2623
R39	0x2714
R40	0x2808
R41	0x2900
R42	0x2a00
R43	0x2b54
R44	0x2c08
R45	0x2d0a
R46	0x2e00
R47	0x2f00
R48	0x30ff
R49	0x3100
R50	0x329b
R51	0x3303
R52	0x3400
R53	0x3500
R54	0x3602
R55	0x3700
R56	0x3806
R57	0x3918
R58	0x3a00
R59	0x3b64
R60	0x3c00
R61	0x3d00
R62	0x3e00
R63	0x3f04
R64	0x401e
R65	0x41b0
R66	0x420f
R67	0x4301
R68	0x4401
R69	0x4505
R70	0x4607
R71	0x4706
R72	0x4818
R73	0x4900
R74	0x4a36
R75	0x4b00
R76	0x4c00
R77	0x4d00
R78	0x4e04
R79	0x4f1e
R80	0x50b0
R81	0x510f
R82	0x5201
R83	0x5301
R84	0x5405
R85	0x5507
R86	0x5600
R87	0x5700
R88	0x5800
R89	0x59de
R90	0x5a01
R91	0x5b18
R92	0x5c01
R93	0x5d4b
R94	0x5e01
R95	0x5f86
R96	0x6001
R97	0x61be
R98	0x6201
R99	0x63fe
R100	0x6402
R101	0x6547
R102	0x6602
R103	0x679e
R104	0x6800
R105	0x6900
R106	0x6a05
R107	0x6b0f
R108	0x6c0f
R109	0x6d0f
R110	0x6e0f
R111	0x6f00
R112	0x7000
R113	0x7100
R114	0x7200
R115	0x7308
R116	0x7419
R117	0x7580
R118	0x7607
R119	0x7705
R120	0x7800
R121	0x790f
R122	0x7a0f
R123	0x7b0f
R124	0x7c0f
R125	0x7d00
R126	0x7e00
R127	0x7f00
R128	0x8000
R129	0x8108
R130	0x8219
R131	0x8380
R132	0x8407
R133	0x8505
R134	0x8600
R135	0x87a6
R136	0x8801
R137	0x8912
R138	0x8a00
R139	0x8b00
R140	0x8c00
R141	0x8d01
R142	0x8eff
R143	0x8f00
R144	0x9000
R145	0x9100
R146	0x9200
R147	0x9300
R148	0x9400
R149	0x9500

The only setting changed is to adjust the PLL2 related settings,
However, you will still see PLL1 status showing the phenomenon of unlocking (purple channel as shown below),
And make the original output clock will be broken for a period of time (the yellow channel in the figure below),
Setting process: PLL2 power down enable -> PLL2 & divider setting -> PLL2 power down disable

We would like to consult with you whether  the PLL1 & PLL2 inside the LMK03328 both independent channels that do not affect each other? If so, what are the setting procedures to avoid mutual influence when PLL1 & PLL2 are switched?

Would also consult with you that is there any suggestion phase margin range to ensure the stability of the PLL? Thank for your kindly help.

  • Hello Fengbin,

    My coworker will get back to you tomorrow.

    Regards,
    Hao

  • Hello Feng, 

    PLL1 & PLL2 should be independent. If changes are only being made to one, I would not expect the other one to be impacted. Unless inadvertently you're updating some settings on the other one as well, when you're just trying to update one and therefore causing it to recalibrate. 

    Do you have the .tcs files for the following change from normal --> mode1? Currently importing hex registers shows me some incorrect data, which most likely has to do with updating the XO frequency since it's showing VCO at 10 GHz. 

    So please provide the primary reference, secondary reference frequencies, the doubler/r divider setting, and in normal operation what is VCO freq (assuming 5 GHz) and locked into presumably primary reference? 

    Now, when you switch to mode 1, what is it that you're trying to do? 

    - Power down PLL2 

    - Updating PLL2 divider settings, is this output divider and vco divider? 

    - Power up PLL2 

    And during this whole time, no disturbance to PLL1, correct? While in your setup, it shows PLL1 unlocks (purple) and it's even before PLL2 output (yellow stops toggling). This is only monitored on the status channel, what is the actual output (from PLL1) doing? 

    Thanks and regards,

    Amin 

  • hi Amin,

    This is Frank. Ben's account transfer to me. Let me follow up this issue.

    "PLL1 & PLL2 should be independent. If changes are only being made to one, I would not expect the other one to be impacted. Unless inadvertently you're updating some settings on the other one as well, when you're just trying to update one and therefore causing it to recalibrate. "

    =>Can I know which register would affect PLL1? so, I can check it.

    "Do you have the .tcs files for the following change from normal --> mode1? 

    =>tcs files are as attachment.

    mode1.tcsnormal.tcs

    So please provide the primary reference, secondary reference frequencies, the doubler/r divider setting, and in normal operation what is VCO freq (assuming 5 GHz) and locked into presumably primary reference? "
    "- Updating PLL2 divider settings, is this output divider and vco divider? "

    =>please check below.

    Mode1 input setting.png

    Mode1 output setting.png

    Normal input setting.png

    Normal output setting.png

     

    "And during this whole time, no disturbance to PLL1, correct? While in your setup, it shows PLL1 unlocks (purple) and it's even before PLL2 output (yellow stops toggling). This is only monitored on the status channel, what is the actual output (from PLL1) doing? "

    =>correct, no disturbance. PLL1 output clock is as reference clock for video asic.

     

    BR,

    frank

     

  • Hi Frank, 

    Thanks for providing the .tcs files. That made it so I can load into TICSpro and understand what I'm looking at. 

    So first question is, how are they switching between Normal to Mode1? Are they reloading everything from the .txt files in terms of register updates? Because that's not necessary. Since they're changing PLL2 to be powered up and changing the mux select on some of the outputs to be PLL2, they can just write those few registers. I compared the .txt files and noticed these differences that make sense: 

    R34 28h to a8h - changes output 2 mux selection to PLL2

    R37 14h to 54h - changes output 4 mux selection to PLL2

    R43 14h to 54h - changes output 7 mux selection to PLL2 

    Changes to R51 (PLL2 Input select) and R54 (PLL2 Rdiv) - which brings me to the next point, if PLL2 is powered down in normal mode, why do PLL2 settings need updating? Wouldn't be easier to start with Mode1 and just powered down PLL2 (and change the output mux selection) to have that as the starting point? 

    Next thing that I noticed is that R71[0] which is the PLL2 PDN didn't show a difference between the .txt files but it should've, since the .tcs file clearly has PLL2 powered down. So there seems to be something else off there. 

    Can we have them run this test, start with mode 1, only write R71[0] to power down PLL2, confirm there is no disturbance on outputs from PLL1 and outputs from PLL2 now don't show a clock. Then write R71[0] again and confirm PLL2 comes back on with no issues. 

    If this works as expected then new "normal" configuration can be created from mode 1 just by power down of PLL2 and updating the output mux selection on those 3 outputs to PLL1. That's the new "normal" image or beginning configuration. And to go to mode 1, only those 4 registers need to be updated. 

    Thanks and regards, Amin 

  • hi Amin,

    Customer found that the PLL1 lost lock at setting R50.

    for example, set R50 from 0x9f to 0x9f or 0x9f to 0x9b or 0x9b to 0x9f.

    do you know why and what's correct setting flow to avoid this?

    BR,

    frank

     

  • Hi Frank,

    1, Double check SECREF settings.

    If a 27 MHz XTAL is adopted, no necessary to check TERMs bits.

    2, If rewriting R50 still make unlock happen, it may be caused by Reference detector circuits.

    The circuits need some time to verify the reference valid.

    Disable Ref Detector, or do not rewrite the R50.