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

LMX2594: Can nCS be toggled as long as CLK is not transitioning?

Variac996
Intellectual 330 points
Part Number: LMX2594

Hello.

I am seeing some strange behavior with the LMX2594 where I can no longer write or read back from the device over SPI. 

This occurs if CLK and DATA are held low and I toggle the nCS line.  (nCS goes from high to low to high again).

Is this expected?

From the datasheet my understanding is that data should only be clocked into to the LMX2594 on the rising edges of CLK if (and only if) nCS is low.  So I thought I could get away with nCS transitioning as long as I ensured CLK did not transition (held low).

I can sometimes recover the device by doing a software reset (write to reset in reg 0), but as soon as I goggle nCS the LMX returns to the bad state.

Thanks for the help.

  • 0
    TI__Genius 16845 points

    Thanks for posting on E2E. I have assigned your post to the responsible engineer. He will respond to you soon.

    Kind regards,
    Lane

  • 0 in reply to Lane Boyd
    TI__Guru** 108330 points

    Hi Variac,

    What was the last written register?

  • 0 in reply to Noel Fung
    Intellectual 330 points

    Hi Noel.

    I've looked at this further and my statement that "as soon as I goggle nCS the LMX returns to the bad state" was not correct.

    The LMX2594 is on a shared bus (SPI CLK and DATA are wired to many devices), so the LMX2594 will have seen lots of SPI traffic before it goes into the "bad state". Apologies for the confusion.

    The last register that I purposely write to the LMX2594  is register R0, to calibrate the VCO (FCAL_EN).  To recover the device I have to assert/deassert the RESET bit. Writing zero to MUXOUT_LD_SEL and not toggling reset does not recover the device, so I don't think MUXOUT_LD_SEL is being accidentally asserted.

    I don't have any issues with the LMX2594 if I put it on a properly behaving bus (nCS only low when talking to the LMX2594), so I am interested to know if the LMX2594 was sensitive to nCS transitioning when CLK/DATA is low. 

    (The reason nCS is transitioning is that I have a buggy SPI controller which uses a 3-8 decoder to drive 8 chip selects with only 3 chip select lines. The controller default state is chip select 7 and the 3-8 decoder is not correctly enabled by the SPI controller chip. This means that when it selects another chip select it unintentionally selects chip select 7 as it enables the 3-8 decoder before it changes the 3-8 decoder input.)

  • 0 in reply to Variac996
    TI__Mastermind 28011 points

    Variac,

    It is not really the case that data is ignored if the CS line is not toggled.

    What really happens is that it counts the bits and then latches this in.  For instance, if you write register R0, but leave out the CSB bit, I actually think that it gets latched in on the last clock bit, not the CSB bit rising edge.

    In fact, for this device you can actually program the entire register set in one huge word.

    So what's the purpose of CSB?  When CSB has a rising edge, what happens is that then the next 8 bits are considered the R/W bit and the address.  Otherwise it autoincrements to the next register.

    I don't know if this explains totally what you are seeing, but maybe.

    Regards,
    Dean

  • 0 in reply to Dean Banerjee
    Intellectual 330 points

    Hi Dean.

    Thanks for looking into this for me.  In my system the LMX2594 is on SPI bus (CLK and DATA shared between devices), so it will have seen lots of traffic meant for other devices on the bus.

    Dean Banerjee said:

    What really happens is that it counts the bits and then latches this in.  For instance, if you write register R0, but leave out the CSB bit, I actually think that it gets latched in on the last clock bit, not the CSB bit rising edge.

    Does this mean that the LMX2594 cannot be used on a shared SPI bus? (The LMX2594 appears to be ignoring traffic when CSB is low, as I have moved it to a chip select which does not "glitch" and the LMX2594 appears to be working correctly...so hopefully this is ok!)

  • 0 in reply to Variac996
    TI__Mastermind 28011 points

    Variac,

    I would think you could and this is the first complaint I have got of this nature, but our general recommendation is to toggle the RESET bit to get rid of any garbage that might be accidentally programmed into the device. .  I would think that if CSB is high, then it should ignore CLK and DATA.

    Dean

  • 0 in reply to Dean Banerjee
    TI__Guru** 108330 points

    Hi Variac,

    The SPI bus can be shared with other devices as long as its CSB is kept HIGH.

    When CSB is HIGH, CLK and DATA are ignored.

    In LMX2594, the written register will be latched to the register bank at the rising edge of the last CLK signal. A LOW-HIGH transition from CSB is needed to tell the chip to prepare for next register write.

    I have tried the following and the part keeps locking without issue.

    - program the device (the last register write is R0)

    - keep CLK, DATA and CSB = LOW

    - toggle CSB from LOW-HIGH-LOW

  • 0 in reply to Noel Fung
    Intellectual 330 points

    Hi Dean and Noel.

    Thanks for looking into this for me and explaining what is going on. This gives me much more confidence that the LMX2594 will work well with our current design, without requiring a respin.

    The LMX2594 is working great on a shared SPI bus when I make sure that I don't glitch CSB.  Fortunately, although my SPI controller has a bad chip select, its signals are routed through FPGA fabric, so I can reroute a properly behaving CSB to the LMX2594.

    (It seems that it is not uncommon for SPI devices to store traffic seen on a shared CLK/DATA lines and latch it on CSB going low-high.  I could repeat this behavior with other SPI devices from other manufacturers...so going forward I will ensure that I avoid "gltichy" chip selects!)