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.

LMK04826: Reference input selection of PLL1

Guru 11160 points
Part Number: LMK04826

Hello,

My customer used the LMK04826 with CLKin1 manual setting of CLKin_SEL_MODE as below.

   - 0x014618, 0x01471A, 0x014813, 0x014913

The symptome that the reference input of PLL1 intermittently changes from CLK1 to CLK2 occurs.

Is there any case where the reference input is automatically changed even though the CLK1 manual is set?
Regards,
JH
  • Hi JH,

    My coworker will get back to you tomorrow.

    Regards,
    Hao

  • Hello JH,

    With the settings described above, it should not be possible for the LMK04826 to perform any reference switching. Setting the CLKin_SEL_MODE to CLKin1 manual should always select CLKin1.

    If CLKin1 is removed from the system or left floating, but CLKin0 is supplied, it is possible for a small amount of CLKin0 signal to couple to the CLKin1 traces or through VCC6_PLL1 supply line, which could appear as though the device is switching to CLKin0. Are they removing CLKin1 and leaving it floating? Is the CLKin1 connection intermittent?

    Regards,

  • Hi Derek,

    Thank you for your reply.

    I will check if there is a interruptions in CLKin1.

    When an error occurs in the LMK04826 and checks the registers, 0x147 is 0x1A, but 0x184 is 0xA0(normal 0x90). Is it possible ?

    Which case should we check further ?

    Thanks a lot.

    Regards,

    JH

  • Hi JH,

    The readback clock selection suggests that somehow the device is explicitly selecting CLKin2 (not a coupling phenomenon) - despite the manual register programming it otherwise. This should not be possible during normal operation - datasheet section 9.3.5.1 explicitly rules out the possibility of the clock switching when in manual mode, even when exiting holdover.

    Is this behavior seen on multiple devices, or just one? This may be a one-off defect.

    Regards,

  • Hi Derek,

    This issue is occurred on field and is reported on several sites. therefore, the customer thinks it is not a one-off defect.

    Please let me know if you need any data to estimate the cause.

    Regards,

    JH

  • Hi JH,

    Can I please get the full register programming, including the sequence they use to program the device along with hardware reset intervals (if any)?

    Regards,

  • Hi Derek,

    I attached the full register file

    The program sequence is as follows.

     1) The reset pin is not used and is set as an output type(push-pull).

     2) Write registers using lmk04826.dat file

     3) Write 0x01ff83

     4) Write 0x013800, 0x01471A

     5) Write 0x015604, 0x015A04

    Regards,

    JH

    lmk04826.dat

  • Hi JH,

    Thanks for the register file and the programming sequence. I'm somewhat confused because 0x01FF is not a valid address for the LMK04826 - I am assuming this is the lock state register 0x1FFF, written to decimal value 83. But please confirm as writing to unknown addresses could produce strange behavior.

    One thing of note: the default POR value for CLKin_SEL_MODE sets pin-select mode. Depending on the state of the I/O connected to CLKin0_SEL and CLKin1_SEL when the CLKin_SEL_MODE state machine transitions from pin-select mode to manual-specified mode, there may be a transition glitch causing the state to become "stuck" in the pin-select state. I have not been able to reproduce the issue in our lab so far, so this is speculation. But perhaps changing the function of CLKin1_SEL I/O to an input, or returning the CLKin_SEL_MODE pin to pin-select mode, while in the glitched state, could force the state machine back into a deterministic state. Additionally, they could try only writing to 0x0147 after all other registers have been written, and with some delay (e.g. 100µs) between writing other registers.

    In any case, the clock selection state machine can be completely powered down by setting the CLKin_OVERRIDE bit (R336[6]=1). CLKin_SEL_MODE should still behave normally in manual selection or pin-selection modes, since these modes do not use the state machine - they are only blocked by it. What happens when the device is in the glitched state, and the CLKin_OVERRIDE bit is set? Does this restore the selected clock to the expected value?

    Please advise the customer to try the proposals above.

    Regards,

  • Hi JH,

    Any update on this issue?

    Regards,

  • Hi Derek,

    The customer is still seeing the issue in the field.

    Please keep this case until early next week.

    Thank you for your patience.

    Regards,

    JH

  • Hi Derek,

    When the customer encountered the ref input error of the LMK04826 and setting CLKin_OVERRIDE returned the device's reference input to CLKin1.

    Could you estimate the root cause of the issue ?

    Thanks a lot.

    Regards,

    JH

  • Hi JH,

    As I mentioned before, I think this is the clock input selection state machine getting stuck before it has a chance to perform the clock switch. I'm not 100% sure why it would be getting stuck. My theories are:

    • Power supply glitch on PLL1, either during programming when the PLL supply pin currents change suddenly due to register changes, or during operation for other reasons like external noise, causing the state machine to reset to default values. Registers would remain programmed since register supplies are on the digital supply, but the systems reading from those registers may be in their reset state or an unknown state and unable to progress without a signal that only arrives on startup. This seems the most likely explanation between my two theories.
    • OSCin and CLKins are not supplied, or VCO is powered down, when CLKin_SEL_MODE is written, so the switching state machine has no clock when the state is supposed to transition away from reset state. It never completes its initialization sequence properly during startup, and is stuck in an unknown state. I am less confident about this possibility, since I believe there is an always-on clock which is not tied to OSCin, CLKinX, or the clock distribution path.

    In either case, CLKin_OVERRIDE powers down the state machine asynchronously, so if the state machine was stuck in a state where it could not properly transition manual control, powering it down forces manual mode behavior. Perhaps slowing down the SPI bus clock could also spread out the increase in current consumption when initially programming the device, avoiding any power glitches.

    Regards,