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: Inconsistent register programming

Part Number: LMX2492

Good evening,

I am getting inconsistent programming of registers on the LMX2492 and I was hoping you could offer some insight.

Below is the same command programmed twice, it is programming the gain register 0x1C as 0x1F from a previous value of 0x0. The sclk speed is 125 kHz.

CH1 - latch enable

CH2 - clock

CH3 - data

CH4 - gain output

They were done one after the other. As you can see, the programming "took" after the second command with the gain rising.

I don't appear to be violating any timing rules of the chip and sometimes it takes 3 or 4 commands to actually take. My slew rate is much faster than the recommended 30V/us (checked on a better oscilloscope). My voltage high levels are above the 1.4V minimum threshold.

Is there a register programming procedure I am not following here? The data sheet did not seem to indicate anything specific.

Thank you,

Nicholas

  • Hi Nicholas,

    Does the Green trace represent the signal at CPout pin?

    If CPG = 0, charge pump is put into tri-state output, the PLL loop is therefore opened and there is no voltage build up in the loop filter. 

    If you want to verify your programming, you can program the POWERDOWN bit, you will see current change if programming is successful. 

  • Hi Noel,

    Yes, I also tried that and the results are similar.

    I think maybe my logic levels were too high? I changed the iostandard for those pins from LVCMOS33 to LVCMOS25 and the single register programming is more consistent.

    I then tried programming the entire device and It was... again... inconsistent. I managed to get 9/10 times consistent by slowing the sclk down to 1 kHz.

    I am worrying about signal integrity now.

  • Hi Nicholas,

    I am puzzling too, except for the step below, your waveform looks good. 125kHz is also fine, our software tool is also running at this speed. 

    At the moment I don't have any other guess.