• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 21 subscribers
  • Views 339 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.

Original question:

LMX2531: latency between reset and lock to previously saved frequency setting

LMX2531: LMX2531

Grzegorz Gancarczyk
Prodigy 10 points
Part Number: LMX2531


Hello,

My use case is as follows:

1. I perform the whole colds start procedure as described in the LMX2531 Data Sheet, chapter 8.6.1.1. Before sending any data over uWire, I set the CE pin high. The delay between sending the first R5-related data over the uWire bus and setting the CE pin high is about 86 usec. 10 msec delay happens after last R5-related data goes over uWire bus.
2. My lmx2531lq1415e locks using my reference 10MHz clock. Ftest/LD goes high as configured for Digital Lock Detect.
3. I put the CE pin low.
4. I put the CE pin high and send over the uWire bus R7, R6, R3, R2, R1 and R0-related data. The delay between sending data over uWire bus and setting the CE pin high once again is more-less 80 usec.
5. I do not obtain a lock to the same 10MHz clock.

My question is, for a warm start scenario as described above, what is the minimum time period between setting the CE pin high and sending R0-related data over uWire bus to achieve a successful lock?

Regards,
Grzegorz.

  • +1
    TI__Mastermind 34120 points

    Grzegorz,

    "Warm Start" is a bit misleading for what's happening. When you pull CE pin low, it disables most of the internal regulators, and they will once again need around 10ms to charge up external capacitors on Vreg pins or else the calibration will be performed with incorrect values. The delay time between CE high and programming success could be shortened by reducing the size of the capacitors on the Vreg pins, at the expense of phase noise (especially if VregVCO is reduced).

    We don't specify a minimum delay since this is closely tied to capacitor values on the Vreg pins, which is a user-driven parameter. Moreover, there will be some PVT variations which are difficult to predict that could have around ±30% effect on required delay time. 10ms is a somewhat arbitrary, but safe, hedge against PVT and user choice of capacitor; it may be excessive in some cases. If you want, you can perform an experiment to determine the impact of different delays:

    • Attach scope probes to the Vreg pins, notably the VregVCO pin as this is likely to be the one that takes the longest to recharge after CE pin toggle
    • Inject varying delays on the uWire bus and observe success or failure of lock detect
    • Optionally, if the shortest lock time is required, the capacitors on Vreg could be varied (made smaller than default values). This might impact phase noise though.

    Regards,

    Derek Payne

  • 0 in reply to Derek Payne
    Prodigy 10 points

    Hello Derek,
    at first, thank You for a fast reply.
    Your explanation made a difference in how now I read the LMX2531 Data Sheet. I was convinced that this 10 msec delay was tightly related to resetting the device during a cold start via performing the R5 INIT1, R5 INIT2 and R5 Initialisation Sequence described in Table 4, chapter 8.6.1.1. And that it does not have any direct relation to the CE pin status. I then assumed, that the CE pin low moves the chip into a "sleep" state and that there might be some sanity period needed for the chip to enter "normal" mode once again, but that it is a matter of microseconds and not tens of milliseconds. While playing with the LMX25311415EVAL I registered that I need ~5 msec to get a successful sync after coming back with CE pin to high and programming registers R7, R6, R3, R2, R1 and R0.
    Nevertheless, I will try to find border value, add 30% to it and stick for a while with that delay and I will see what will come.