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.

LMX2595: Output Settling Time from POWERDOWN De-assertion

Part Number: LMX2595

Hello, if I put the LMX2595 into POWERDOWN mode by asserting the bit in R0, how long would it take to lock back to the frequency after I de-assert that bit?

Additionally, can I program a new frequency to the part while it is in POWERDOWN mode, and will the timing to the previous question be the same(-ish)? I am using Full Assist mode for this so no need to assert the F_CAL_EN bit

Thank you

  • Hi Dylan,

    There is an undisclosed field in the registers, RAMP_LDO_DLY (R6[15:11]) which determines how long to wait between reset/CE toggle and LDO output stable signal. By default it is set to 25, and counts 2^13 state machine clock cycles per tick. So if you exit powerdown with a 100MHz Fosc and CAL_CLK_DIV=0, you can expect 25 * 2^13 * 10ns delay, or approximately 2ms, before the device LDOs are fully powered up at that specific Fosc and CAL_CLK_DIV. We don't recommend changing the values of RAMP_LDO_DLY, because this could cause the device to calibrate incorrectly after clearing the POWERDOWN bit.

    After the internal LDOs are all ramped up and active, in full assist mode, the remaining analog settling time will be within one VCO capcode (about ±40MHz max transient at the VCO) and can be determined from PLLatinum Sim.

    The device can still be programmed in the POWERDOWN state, and registers will be retained between POWERDOWN toggles. So you could set POWERDOWN=1, establish new full assist parameters, then POWERDOWN=0 to exit powerdown, await the LDO powerup, and become active at the new frequency. I admit I am not sure whether OUT_MUTE needs to be set, and/or OUT_FORCE needs to be cleared, while awaiting the LDO powering up, but it should be a straightforward exercise to check if either field has any effect.


    Derek Payne

  • Thank you for the quick reply Derek, this is exactly the answer I was looking for.

    Unfortunately that is too long for my purposes, do you know if this is similar timing from toggling OUTA_PD/OUTB_PD or OUT_MUTE? At the moment I have both OUT_MUTE and OUT_FORCE off as I do not mind the state between frequencies

  • Toggling OUTA_PD/OUTB_PD or OUT_MUTE would both be faster. There's no fixed time for how long it takes before toggling OUTx_PD=0 restores the output format, and runt pulses or glitches may occur while the output is powering up, but it will definitely be faster than 2ms - likely in the hundreds of nanoseconds range. OUT_MUTE only mutes during FCAL, and in full-assist mode there is no FCAL event, so I don't think OUT_MUTE would be of any use.

    Are you trying to ensure there is no output while you transition frequencies? Reduce current between frequency transitions? I can't tell from the way you phrased the "state between frequencies" remark; if you don't care about what the output is doing between transitions, there shouldn't be any need to make changes to the output buffer or powerdown the device when hopping to a new frequency using full-assist fields.


    Derek Payne

  • Ah ignore that state between frequencies remark, I wasn't using OUT_MUTE and OUT_FORCE and had just read up about them, determined they were of no interest to me in regard to their function. 

    I basically want to conserve current and power consumption when not using the PLL/certain output, but still be able to get back my output relatively quickly (probably <10µs). Will asserting OUTA_PD/OUTB_PD significantly impact my current consumption? Or is that more up to the VCO?

  • never mind, just found that out for myself

    both outputs powered off yields around 290mA current (according to TICS estimate), 1 on is 382mA, both on is 470mA

    I will use this method then of OUTA_PD/OUTB_PD to control my power consumption, thank you Derek

  • No worries, glad the TICS Pro current calculator tool is working as intended. I'll mark the thread as resolved. If I answered your questions, can you help out future designers by clicking the green button? This question seems likely to come up again for others, and resolved questions are prioritized in E2E's search algorithm.


    Derek Payne