LMX2572LP: Unlock Problem After a While

Hi Gunduz,

Could you share your register configuration?

Dear Noel,

Thanks for your return. 

Firstly, We programmed the LMX2572LP with the following register configuration. and we did not observe any problems. 

R125 R:0x0820
R124 R:0x0000
R115 R:0x0048
R114 R:0x7C03
R078 R:0x00A3
R075 R:0x09C0
R071 R:0x0081
R070 R:0xC350
R069 R:0x0000
R062 R:0xFCAF
R060 R:0x01E0
R059 R:0x0001
R058 R:0x8001
R057 R:0x0020
R052 R:0x0421
R046 R:0x07F0
R045 R:0xC607
R044 R:0x0D63
R043 R:0x0000
R042 R:0x0000
R041 R:0x0000
R040 R:0x0000
R039 R:0xFFFF
R038 R:0xFFFF
R037 R:0x0505
R036 R:0x0084
R034 R:0x0010
R030 R:0x0CA6
R029 R:0x0000
R020 R:0x4848
R019 R:0x2700
R017 R:0x008A
R016 R:0x0000
R014 R:0x1870
R012 R:0x5001
R011 R:0xB018
R010 R:0x10F8
R009 R:0x0004
R008 R:0x2000
R007 R:0x00B2
R006 R:0x1002
R005 R:0x30C8
R001 R:0x0808
R000 R:0x2098

Then, from time to time we programmed the LMX2572LP with the following configuration. After a few programming we saw that the problem as we mentioned earlier occurred.

R125: R:0x0820
R124: R:0x0000
R115: R:0x0048
R114: R:0x7C03
R078: R:0x00A3
R075: R:0x09C0
R071: R:0x0081
R070: R:0xC350
R069: R:0x0000
R062: R:0xFCAF
R060: R:0x01E0
R059: R:0x0001
R058: R:0x8001
R057: R:0x0020
R052: R:0x0421
R046: R:0x07F0
R045: R:0xC607
R044: R:0x0D63
R043: R:0x0000
R042: R:0x0000
R041: R:0x0000
R040: R:0x0000
R039: R:0xFFFF
R038: R:0xFFFF
R037: R:0x0505
R036: R:0x0084
R034: R:0x0010
R030: R:0x0CA6
R029: R:0x0000
R020: R:0x4848
R019: R:0x2700
R017: R:0x008A
R016: R:0x0000
R014: R:0x1870
R012: R:0x5001
R011: R:0xB018
R010: R:0x10F8
R009: R:0x0004
R008: R:0x2000
R007: R:0x00B2
R006: R:0x1002
R005: R:0x30C8
R001: R:0x0808

Meanwhile, we reset the chip and used same register configuration. We did not observe any problem after reset. 

We hope, you have some idea about this unexpected behavior. 

Thanks in advance.

Gündüz 

Hi Gunduz,

The second register maps is identical to the the first register maps except that R0 was not in the second register maps, is this true?

The problem with the first register maps is the PFD_DLY_SEL value is not correct, it should be 3 instead of 5. This register bits will affect phase noise, in some cases, a wrong value may lead to unlock. 

After initial programming is done, if you want to change the VCO frequency, you only need to program those related register bits, and then program R0 to trigger the change (since you have all the double buffer bits enabled) and to trigger a VCO calibration. You don't need to program all registers.

Dear Noel,

Many thanks for your answer.

After your warning, we checked our software. As you said this identical register map is used for the programming. We program only frequency related registers at regular intervals. However, we saw the unlock signal after a while. 

We changed our PFD_DLY_SEL value 3 instead of 5 but unfortunately, we saw the same problem once again. 

In our opinion, Reset is an key point in this problem. Because, after seeing the problem, when we reset the chip and programmed it with the same register map, the problem was solved. Have you any ideas on a how a reset will fix the problem? 

Thanks,

Gündüz

Hi Gozkul,

When you see the problem, if you (1) program all the registers without a reset or (2) program R0 once, will that also fix the problem?

Hi Noel,

Thanks for suggestions but unfortunately we couldn't get any positive development. We tried both your (1) and (2) advices but problem still continues. Only Reset solved our unlock problem. Could it be that the chip is going to into interesting state when it's constantly programmed? 

Thanks in advance.

Gündüz 

Hi Gunduz,

I am not sure what is causing the problem, your observation seems like this is a logic issue but it was locked before failure happen, this seems to be contradict with the suspicion.

Is the problem repeatable? For example, if you switch from f1 to f2 and then f2 will unlock after a while, could you measure the following voltages?

BTW, did you follow datasheet suggestion on the shunt capacitors at pin 3, 27 and 38?

Dear Noel,

Thanks for your suggestions. 

Yes, we connected the suggested capacitor at pin 3, 27, 38. 

You can see the measurement of the voltages. Also, problem is repeatable. We setup the LMX2572LP to f1 RX frequency and then we send the TX f2 data time to time. After a while we come across this unlock problem.  

Also, we left the unused SYNC, RampClk, RampDir and Sysrefreq pins open. Should we grounded them? Would it cause such a problem if we left it open? 

Thanks a lot.

Gündüz

Hi Gunduz,

leaving the SYNC, Rampxxx and Sysrefreq pin floating is ok, my preference is connecting them to ground. Anyway, no matter how do we connect these pin to, they will not affect the PLL. 

It is odd that pin 3 voltage dropped to 0.2V after several lock, how many LMX2572LP has this problem?

Could you change LD_TYPE to 0x0? This will put the MUXout pin to indicate "VCO calibration done". I want to know if the calibration was successful when unlock. 

Sorry to ask again, make sure you are using the bypass capacitors as shown below.

Dear Noel,

Thanks for your quick answer. We have observed this problem on many devices.

We will change the LD_TYPE to 0x0 but what is your suggestion about LD_DLY value? Our Phase Detector Frequency is 48 MHz. Should LD_DLY be 48000000 / 4 = 12 000 000? 

Also, previously, we were using 10uF capacitors on Pin 3, 27, 38. After your suggestion we have changed them as datasheet recommendation. (Pin 3 => 470nF, Pin 27 => 100 nF, Pin 38 => 10 nF). But, as you remembered problem is not solved. Could it be that, we didn't see the effect because we made this capacitor change later? To be sure, we will try again with new LMX2572LP.

Thanks in advance. 

Gündüz

Hi Gunduz,

LD_DLY is not matter, you can put 0. 

Datasheet suggested capacitor values will ensure the internal LDOs will response faster, this will help ensuing the VCO calibration will get started at the correct reference voltages. In your use case, since you are switching the frequency frequently, faster LDO response time should help eliminating VCO calibration failure. That's why I want the chip to tell me if calibration is successful from the MUXout pin.

Dear Noel,

We replaced the LMX2572LP with the new one and we used suggested capacitor values. Also, we changed LD_TYPE to 0x0. Unfortunately, problem continues. Additionally, we made a new observation about this problem:

As you know we programming the LMX2572LP to single RX frequency, and time to time we are sending TX frequency data to the chip. This process continues constantly and after 15-20 minutes problem occurs. Now, we programmed the LMX2572 to several RX frequency, and then sent the TX frequency data. Now, at this time, problem did not occur. We know, this is an interesting observation and made the problem even weirder :) Do you have any opinion on this? 

Thanks in advance.

Gündüz

Hi Gunduz,

Do you mind telling us what are the RX and TX frequencies? Just want to see if QUICK_RECAL_EN or forcing VCO_SEL to a certain value help.

Dear Noel,

Our RX frequency is 163 MHz, and TX Frequency is 153 MHz. 

Due to these two frequencies are close to each other, we tried QUICK_RECAL_EN before. Unfortunately, this did not solve us problem. 

Thanks.

Gündüz

Hi Gunduz,

RX: 163MHz --> VCO: 5216MHz --> VCO5 (may be VCO4 is also possible)

TX: 153MHz --> VCO: 4896MHz --> VCO4

Let do some tests to debug if this is VCO calibration problem.

1. program the device to lock to RX, then do a register read back to see which VCO is selected (R110, rb_VCO_SEL).

2. switching to TX frequency, again read back the selected VCO. 

3. switching to other TX frequencies, from time to time, as usual until failure happen

4. read back the selected VCO. 

Alternatively, you can assign the corresponding VCO when you program RX and TX frequencies. For example,

1. set R20, VCO_SEL_FORCE = 1

2. set R20, VCO_SEL = 0x5; program the device to lock to RX

3. set VCO_SEL = 0x4; program the device to lock to TX

4. switching to other TX frequencies, as usual. 

Make sure you use the correct VCO_SEL for your frequencies: