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: Single loop mode - PLL2 doesn't lock

Part Number: LMK04828

Hi,

I'm trying to use an LMK04828 in single loop mode to generate a 1GHz system clock from a 100MHz OCXO. Input to OSCin is 100MHz sine at 1.5Vpp. PLL2 is configured with R=1 and N=30 (/2 in prescaler and /15 in main divider). I've selected VCO1 which should lock at 3GHz, which is then divided down to 1GHz and some other frequencies in the output dividers. I have the loop filter as follows

  • R2 = 560R external
  • R3 = R4 = 200R internal
  • C1 = 68pF external
  • C2 = 4.7nF external
  • C3 = C4 = 10pF internal

Clock Design Tool tells me this should give a loop bandwidth of 191kHz and phase margin of 68.7 degrees. My own simulations of the block diagram in SPICE give almost the exact same numbers.

Problem is the PLL refuses to lock. DLD output stays low, and the voltage on CP2OUT is a ~0.36V ramp waveform at 1.2MHz sitting just below the 3.3V rail.

I tried putting the PLL2_R and PLL2_N signals on Status_LD1 pin. PLL2_R is a clean 100MHz square as expected. PLL2_N is at 101.2MHz, which given the /30 ratio would put VCO1 at 3036MHz. Using an FFT you can clearly see the sidebands from the 1.2MHz modulation. This isn't present on PLL2_R, that's dead clean.

This looks like loop instability but I don't understand why given that CDT says I have plenty of phase margin. I've checked that PLL2 is set for negative slope (PLL2_CP_POL=0) and OSCin_FREQ=1 for 100MHz input.

I also noticed I get nothing on any of the DCLKx and SDCLKx outputs even though they should be enabled. I don't see anything in the datasheet that says these are disabled until the PLL locks. Is this normal or could it point to some bigger problem?

Thanks,

Tom

  • Hi Tom,

    Thanks for checking the PLL2 R and N /2 signals on the Status pin.  I have a feeling it is not loop filter related.  Rarely have I seen it cause a problem in locking.
      - Have you confirmed proper supply voltage on all Vcc pins?

    Is this a new design?  More than one board has a problem?

    It's probably worth posting the exact programming you are using...  did you use TICS Pro to generate the programming?

    Please ensure OSCin_FREQ=1 is set properly (or 2, or 4 is acceptable too).  This is R0x162[4:2].  It's come to my attention recently you may need to look at this in the raw register as TICS Pro may not expose this.

    73,
    Timothy

  • Hi Timothy,

    All Vcc pins measure in the range 3.265-3.290V so within spec. Ripple on all pins is under 100mVpp, well below this in most cases.

    This is a new rev of an existing design. The previous rev used the '828 in divider-only mode with a 1GHz clock direct to CLKin1. We never had any issues with that design. This version replaces the 1GHz OCXO with a 100MHz unit, hence the PLL. Unfortunately I only have the 1 prototype card available to test right now.

    The config was made by manually editing the existing settings from the previous rev. Not sure how the original one was made, that was before I started here. I've attached part of the code that programs the '828. The array contents show the registers in the order they're written, including registers written multiple times as part of the JESD204B SYNC setup. Tbh I'm not really sure why some of the registers are written in the order they are but I don't think it should affect the PLL.

    I've checked register 0x162 = 0x44 which sets OSCIN_FREQ to 1.

    Thanks,

    Tom

    const UNSIGNED16 CClkDistLMK04828::m_u16RegArray[CLK_DIST_LMK04828_REG_ARRAY_LENGTH] = {
        0x000, 0x002, 0x100, 0x101, 0x103, 0x104, 0x105, 0x106, 0x107, 0x108, 0x109, 0x10B,
        0x10C, 0x10D, 0x10E, 0x10F, 0x110, 0x111, 0x113, 0x114, 0x115, 0x116, 0x117, 0x118,
        0x119, 0x11B, 0x11C, 0x11D, 0x11E, 0x11F, 0x120, 0x121, 0x123, 0x124, 0x125, 0x126,
        0x127, 0x128, 0x129, 0x12B, 0x12C, 0x12D, 0x12E, 0x12F, 0x130, 0x131, 0x133, 0x134,
        0x135, 0x136, 0x137, 0x138, 0x139, 0x13A, 0x13B, 0x13C, 0x13D, 0x13E, 0x13F, 0x140,
        0x141, 0x142, 0x143, 0x144, 0x145, 0x146, 0x147, 0x148, 0x149, 0x14A, 0x14B, 0x14C,
        0x14D, 0x14E, 0x14F, 0x150, 0x151, 0x152, 0x153, 0x154, 0x155, 0x156, 0x157, 0x158,
        0x159, 0x15A, 0x15B, 0x15C, 0x15D, 0x15E, 0x15F, 0x160, 0x161, 0x162, 0x163, 0x164,
        0x165, 0X171, 0X172, 0X17c, 0X17d, 0x166, 0x167, 0x168, 0x169, 0x16A, 0x16B, 0x16C,
        0x16D, 0x16E, 0x171, 0x172, 0x173, 0x17C, 0x17D, 0x139, 0x143, 0x140, 0x144, 0x143,
        0x143, 0x143, 0x144, 0x139};
    
    const UNSIGNED8 CClkDistLMK04828::m_u8DataArray[CLK_DIST_LMK04828_REG_ARRAY_LENGTH] = {
        0x10,  0x00,  0x6C,  0x55,  0x01,  0x20,  0x00,  0xF0,  0x11,  0x63,  0x55,  0x01,
        0x20,  0x00,  0xF0,  0x66,  0x63,  0x55,  0x01,  0x20,  0x00,  0xF0,  0x66,  0x63,
        0x55,  0x01,  0x00,  0x00,  0xF1,  0x06,  0x08,  0x55,  0x00,  0x00,  0x00,  0xF9,
        0x01,  0x08,  0x55,  0x00,  0x00,  0x00,  0xF9,  0x01,  0x78,  0x55,  0x01,  0x00,
        0x00,  0xF1,  0x01,  0x20,  0x03,  0x03,  0x00,  0x00,  0x08,  0x03,  0x00,  0x00,
        0x00,  0x00,  0x11,  0xFF,  0x7F,  0x00,  0x1F,  0x02,  0x42,  0x02,  0x16,  0x00,
        0x00,  0x00,  0x7F,  0x03,  0x02,  0x00,  0x00,  0x78,  0x00,  0x7D,  0x00,  0x96,
        0x06,  0x00,  0xD4,  0x20,  0x00,  0x00,  0x13,  0x00,  0x01,  0x44,  0x00,  0x00,
        0x0C,  0xAA,  0x02,  0x15,  0x33,  0x00,  0x00,  0x0F,  0x59,  0x20,  0x00,  0x00,
        0x00,  0x3B,  0xAA,  0x02,  0x00,  0x15,  0x33,  0x00,  0x11,  0x00,  0x30,  0x11,
        0x31,  0x11,  0xFF,  0x03};

  • Hello Tom,

    Thanks for sharing the config.  In general it looks like it should work.

    Lets try this.  Please update reg 0x165 = 0x0f (was 0x0c).  This will result in PLL2_N_CAL = 15 instead of current 12 value.  Datasheet says this is only used for 0-delay mode, however I want to eliminate this as a possible issue.  I note the default EVM config has the same PLL_N ans PLL2_N_CAL.  If this doesn't solve the problem, I'll try locking a board with your config and debug.

    Note, you could also power down PLL1, reg 0x140 = 0x80.

    73,
    Timothy

  • Hi Timothy,

    After some more digging it turned out that a firmware issue was preventing the '828 from being programmed how we thought it was. The image I posted now actually works fine. Sorry for wasting your time with this.

    Thanks,

    Tom

  • Glad you got to root cause Tom.  Let us know in case if any other support need.

    Also, please be aware of our new on-line tool for solving clock tree, Clock Tree Architect.

    73,
    Timothy