• TI Thinks Resolved

LMX2595: CSB line communication

Genius 10785 points

Replies: 9

Views: 139

Part Number: LMX2595

Hello Guys,

Good day.

Our customer is asking if he can communicate to each chip individually by using only the CSB lines to select one chip, or the other, or does the SPI bus have to be physically disconnected from one device (via the mechanical switches) while he talk to the other?

He is  trying to make a low-noise 15 GHz LO with 2 LMX2595's as in the TIDA document. He prefer to use the CSB lines over mechanical switches.

Thanks!

Art

  • I just like to add that the MUXout pin of every LMX is configured as data out (SDO), NOT as lock detect (LD).

    Thanks!

    Art

  • In reply to Art Mecina:

    Hi Art,

    The SCK and SDI pins can be shared without issue, as long as there are separate CSB signals for each device on the bus.

    As far as I know, the MUXout output is permanently configured as a push-pull output. Consequently, the customer would not be able to share a data line for the MUXout pins to return the SDO communication. If the customer wants to do this, they will need an additional MUX and the chip select bits should be used as part of the addressing scheme. I will double-check in case we have a MUXout tristate option somewhere undisclosed in the register map; if we do have a tristate option, I'll let you know and add it to our list of datasheet updates so it can be officially supported.

    Regards,

    Derek Payne

    Texas Instruments

  • In reply to Derek Payne:

    Hi Art, 

    The MUXout of LMX2595 cannot be shared with other devices, this pin does not support tri-state. 

  • In reply to Derek Payne:

    Hi Derek,

    I am the customer in question.

    Your answer is clear and as a consequence my PCB is in trouble since I tied all four of the MUXouts together - thinking they were the SDO line of the SPI bus.

    My next question, and yes, it's rhetorical, is where exaclty in the 79 pages of the LMX2595 datasheet, was it mentioned, or even hinted, that the MUXout pin is push-pull and absolutely can NOT be used as the LDO line of the SPI bus connected to multple devices?

    I imagine I'm not alone in asking this.

    Thank you,
    Tony

  • In reply to Tony Rohlev1:

    Hi Tony,

    The datasheet did not say the MUXout pin supports tri-state, so we should not assume multiple MUXout pins can be tied together.

  • In reply to Noel Fung:

    Hi Noel,

    The term 'SPI' is used in no less than 10 locations in the LMX2595 data sheet. This might lead some users to believe that the device actually supports a standard SPI interface when it clearly does not. I don't think it would be a waste of ink or space if TI was to elucidate this fact in the data sheet.

    Thank you,

    Tony

  • In reply to Tony Rohlev1:

    Hi Tony,

    This is a common pain point for SPI usage with LMX2595 (and similar devices), so I think a datasheet update is necessary to clarify the MUXout behavior and its implications for SPI.

    That said, after searching the register map, I believe I have located an undisclosed bit which can tri-state the MUXout pin. Setting R1[3] = 0 should tri-state the MUXout pin. Set R1[3] = 1 to enable the MUXout pin driver.

    Default register values on startup should set the MUXout pin to lock detect mode, and the lock detect should be low after reset, so the MUXout pins should share the same state on startup. I recommend writing R1[3] = 0 immediately after power up on all devices simultaneously, so that subsequent programming does not cause bus conflicts. To get readback, set R1[3] = 1 for a single device, perform the readback transaction, and set R1[3] = 0 once all readback is complete. If a device must be reset, be sure to write R1[3] = 0 again immediately after the reset.

    If there is a subsequent spin to your board, I recommend connecting the MUXout pins through some resistance to avoid damage from accidental bus conflicts. In theory it should be possible to avoid this by programming alone, but adding the resistance is a hedge against unexpected hardware faults such as device-specific power interruption causing POR.

    Regards,

    Derek Payne

    Texas Instruments

  • In reply to Derek Payne:

    Hi Derek,

    THANK YOU , YOU HAVE MY VOTE FOR GENIUS OF THE YEAR! - in bold, itallic, all-caps ... if they had flashing Neon I'd do that too.

    Yesterday we tried the procedure exactly as you outlined it and now we have full, unique, programming and readback between 2 pairs of dual LMX2595's all sharing the same SDI, SCK and MUXout (SDO) lines. It might be the first time this has been done outside of Texas - in Sofia, Bulgaria of all places - and, cherry-on-cake, it's Friday so you also made our weekend.

    All the best,

    Tony

  • In reply to Tony Rohlev1:

    Tony,

    Glad I could help! If I've resolved your question, could you help me out by clicking the green button on my answer?

    Regards,

    Derek Payne

    Texas Instruments