LMX2492: Soft reset of LMX2492 fails occasionally

Prodigy 110 points

Replies: 20

Views: 307

Part Number: LMX2492

Hello,

We observe that a reset of the LMX2492 PLL through register write fails with a failure rate in the order of 1%.

We reset the device by the following writes to register 2:

PLL_write(0x02, 0x04); // Register reset (same issue with value 5, i.e. w/o powerdown)
delay_ms(1);           // Delay
PLL_write(0x02, 0x01); // Set PowerDown to '01' (steady on)
_delay_ms(1);          // Delay
{...}                  // Load MUC, FRAC, CPM, COUNT registers etc...


We define failure to reset by not receiving a frequency signal out of MUXout, which is set to "Output N Divide/4" (MUXout_MUX=19, MUXout_PIN=2, set by PLL_write(0x27, 0x9A)). Instead, MUXout is constant high.

We also observe that in the failed state reserved registers 46..55 (0x2e..0x37) read 0x00, while those registers read non zero values after successful reset and initialization. Documented registers read reasonable values in any state.

We have increased delay in above code without reduction of failures.
We have increased Vcc to the datasheet maximum 3.45V without reduction of failures. Each of the four 3.3V supply pins are supplied through a LC network with a 330 Ohm (at 100MHz) ferrite bead in series with one 1nF and one 100nF capacitor close to the device , all four of those stubs powered by a single 3.3V LDO with additional capacitors.

Failure to reset can be usually resolved by repeating above reset procedure.

What can cause this behavior?
Thank you!

20 Replies

  • Hi Christian,

    RESET will reset all the registers to the silicon default values, that is, the POR values as shown in the Register map section in the datasheet. If the reset is successful, MUXout_MUX will be reset to "Output Readback" while MUXout_PIN will be reset to "Tri-state".

    After a reset, we have to write all the registers once to make it operate as desired. 

    Since you write 0x004 to R2, you are asking the chip to reset and powerdown. I guess the chip was powerdown but the reset was ignored. That is why when you power it up again, you still get the desire MUXout signal.

  • In reply to Noel Fung:

    Hi Noel,

    Thanks for your reply.

    When resetting by writing the value 5 to register 0x02, i.e. reset without powerdown, we do see the same issue.

    We do re-write all registers, including those related to MUXout, after every attempt to reset.

    I was hoping that the apparently unusual state of the undocumented registers 46..55 (0x2e..0x37) could give you a hint? They read all zero in the "failed" state, but other values when operating as expected.

    Best regards, Christian.

  • In reply to Christian Sayer:

    Hi Christian,

    "When resetting by writing the value 5 to register 0x02, i.e. reset without powerdown, we do see the same issue.

    We do re-write all registers, including those related to MUXout, after every attempt to reset."

    After the reset and re-write all registers, did you get it lock? If it is locked, I don't see any reason why you did not get the right output from MUXout pin.

  • In reply to Noel Fung:

    Hi Noel,

    Yes, it is in lock after instances of "failed" reset. That is, the Output_DLD and output_CPMON_good signals are high. That said, we observe them through the same multiplexer that gives us constant high when set to Output_N_Divide_by_4. However, also our monitoring of the CPout pin indicates that it is locked.

    Best regards, Christian.

  • In reply to Christian Sayer:

    Hi Christian,

    OK, you confirmed it is locked, that means you were able to program the device, so there is nothing wrong with the SPI logic.

    Can you try set MUXout_MUX to GND and Output R/4?

  • In reply to Noel Fung:

    Noel,

    Thank you for your support. I currently don't always have access to devices or the lab environment, hence the delay on my end.

    When the device enters after reset the state which I call "failed":

    MUXout_MUX is set to N/4 and the MUXOUT pin is at constant high (there are about 25MHz under normal conditions).

    I then set MUXout_MUX to R/4 and the MUXOUT pin goes to constant low.

    I then set MUXout_MUX back to N/4 and the MUXOUT pin goes back to constant high.

    I then set MUXout_MUX to GND and the MUXOUT pin goes to constant low.

    I then reset the device again, and (in most cases, unless it fails twice in a row) I see the expected frequencies at MUXOUT.

    The OSCin inputs are driven by a LVDS TCXO. Below is a scope plot of the OSCin inputs (note 100mV per division). Do we meet the input requirements of the LMX2492?

  • In reply to Christian Sayer:

    Hello Christian,

    It would be helpful to us if we could get the full readback results in the "fail" state, vs the readback results in the normal state, as a file (so we can observe what specific registers and other functions are not being properly reset). Can you give this to us so we can do a diff on the states? It may provide us a clue as to what's going on.

    I don't see any problems with the OSCin.

    Regards,

    Derek Payne

    Texas Instruments

  • In reply to Christian Sayer:

    Hi Derek,

    Please find the two files above attached.

    Note: Unlike in my reply from Jan 26 2021, CPMON_good seems not to be at '1' in the failed state. I think this can be expected as I now am cycling through LMX2492 resets after system reset, as opposed to the running system I used previously. Failure rates and patterns are identical in both approaches. Our application uses a frequency counter at the N/4 output, which yields 0 in the failed state, and I generally use that to determine failure. I have additionally used a scope in my reply from Feb 12, 2021 to confirm R/4 and N/4 outputs when failed. In short, my assumption or observation is that whether the chip is "locked" or not does not matter for our problem that we don't get the divided frequencies out of the internal multiplexer.