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

LMX2615-SP: Will not lock on initial power on but subsequent attempts are successful

LMX2615-SP: Dynamic switching of MUXOUT_LD_SEL without having to reprogram R75 to R0

Edwin Grigorian
Prodigy 20 points
Part Number: LMX2615-SP
Other Parts Discussed in Thread: LMX2594,

I have a question regarding whether the MUXout pin can be switched dynamically without having to redo the initial power-up sequence programming.  I'm not sure if R75 to R0 reprogramming is required after this change or whether MUXOUT_LD_SEL can simply be switched before performing SPI readback.

It's unfortunate that TI chose to multiplex the MUXout pin between the lock detect function and SPI' s SDO.  With several NC pins, seems like TI could have just opted to use two of those NC pins for Lock_Detect[1:0] status function rather than share this MUxout pin with SPI SDO.

We have a use case where we need to do reads and writes to the LMX2615 via SPI, but also need to always have lock detection status available.  Keeping the pin as SDI, requires waiting at most 650us (for VCO to lock) and then doing a read to register R110 after each time the PLL_N and PLL_NUM fields are changed, which is quite often in our situation.

Instead, I would like to keep MUXout as a Lock Detect indicator (MUXOUT_LD_SEL=1, LD_TYPE=1).  Then anytime I need to readback all of Register R0-R114, I would first switch MUXOUT_LD_SEL to 0, perform the reads, then return MUXOUT_LD_SEL back to 1 so that for majority of the time when I'm not needin g to do register readbacks, the MUXout pin remains as a lock detect inidcator.

So, is this dynamic switching of MUXOUT_LD_SEL allowed as described, or do I need to rerun the intialization sequence all over again?

Thank you

  • 0
    TI__Mastermind 33790 points

    Dynamic switching of MUXOUT_LD_SEL is permitted. It is also valid to write the updated R0 with FCAL_EN = 0, so you can avoid triggering frequency calibration every time you set MUXOUT_LD_SEL to a new value - next time you need to calibrate, just write FCAL_EN = 1 again.

    The MUXout pin and its functionality are a source of significant grief for many of our customers over the last several years. There's three major reasons things ended up this way:

    • We didn't have enough pins on the commercial-grade LMX2594 (from which the LMX2615-SP inherits much of its design) for a dedicated lock detect pin - we really do need all those grounds for performance and noise isolation. So already, the lock detect pin would have to be relegated to an unused bond pad somewhere on-die, which would consume limited area on the device perimeter and force new positions for many other pins that we did not want to move for performance reasons.
    • To offset the increased size of the space-grade packaging, we moved the die closer to one corner in particular, such that the bondwire length from RF outputs was minimized - this was necessary to maintain output power at remotely acceptable levels. We literally couldn't reach many of the NC pins thanks to a combination of die shape, package orientation, maximum bondwire length, and wire-to-wire clearance.
    • Several NC pins that we could reach serve other functions during factory test. It is conceptually possible that these pins could instead be muxed with lock detect functions, but it would have greatly complicated the automated testing routines.

    Despite what may have seemed like valid reasons at the time, clearly we did not make the correct prioritization - the dedicated lock detect pin is valuable. Until we can introduce a new design to the space-grade market, there's not much we can do about the MUXout pin; but we definitely understand it's frustrating to use in its current implementation, and I am regularly raising internally the need for separated and dedicated pins for each of readback and lock detect.

  • 0 in reply to Derek Payne
    Prodigy 20 points

    Thank you for your quick and thorough response.  I now understand the trades that you had to make which prevented having to provide a dedicated LD pin.  Also it's good to know that I can keep FCAL_EN at 0 while switching MUXOUT_LD_SEL.