• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 22 subscribers
  • Views 344 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LMX2594: PLL No Longer Locks

Wei-Chung Huang
Prodigy 10 points

Part Number: LMX2594

Tool/software:

We have the LMX2594 chip integrated to a custom PCB, inside a housing.  This is the second revision of the PCB, and both designs had been working perfectly until the following:

A co-worker left the whole unit with the PCB inside powered ON, without initializing or powering down the LMX, over a ~24 hour period.  He didn't keep track of anything.

Now the LMX2594 no longer locks.  It had been outputting a beautiful 2.72 GHz signal, and now sometimes you see a signal, sometimes you don't, but it never locks.  The readback say "Unlocked (Fvco Low)".

When we do see a signal, sometimes it likes to go between a ~3.639 GHz and ~3.83 GHz signal, even with the Fvco set to a range of values.  Please see the spectrum capture below.

By the way, we're using a 10MHz reference signal, and Fpd is 20MHz, which is the delta between those two frequencies above.  I don't know if that helps.  Here's a screenshot of TICS Pro's GUI on one of many Fvco value attempts:

I've also managed to just get a bad signal, see spectrum below:

Is the part most likely damaged because of overheating or is it recoverable?  Could we have just been lucky and it's actually another aspect of the design, like a bad loop filter design?  Unfortunately getting in to look at any of these components isn't possible unless we un-assemble the whole unit.

Please help.  Thank you!

  • 0
    TI__Guru** 117470 points

    Hi Wei,

    Make sure LD_TYPE is as follows, otherwise rb_LD_VTUNE will say Fvco Low. 

    Sounds like you are still able to program the device, to confirm this, program POWERDOWN = 1 to see if there is current change.

    Also try do a read back to compare below parameters between a known good board and the bad board.

    You can measure Vtune signal with a scope, it should be a static signal at approx. 1.3V. 

    How does the reference clock signal looks like at OSCin pin?

  • 0 in reply to Noel Fung
    Prodigy 10 points

    Hi Noel,

    Thank you very much for your immediate reply. It was very useful and very much appreciated.

    Here are our results:

    Yes, LD_TYPE was selected to be "Vtune and VCOCal", and "Unlocked (Fvco Low)"
    is the response.

    Yes, the device is responsive to POWERDOWN, and changes current.

    Unknown regarding those VCO Calibration values since we don't have a known good board to compare the values against. We have read back rb_VCO_SEL = 3, rb_VCO_CAPCTRL 9 or 18 depending on the time we've tried, rb_VCO_DACISET 259 or 276 depending on time we've tried. We've programmed 7, 183, and 128 respectively, tried 7, 183, and 300, and tried 4, 183, and 300 respectively to no avail. It seems like we can force the values of VCO_SEL and DACISET to readback to what we set, but the VCO_CAPCTRL value doesn't budge.

    Vtune is no good.  It measures 2.079V instead of 1.3V.

    The reference clock signal looks good at the OSCin pin. In this case, it's a 10MHz signal, centered at 0V, Vpp = 0.494V. Light green curve in the screenshot below.

    Any thoughts of what to do next?

  • 0 in reply to Wei-Chung Huang
    TI__Guru** 117470 points

    Hi Wei,

    Oscin is good. 

    Were you using no VCO assist calibration in your read back test?

    At VCO=11440MHz, your read back shown VCO3 is selected. I would guess, majority of the devices should use VCO4.

    The variation in CAPCTRL and DACISET is too big. Every time we calibration and read back these data, the variation should be very small. 

    If you were using no assist calibration, looks to me the device is attempting to lock with VCO3. You can try forcing the device to use VCO4. 

    set VCO_SEL = 0x4; VCO_SEL_FORCE = 0x1. 

    Try also not using the fosc doubler, i.e. reduce the fpd to 10MHz.

    The last thing to check is the pin voltage.

  • 0 in reply to Noel Fung
    Prodigy 10 points

    Thank you for the quick response again!

    Correct, we were using no VCO assist calibration in our read back test.

    Okay, we've tried forcing the device to use VCO4 but the output frequency is still bad and not locking. The readback to CAPCTRL and DACISET are 141 and 450 respectively.

    Okay, we performed without using the fosc doubler (i.e. reduced fpd to 10MHz), but no improvement.

    And lastly, we've probed the pins as suggested:

    Pin # Pin Name Measured Supposed to Be Pass/Fail
    3 VbiasVCO 0.375 1.3 Fail
    27 VbiasVCO2 0.656 0.7 Pass
    29 VrefVCO2 2.85 2.9 Pass
    33 VbiasVarac 1.459 1.7 Fail?
    36 VrefVCO 2.854 2.9 Pass
    38 VregVCO 2.024 2.1 Pass

    VbiasVCO does not measure as listed, measures 0.375 instead of 1.3V.  VbiasVarac seems likely low as well, measuring 1.459 instead of 1.7V.  What does that indicate?

  • 0 in reply to Wei-Chung Huang
    TI__Guru** 117470 points

    Hi Wei,

    After Vcc power up without programming, VbiasVCO should be around 1V. After programming and lock, it will change to 1.3V. 

    Anyway, 0.375V is still way below 1V, looks like this is the reason why it is not working. Verify all Vcc supply pins has 3.3V. If this is the case, I am afraid you need to replace the device. 

  • 0 in reply to Noel Fung
    Prodigy 10 points

    Hi Noel,

    Okay.  Yes, we have verified that all Vcc supply pins still have 3.3V.  Understood that the remaining thing to do is to replace the device.  Thank you very much for all of the troubleshooting tips.