• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 16 subscribers
  • Views 829 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.

CC1111 SPI Slave Problems. Does SSN actually work ?

Robert Wey
Prodigy 50 points

I have the SPI on a CC1111 set up for slave mode, where I'm sure I have slave mode selected and all four pins set for peripheral function.

I then set up a DMA channel to receive SPI data, but I find the DMA is triggering on reception even when the master direct SPI activity to other devices ... and the CC1111's SSN pin never goes low.  ( confirmed with a logic analyzer ).

How can this be happening?  If the SPI master never asserts ( logic 0 ) the CC1111's SSN line, then surely one would think the CC1111 would simply ignore any SPI activity on its other three lines.

Am I missing something here?

Edition:  I guess I need someone to confirm or deny:  If SPI slave mode SSN is logic 1, the CC1111 will ignore all activity on MISO, MOSI, and SCK.

Regards,

RW

 

(p.s  I hope this is the right forum for this question )

  • 0
    Mastermind 8170 points

    Taken from the CC1110 data sheet:

    12.14.2.3 Slave Select pin (SSN)

    When the USART is operating in SPI slave

    mode, a 4-wire interface is used with the Slave

    Select (SSN) pin as an input to the SPI (edge

    controlled). The SPI slave becomes active

    after a falling edge on SSN and will receive

    data on the MOSI input and send data on the

    MISO output. After a rising edge on SSN, the

    SPI slave is inactive and will not receive data.

    Note that the MISO output is not tri-stated

    when the SPI slave is inactive.....

    I can confirm this paragraph is correct. I use a CC1110 as a MCU for audio processing (SPI /I2S great for CODEC interface) as master and a CC1110 for the radio with the SPI as slave. I used DMA.

    The CC1110 slave SSN is controled with a GPIO pin on the master, and the SSN pin is never used on a Master.

     

     Here is what it looks like running....

  • 0 in reply to H Stewart
    Prodigy 50 points

    H Stewart,

    Thanks for your reply.  Since posting, I have gotten my SPI slave mode working and I believe I know what was going wrong.  Our design has three CC1111 devices operating as slaves on a common SPI bus driven from a TI 5504 DSP acting as SPI master.  The 5504 SPI master controls up to 4 individual SPI select lines.  We confirmed the odd behavior with a logic analyzer, where we could clearly see logic 1 on one of the CC1111's SSN while a transaction was being directed to another, yet it was receiving data.

    What we found was this:  When the 5504 would initiate an SPI transaction, it would cause a very short glitch on all three SSN output lines to our three CC1111's.  This glitch must have been fouling the internal SPI state machine of the CC1111's and placing them in active slave mode, never again to go dormant.  We ended up putting an RC filter on the SSN lines to filter out the aforementioned glitch and the problem went away.

    In conclusion, it appears there are two problems:  1) The TI 5504 glitches it's outgoing SPI chip select lines when it's being configured and, 2) The CC1111 is intolerant of fast pulses on its SSN line when in slave mode.

  • 0 in reply to Robert Wey
    Mastermind 8170 points

    Hello Robert,

    First, I really appreciate your posting back and sharing what you found.

    We have a design with the C5501 as master and 4 slaves with one being a CC1110. We use 4 seperate GPIOs for SSNs, one for each slave and also the OEx enable for a quad / quad buffer (54LVTH162244) for  the 3 SPI lines. The GPIOs do toggle during initialization but once set high seem glitch free. We then clear all SPI flags and only arm the DMA when ready.

    Just so we are not missing something that will bite us later what is the cause of the glitch you are seeing? Is it noise on the GPIO / SSN line?

  • 0 in reply to H Stewart
    Prodigy 50 points

    H Stewart,

    Again, we driving the three CC1111's with the SPI module on a TMS320VC5504.  The TI CSL SPI_open( ) function causes all chip select lines to glitch ( we confirmed this using a logic analyzer ), and calling this function is required whenever changing chip select.

    From your previous reply suggesting the CC1111 SSN line is "edge" triggered, I'm wondering if the CC1111 sees the fast low-going glitch, but misses the rising edge and as a result then leaves the SPI slave receiver enabled.

    Just some thoughts, and again thanks for your help.

    R. Wey