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

LMK05028: APLL freeze when input reference out of pull-in range

PHI TU
Prodigy 240 points
Part Number: LMK05028

Hello,

I using LMK05028 as jitter-cleaner in CPRI application as figure below and .tcs file.

Normal operation: Plug the CPRI cable at power on. CDR frequency is 15.36MHz, the DPLL2 of LMK05028 lock 

Then un-plug the CPRI cable then CDR frequency drop to 15MHz (no data to recovery)

Then plug the CPRI cable the CDR frequency come back to 15.36MHz but DPLL2 freeze, not lock. I read the PLL2_status_NUM it all un-change. It seem when input reference out of pull-in range of DPLL (about 2000ppm calculate from PLL2_status_NUM read back when PLL2 freeze) the PLL freeze and can't recover.

What would you suggest to solve the problem? so PLL can auto recover.

LMK05028_CPRI.tcs

 

  • 0
    TI__Expert 6140 points

    Hi Phi, 

    Did you perform a status readback both after CPRI cable was removed and then brought back? My expectation for it would be that when it is removed and therefore we have no reference (CDR producing 15 MHz) we should enter holdover mode with LOPL flag. Once comes back it should re-lock but since it isn't and it's "freezing" as you put it, I would like to know what does the status readback tell us. 

    • Is the input valid
    • Has the DPLL selected the input 
    • What is DPLL R div and N div show if probed on the status channel, is it moving to try to achieve lock or just frozen 

    Secondly, please enable missing clock feature (missing and runt pulse) so that the reference can be quickly invalidated when it drops out. Otherwise DPLL may try to track and then rail (since this is very large offset) which might make it harder to recover. This feature is on the main start tab and does not require a runscript to be calculated, as soon as you enable the bit it will correct program the needed registers. 

    Thanks and regards,

    Amin

  • 0 in reply to Amin Eshraghi
    Prodigy 240 points

    Hi Amin

    When CPRI come back:

    • Yes, the input valid
    • The DPLL selected the input
    • PLL2_NUM_STAT  just frozen: R145, R146, R147, R148, R149 

    I enabled the PPM monitor, the missing clock and Early clock detector so when input clock drop DPLL change to Holdover and when input comeback DPLL can recover.

    I just want to test the abnormal when the input clock fall too fast and input monitor don't disqualify fast enough then DPLL can be "freeze" hard to recover.

    I try some config on the user control tab. By un tick the DPLL2_REF_AVOID_SLIP or increase the REF Cycle_Slip_OFFset to like 50000. The DPLL can easy recover even when i force it lock to input clock like 15MHz then comeback to 15.36MHz.

    Can you give me more information about Cycle slip setting. Does it effect to phase noise performed  or lock time of DPLL.

    Thanks and regards,

    Phi Tu

  • 0 in reply to PHI TU
    TI__Expert 6140 points

    Hi Phi, 

    The missing clock monitor is fully there for this purpose. It is the fastest detection and should invalidate the reference and not therefore stop the DPLL tracking. You're holdover history is also large enough where it switches to a holdover mode frequency from the history gathered when device was locked to reference. 

    PPM detector is slower, but a lot more precise. It would allow the user to determine how far would they want the DPLL to track the reference exactly and at what point do they want system to switch to holdover mode. 

    If reference doesn't get disqualified fast enough, DPLL may have tracked for too long and then take much longer time re-locking when reference comes back. I believe this is what you were observing when the DPLL "freeze" was occurring. My assumption would be it would eventually lock but it would take very long time. 

    I'm not sure I understand the "abnormal" comment, again we recommend missing clock monitor to always be enabled. And from what I'm reading above it seems like when it's enabled, system has no issues. 

    DPLL_REF_AVOID_SLIP can be enabled. I would assume TICSPRO config comes out with it enabled. Did you manually change it? It will not have any impact on phase noise performance, it may have some slight impact on lock time. It doesn't hurt to have it enabled. 

    REF_Cycle_Slip_Offset should not be manually programmed. This is a function of VCO / TDC / Ref input. Again this is part of runscript and these calculations are run for you, so please don't change them. 

    Thanks and regards,

    Amin 

  • 0 in reply to Amin Eshraghi
    Prodigy 240 points

    Hello Amin,

    thanks for reply

    Now the system works as expected!

    Regards,