• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 9 subscribers
  • Views 531 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

LMX8410L: SPI Bus Behavior

Philip Swan1
Prodigy 50 points
Part Number: LMX8410L

The data sheet says under "There are several other considerations for SPI readback:", "The MUXOUT pin is always for the address portion of the transaction." This sentence seems incomplete. What should it say?

  • 0
    TI__Guru* 81400 points

    Hi Philip,

    Yes, we missed one magic word there.

    The complete sentence is:

    The MUXOUT pin is always low for the address portion of the transaction.

    Thank you for pointing this out, we will file this error and make the change in next revision of datasheet.

  • 0 in reply to Noel Fung
    Prodigy 50 points

    Thanks for quickly responding! I'm debugging a board with 8 of these parts on it organized into two groups of four. Within a group of four, the MISO outputs are all connected to the same signal on the board, which then becomes an input to our main FPGA. Every chip receives its own individual CSB signal from the FPGA.

    Is MISO tri-stated when CSB is deasserted? Or, was it a mistake to wire the MISO signals together?

  • 0 in reply to Philip Swan1
    TI__Guru* 81400 points

    Hi Philip,

    MISO.....did you mean MUXout? It is not high-Z when CSB is not asserted. You cannot directly connect multiple MUXout together. The simplest way to resolve this problem is use a diode for each MUXout to forward the readback data or LD signal to the FPGA.

  • 0 in reply to Noel Fung
    Prodigy 50 points

    We would like to learn as much as possible about the behavior of the MUXOUT pin. We think that it tri-states when CE (Chip Enable) is low. Could you confirm and tell us if there is any other hidden functionality that might enable us to control it or tri-state it?

  • 0 in reply to Philip Swan1
    TI__Guru* 81400 points

    Hi Philip,

    Unfortunately, it is not configurable. It is either HIGH or LOW. 

  • 0 in reply to Noel Fung
    Prodigy 50 points

    I have one more question related to this thread. If another part were to drive the MISO line high and low (i.e. performing normal SPI transactions) while MuxOut is connected to the same MISO line, what is the likelihood that this perturbation would prevent the LMX8410L from operating in compliance with its specification? For more context, assume that the LMX8410L is in read-back mode but with its CSB de-asserted (and thus it will be driving its MuxOut low) and assume that the LMX8410L is configured into INTERNAL LO/DIV2 mode.

    Part 2 of this question is: Is the LMX8410L's RF parametric performance tested while signalling activity is occurring on the SPI lines at the same time? Or, is there an expectation that all SPI activity should cease after the part is configured to enable the part to perform optimally?

  • 0 in reply to Philip Swan1
    TI__Guru* 81400 points

    Hi Philip,

    When LMX is driving the MUXout LOW, the MISO bus will be driven LOW, you won't see any readback data from other devices.

    When the SPI is toggling, you might see some random spurs at the VCO output. We have seen this behavior in some synthesizers, but I don't know if this happen to LMX8410L or not.

  • 0 in reply to Noel Fung
    Prodigy 50 points

    Thanks. I think the data sheet needs some additional text along the lines of:

    1) "The MuxOut signal does not tri-state when the CSB is deasserted".

    2) Test conditions for the part: "There was / was not activity on the SPI bus when parametric measurements were taken."

    Also: DIGITAL INTERFACE -> "High level output current" row, it looks like there are two typos mixing up V and I.

  • 0 in reply to Philip Swan1
    TI__Guru* 81400 points

    Hi Philip,

    Thanks for your suggestion and finding, we will record it and fix it in the next revision of datasheet.