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.

LMX2492: Q

Part Number: LMX2492

Dear TI support team, 

here is an issue with the Charge Pump Voltage Monitor of the LMX2492. 

Our design had used the CPMON functionality for lock detection by assigning the "CPMON good" signal to the TRIG2 output. This has always worked reliably and without issues (series production since 2019). 

Now with a design change the "CPMON good" signal doesn't go high. 
Basically, the design has not changed much (higher Q factor of the VCO, and 1 nF instead of 22 nF as first Cap to GND in the loop filter at CPout)


Vcp: 5 V

We see a safe lock condition on our spectrum analyzer and measure clean 2.3 V at CPout. 

However, in this situation, "CPMON good" stays low, and "CPMON too low" is high.

Any ideas what this could be related to?


  • Hi Nils,

    I need to check with the designer of this chip, I will get back to you later.

  • Hi Noel, thank you for taking care of this. 

    In the meantime, I have to report that we found this issue to be dependent on individual specimen of LMX2492. 

    Throughout all our series production of the past 18 months, the issue did not appear. We managed to implement one board from the old batch into our new design, and the issue with the CP monitor is NOT there, so we don't believe it can be related to the VCO characteristics or the loop filter design. 

    Now, recently purchased specimen show this issue, which tends to cause serious delay in our product roll-out. 

    Any feedback will be appreciated!

  • Hi Nils,

    I got some comment from the designer.

    The CPMON works by basically mirroring the charge pump output voltage into a window detector, it shouldn’t be affected by the first loop filter capacitor directly. CPMON levels do have a fairly large variation to them. That mirroring coupled with some wonky issues with the resistor ladder for the threshold setting DAC makes it not so nice. 

    I think the last two sentences above explains why you don't have problem in the past. Could you try lowering the CPM_THR_LOW voltage?

  • Hi Noel, thanks!

    It's good to have confirmed that the detector scheme bears some known issues. 

    However, lowering the threshold even to the lowest values does not show any effect. 

    With one of the individual LMX2492 we have, we see that the bad behaviour is subject to start-up, so if we soft-reset the device during operation, it gets into a state of good and reliable CP monitor behaviour (around 60% of the reset instances), or into the described bad state (approx. 40%). 

    In all cases of bad behaviour, reading back the registers shows that all values are set correctly. 

    We now need to decide whether to implement some external CP voltage detection in our design, or if we see this as an issue that hints to more profound limitations with this chip. 

    Looking forward to your comments on this!

  • Hi Nils,

    How bad is the phase noise if we use 22nF instead of 1nF in the loop filter? With the new specimen, can we fix this issue with 22nF capacitor? I just want to see if adjusting the capacitor value is also an option to you.

    In addition, can you use the following MUXout_MUX options instead of CPMON OK?

  • Hi Noel, the first filter cap needs to be at 22 nF, this is required by the VCO characteristics (with 1 nF we will not get the looped into lock, and thus can not judge the CPMON behaviour). 

    Combining the CPMON OK with the DLD does not help: The AND logic works fine, so the DLD goes up fairly reliably, but the CPMON OK stays low, and so does the "DLD&CPMON OK". 

    We can't use the DLD either, because it is down for around 20 µs everytime when updating the N Counter registers. 

  • Hi Nils,

    Can you share your loop filter design? I just want to see if we can come up with a different loop filter that is able to balance between lock and CPMON.