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.

LMK61E2: Questions for LMK61E2BBA-SIAR no clock output failure, urgent!

Part Number: LMK61E2

Hi Team,

Customer is using our LMK61E2BBA-SIAR in their design, but facing high failure for no clock output issue now after some times running for their machine. We verified the failure IC on our EVM, and it shows the same behavior without any clock output. Below we captured the output waveform and registers dump compared with good units, please help to check what's the problem in here. Please help to check as your earlier as possiable, as this issue is blocking customer's mass production now. Thanks.

Good unit output clock waveform and register dump:

LMK61E2_Good_Default Register Map Dump 2_5-31-2023.txt
R0	0x0010
R1	0x010B
R2	0x0233
R8	0x08B4
R9	0x0900
R16	0x1000
R17	0x1180
R21	0x1502
R22	0x1600
R23	0x172E
R25	0x1900
R26	0x1A2E
R27	0x1B00
R28	0x1C00
R29	0x1D00
R30	0x1E00
R31	0x1F00
R32	0x2001
R33	0x210C
R34	0x2228
R35	0x2303
R36	0x2404
R37	0x2500
R38	0x2600
R39	0x2700
R47	0x2F28
R48	0x3003
R49	0x3110
R50	0x3228
R51	0x3300
R52	0x3405
R53	0x35FF
R56	0x3800
R72	0x4800

Bad unit output waveform and registers dump:

LMK61E2_Failure_Configured Register Map Dump 4_5-31-2023.txt
R0	0x0010
R1	0x010B
R2	0x0233
R8	0x0804
R9	0x0900
R16	0x1000
R17	0x1180
R21	0x1502
R22	0x1601
R23	0x17CC
R25	0x1900
R26	0x1A2E
R27	0x1B00
R28	0x1C00
R29	0x1D00
R30	0x1E00
R31	0x1F00
R32	0x2001
R33	0x210C
R34	0x2228
R35	0x2303
R36	0x2404
R37	0x2500
R38	0x2600
R39	0x2700
R47	0x2F1D
R48	0x3005
R49	0x3110
R50	0x321D
R51	0x3300
R52	0x3400
R53	0x35FF
R56	0x3800
R72	0x4800

Customer design files for your double check if any issues:

61E2.rar

  • Hi Jacky,

    Thanks for the detailed information. I compared the two register dumps and here are the important differences:

    • Slave address in good device is 0x5A, in bad device is 0x02.
      • If this was done for debugging purposes then you can leave it alone for now.
    • R22 and R23 (OUTDIV_BY1 and OUTDIV_BY0): overall output divider value of good device is 46, for bad device it is 460
      • Very large difference, bad device would be expected to produce 10 MHz output instead of 100 MHz. 10 MHz is the minimum output frequency according to the datasheet, not clear to me if that is an inclusive or exclusive lower bound.
    • R48 (NVMCNT) in good device is 3, in bad device is 5

    So it looks to me that the bad device was programmed more times than the good device and it has both a different slave address and an incorrect output divider value. Maybe the bad device was programmed incorrectly or someone programmed it again by accident. It is possible that the device cannot output a frequency of exactly 10 MHz and no waveform would be generated.

    You may try the following corrections to the bad device:

    • Set value of R22 to 0x00
    • Set value of R23 to 0x2E

    Let us know if it can then produce a 100 MHz output as expected.

    Best,

    Evan Su

  • Hi Evan,

    Please ignore the output frequency settings as we tried to change to 10MHz in GUI default setting. And even we set to 100MHz or 10MHz settings, there is still no waveform output as above captured.

    Please help to check if there is any other clues for this failure, it looks like there is some thing wrong in clock output buffer stage, but we do the FA initial test, no abnormal observed.

  • Hi Jacky,

    Thanks for the information. I did not see any issues in the schematic, the output LVDS termination looks correct and the OE pin is pulled high. I would like to ask some questions to understand the situation better:

    We verified the failure IC on our EVM, and it shows the same behavior without any clock output.

    Did you physically transfer a bad device from the customer board to the EVM? The EVM should have a correct board design so if the bad device continues to fail while installed on the EVM, then the issue should be related to the specific device.

    Please help to check if there is any other clues for this failure, it looks like there is some thing wrong in clock output buffer stage, but we do the FA initial test, no abnormal observed.

    Since the registers look OK so far it is possible that there is something wrong with the output driver or that there is a problem deep inside of the register map:

    • Have multiple units failed in the same way?
    • Has the customer accessed or configured any registers that are not exposed in TICS Pro? There are some registers in the datasheet but hidden in TICS Pro that can cause problems.

    Best,

    Evan Su

  • Hi Evan,

    Please refer to below my comments:

    I would like to ask some questions to understand the situation better:

    We verified the failure IC on our EVM, and it shows the same behavior without any clock output.

    Did you physically transfer a bad device from the customer board to the EVM? The EVM should have a correct board design so if the bad device continues to fail while installed on the EVM, then the issue should be related to the specific device.

    [Jacky] Yes, we simply solder customer's failure IC return to our EVM to verify its function, it has no normal output as well.

    Please help to check if there is any other clues for this failure, it looks like there is some thing wrong in clock output buffer stage, but we do the FA initial test, no abnormal observed.

    Since the registers look OK so far it is possible that there is something wrong with the output driver or that there is a problem deep inside of the register map:

    • Have multiple units failed in the same way? [Jacky] Yes, so far customer reported 4pcs failure out of 50pcs pilot running.
    • Has the customer accessed or configured any registers that are not exposed in TICS Pro? There are some registers in the datasheet but hidden in TICS Pro that can cause problems. [Jacky] Customer only configured the registers listed in datasheet, but I will double check with them.

    Thanks.

  • Hi Evan,

    We have another finding, that for the failure device, the R66 register read back value is 0xCA, which shows Loss of Lock PLL error. Below is customer's full configuration table and code, please help to double check if any issues to trigger this error:

  • Hi Jacky,

    Thanks for the register information, I will review it and get back to you as soon as possible.

    Best,

    Evan Su

  • Hi Evan,

    Add another question, we found when we get one fresh new LMK61E2BBA IC, and just only read R48 register without any writing, it shows 0x01 rather than 0x00 by default. Can you help to check if this is normal or not? Do we have one time factory EEPROM writing by default?

    Thanks.

  • Hi Jacky,

    I looked through the 120 MHz configuration and did not see any problems that could cause a loss of lock. I will discuss this more with my team.

    Out of curiosity, can you ask the customer to read back (do not write) the following registers on the failure device?

    • R10 (DEV_CTL)
    • R42 (PLL_CALCTRL)
    Can you help to check if this is normal or not? Do we have one time factory EEPROM writing by default?

    I will ask about this. I would not be surprised if the device needs to be programmed one time after manufacturing to achieve the LMK61E2 default configuration.

    Thanks,

    Evan Su

  • Hi Evan,

    Please refer to below register value(powering up IC, read only without any writing and configuration), and check if any issues:

    •    R10 (DEV_CTL) - 0x00
    •    R42 (PLL_CALCTRL) - 0x00

    Thanks.

  •  Hi Jacky,

    Those readbacks do not sound right. Based on some experiments I did months ago, the correct value for R10 should be 0x01 (autostart on) and the correct value for R42 should be 0x09 (standard VCO calibration settings). However they are hidden in TICS Pro and I did not see them accessed in the code so it does not make sense for them to be modified. The hex address for R10 is 0x0A and the hex address for R42 is 0x2A in case I was not clear enough; if the customer has time they may check the readback again on the failure device and then check the readback on the good device. 

    However I saw an email this morning about ATE testing, if there are potential hardware issues then the process should be followed for investigating that as first priority. I do not have much experience with the return/FA process, if we are moving past configuration issues then I think we should close out this thread soon. Let me know how things go.

    Best,

    Evan Su

  • Hi Evan,

    The register R10(0x0A) and R42(0x2A) value back no problem for he failure device, which they are all 0x00. We also check the good units, it matched the value you mentioned. So for the failure device, there must be something wrong or issues inside and we do not the root cause how they are failed. As you also checked customer's initialization register settings and no issues, next step we will focus on ATE test result and further FA result. But as we still need to figure out the root cause for the failure, we will communicate in offline by email.

    Thanks for the support.

  • Hi Jacky,

    Thanks for the update. I will close this thread since the issue has been moved to email, if there are new action items for Applications to support, I am happy to help.

    Best,

    Evan Su