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.

LMX2572: Lock time is much longer than excepted

Part Number: LMX2572
Other Parts Discussed in Thread: LMX2594

Hi,

I’m using the LMX2572 for a fast stepped frequency synthesizer from 800 to 6000 MHz with 20 MHz steps. The desired lock time is < 20us in full assist mode. As simulated with PLLatinium the analog lock time should be < 15us (3. order loop filter, bw=200kHz, margin=40°, gamma=1.48).

As measured, the lock time is < 20us on the most frequencies but on certain frequencies > 50us. The screen shots show the phase error at 5160, 5180, and 5200 MHz (SPI_CLK=green, PhaseError=Yellow). The lock time at 5160 and 5200 is ok but 5180 is too long.

Full assist register values used by this test (frequency, vco_sel, vco_capctrl, vco_daciset)
5160 MHz, 4, 24, b4
5180 MHz, 4, 21, b4
5200 MHz, 4, 1d, ae

How to optimize the lock time for all frequencies?

Regards Samuel

  • Samuel,
    Tough question, only a few things I can think of:
    1. For the VCO calibration settings, these should be obtained by locking the device and reading back the settings (not the TICSPro button on the GUI). I say this because if the VCO_DACISET setting is wrong, it could impact the loop bandwidth of the system. In fact, if you have a spectrum anallyzer, you might just lock it to 5180 MHz and ensure the loop bandwidth looks reasonable. You probably did these things already, but if not, maybe worth a try.

    2. For the capacitor on pin 3, see if reducing this helps the 5180 MHz lock time.

    Regards,
    Dean
  • Hi Dean,

    thank you for the fast response

    >> For the VCO calibration settings, these should be obtained by locking the device and reading back the settings

    That's exactly what I did

    >> I say this because if the VCO_DACISET setting is wrong

    The values in the first post are taken by my firmware and hardware. If I do the same with TICS Pro and EVM I get the same value

    1. Load default mode configuration
    2. Change Fosc, Fpd and Charge Pump Gain
    3. Set MUX_LD_SEL to Readback
    4. Set frequency
    5. Read Raw register

    >> In fact, if you have a spectrum anallyzer, you might just lock it to 5180 MHz and ensure the loop bandwidth looks reasonable.

    Loop bandwidth is 200 kHz for all frequencies

    >> For the capacitor on pin 3, see if reducing this helps the 5180 MHz lock time.

    I tested with 1uF and 100nF, no improvement

    After changing the frequency from 5160 to 5180 the frequency error stays constantly at 47 MHz for ~20 us. It seems that the PLL is not working properly. 

    I'm using the following presets

    Any ideas?

  • I found something interesting

    The first pictures shows the voltage (green trace) at the loop filter after changing the frequency from 5160 to 5180 MHz. The loop filter voltage drops to zero! The second shows the loop filter voltage over the entire range from 800 to 6000 MHz. 

  • Samuel,

    I have 2 theories:
    1. Loop filter/Cycle slip related
    Try changing the charge pump current. If it changes this time 20 us later when the tuning voltage goes low, then it points to the loop filter.

    2. Amplitude Calibration Glitch
    Tryy doing this frequency change and NOT change the VCO_DACISET setting. If this resolves the issue, I suspect something from the amplitude settings. This is what was fishing for with the pin 3 capacitor, but it didn't seem to be the right thing, but good to check this way too.

    Regards,
    Dean
  • Morning Dean,

    >> 1. Loop filter/Cycle slip related

    Changing the charge pump current changes the entire lock time but not the length of the glitch

    >> 2. Amplitude Calibration Glitch

    Changing VCO_DACISET doesn't cause the glitch.

    I added a delay between the SPI requests to see which command causes the glich. In that example the PLL_N was changed from 258 to 259

  • Samuel,

    When you change the N divider value from 258 to 259, this will try to drive the VCO frequency higher. As this is a negative tuning coefficient VCO (Kvco is negative), this will drive the Vtune voltage lower. Now although the VCO has a wide tuning range, the specific band designated by VCO_CAPCODE may not be as wide.

    So it looks to me what is happening is that you are telling the VCO to go to a higher frequency, but you have not changed the value for VCO_CAPCODE yet, so it is slamming against the highest frequency that the band you are in can handle, which means slamming back to 0 V tuning voltage.

    So if you were to hypothetically change the VCO_CAPCODE first, then the tuning votlage would rail high until you put the appropriate value of VCO_CAPCODE.

    If this is what is going on, then the way to remedy this might be to ensure that the timing between the changing of the VCO_CAPCODE and PLL_N values was closer together. Hope this helps.

    Regards,
    Dean
  • I send PLL_N and PLL_N[18:16] as the last command but without any improvement

    I sweep the frequency from 800 to 6000 MHz in 20 MHz steps (260 steps in total). The negative glitches happen three times (~1280 MHz, ~2580 MHz and 5180 MHz). There are also some positive glitches but with a shorter time of ~10us. 

    frequency, vco_sel, vco_capctrl, vco_daciset, pll_n, rf_n
    1280, 4, 2a, b2, 256, 4
    2580, 4, 24, b3, 258, 2
    5180, 4, 20, b3, 259, 1

  • Samuel,

    It looks that when you write PLL_N, the PLL loop tries to force the VCO to a higher frequency in the band (because VCO_CAPCTRL has not been changed yet), which in turns drives the tuning votlage to ground. The PLL loop does recover, but it takes on the order of 20 us to do so. This seems to be what you are calling the "glitch".

    Now it is a little perplexing that changing the charge pump current does not impact the length of the glitch, unless this glitch is related to the counters. If it is counter related, it would be impacted by the phase detector frequency. We don't have a counter reset, so the only thing I can think of is to write faster so that the PLL can't react so much, or tri-state the charge pump to prevent this glitch.

    Regards,
    Dean
  • Hi Dean

    >> Now it is a little perplexing that changing the charge pump current does not impact the length of the glitch, unless this glitch is related to the counters

    I have taken some measurement with different CPG settings (see pictures at the end). The pictures show the voltage at the loop filter. The length of the glich doesn't change with CPG. Normally the lock time is around 20us the glicht adds a additional delay of 20us. For my application the lock time mustn't be grater than 20 us.

    >> We don't have a counter reset, so the only thing I can think of is to write faster so that the PLL can't react so much

    On the measurements above I wrote all register values within 5us.

    >> or tri-state the charge pump to prevent this glitch

    I write 0x0E1800 as the first command and 0x0E1878 as the last but it doesn't help. 

  • Samuel,

    I tried to replicate this, but my setup is limited in programming the EVM and I was not able to replicate this. Specifically, TICSPro is painfully slow, and the only word generator we have is likely as as old as I am (OK maybe not that old) and I don't know how to use it.

    So the best I could think of was to lock at 5160 MHz and switch to 5180 MHz by only changing the N divider value and not the VCO calibration settings. In this case, I saw no glitch. Now this does not include the VCO calibration settings, so my thought is perhaps one of the settings of VCO_DACISET or VCO_CAPCTRL is doing this. But also I see the divider might be changing. For instance , when you write 5160, is this really 2580 MHz output frequency and changing the divider.

    In your setup, have you tried this by setting up everything as it would be for 5180 MHz and using only the PLL_N divide value to change frequency?

    Regards,
    Dean
  • Hi Dean,

    >> so my thought is perhaps one of the settings of VCO_DACISET or VCO_CAPCTRL is doing this

    For me it looks like the PLL_N causes this glitch. See picture from Oct 1, 2018 the voltage drops to zero immediately after setting the PLL_N. In the measurement from Oct 2, 2018 I changed the order of the commands but the glicht still happens at PLL_N (PLL_N is the second last command, VCO_DACISET and VCO_CAPCTRL were set correctly before PLL_N). The length of this glich doesn't change with CPG or with the timing of the SPI. It always adds a delay of 20us. This issue only happens at certain frequencies ~1280 MHz, ~2580 MHz and 5180 MHz.

    >> In your setup, have you tried this by setting up everything as it would be for 5180 MHz and using only the PLL_N divide value to change frequency

    The measurement below were taken with a additional delay between the SPI commands (yellow trace: SPI clk, green trace: loop filter voltage)

    1. Picture: Frequency was changed from 5140 MHz to 5160 MHz.The voltage drops after changing PLL_N but not to zero. The voltage recovers immediately after VCO_CAPCTRL is set correctly. If you lock the picture from  Oct 1, 2018 (frequency was changed from 5160 MHz to 5180 MHz)  there is a drop to zero. After 20 us the voltage goes up tho 1 Volt affter VCO_CAPCTRL to 1.4 Volt.

    2. Picture: Frequency was changed from 5160 MHz to 5180 MHz. On that measurement only PLL_N was changed and the voltage drops to zero

    3. Picture: Repeated frequency change 5180 MHz to 5180 MHz. PLL_N was written with the previous value, PLL stays locked

    4. Picture: Frequency was changed from 5180 MHz to 5200 MHz. Behavior is as expected

  • Hi Dean,

    I connected a LMX2572 EVM to my FPGA board to exclude any problems with my synthesizer board. The FPGA sweeps from 800 to 6000 MHz in 20 MHz steps within 14 milliseconds. I connected the oscilloscope at C4_LF (loop filter voltage). I see the same spikes at the same frequency, see picture.


    Either there is something wrong in the initialization (modified the default preset from LMX2572) or the chip is not working properly. Can you please have a look to the initialization (registers below)?

    0x7D1F7C
    0x7C0000
    0x7B0000
    0x7A0000
    0x790000
    0x780000
    0x770000
    0x760000
    0x750000
    0x740000
    0x730000
    0x727802
    0x710000
    0x700000
    0x6F0000
    0x6E0000
    0x6D0000
    0x6C0000
    0x6B0000
    0x6A0007
    0x694440
    0x680000
    0x670000
    0x660000
    0x650000
    0x640000
    0x630000
    0x620000
    0x610000
    0x600000
    0x5F0000
    0x5E0000
    0x5D0000
    0x5C0000
    0x5B0000
    0x5A0000
    0x590000
    0x580000
    0x570000
    0x560000
    0x550000
    0x540000
    0x530000
    0x520000
    0x510000
    0x500000
    0x4F0000
    0x4E0001
    0x4D0000
    0x4C000C
    0x4B0840
    0x4A0000
    0x49003F
    0x480001
    0x470081
    0x46C350
    0x450000
    0x4403E8
    0x430000
    0x4201F4
    0x410000
    0x401388
    0x3F0000
    0x3E00AF
    0x3D00A8
    0x3C03E8
    0x3B0001
    0x3A9001
    0x390020
    0x380000
    0x370000
    0x360000
    0x350000
    0x340420
    0x330080
    0x320080
    0x314180
    0x3003E0
    0x2F0300
    0x2E07F0
    0x2DC61F
    0x2C3FA0
    0x2B0000
    0x2A0000
    0x290000
    0x280000
    0x2703E8
    0x260000
    0x250105
    0x2400C8
    0x230004
    0x220010
    0x211E01
    0x2005BF
    0x1FC3E6
    0x1E18A6
    0x1D0000
    0x1C0488
    0x1B0002
    0x1A0808
    0x190624
    0x18071A
    0x17007C
    0x160001
    0x150409
    0x145848
    0x1327B7
    0x120064
    0x110083
    0x100080
    0x0F060F
    0x0E1878
    0x0D4000
    0x0C5001
    0x0BB058
    0x0A10F8
    0x090004
    0x082000
    0x0700B2
    0x06C802
    0x0528c8
    0x040A43
    0x030782
    0x020500
    0x010808
    0x002018

  • Samuel,

    I analyzed these registers and found that:
    PFD_DLY_SEL should be 0, but you have 1. Although I don't think this causes your issue.

    I also checked the engineering registers and found nothing suspicious. Your registers are the same number and same order with TICSPro.

    Regards,
    Dean
  • Thank you for analyzing the registers. I changed PFD_DLY_SEL to 0 but the lock time didn't increase.

    I'm using the LMX2572 with the Version, see picture. Is there a newer chip revision?

  • Samuel,

    This is the latest production revision silicon.

    Regards,
    Dean
  • That means, with the LMX2572 a lock time < 20us is not possible. I hope TI updates the datasheet and/or fixes this issue.

    Regards Samuel

  • 5100.Fast frequency switching full assist.pdfSamuel,

    Debugging a setup over E2E does not always work.    I don't have the plot for the LMX2572 to prove it can be done, which would be nice.

    That being said, for the sister part with a higher frequency VCO, the LMX2594, I have this result to show.

    Regards,

    Dean