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

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:

Jacky Wang(QD) said:

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 Wang(QD) said:

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:

Jacky Wang(QD) said:

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.

Jacky Wang(QD) said:

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)

Jacky Wang(QD) said:

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.