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.

TM4C129XNCZAD: Connecting more than one device to the same Quad Synchronous Serial Interface (QSSI)

Part Number: TM4C129XNCZAD

Hi,

I want to connect more than one device to the same QSSI interface.

The example for 2 devices connection I see in the reference design "Tiva™ TM4C129X Development Board" , p/n DK-TM4C129X.

512 Mb EEPROM (U2) and a microSD use SSI port 3.

EEPROM is using dedicated CS pin SSI3SS, while SD card CS is connected (in my understanding) to GPIO pin.

Is there any document describes how to support two or more Chip Selects for the same SSI?

Best Regards,

Anatoli R.

  • I have no awareness of "any such document" - yet your independent use of multiple GPIO - each dedicated to a specific SPI device's CS - should succeed.

    You must insure that, "One and only one" SPI device becomes active at any time.     (to prevent multiple output contention)

    Depending upon the number of such SPI devices - you may add a decoder/mux IC (such as HC138/similar) to reduce the number of "GPIO" (sacrificed) in service of SPI chip selects.      (i.e. 3 such GPIO may control up to 8 SPI devices via this (added chip) method...)      

    Note too that as, "External SPI devices are added - line capacitance adds - and best results are likely to demand a, "Reduction in SPI clock speed."      Firm/I always recommend that one "start at low-speed - and only gradually & incrementally increase - noting the impact upon the device "furthest" from the MCU...

  • Hi,

    I see your point to add decoder and sacrifice 1 GPIO port to select first or second SPI device (in case of 2 devices). In that case both devices are connected after the decoder.

    I am just wandering how is it implemented in the TM4C129X Development Board, p/n DK-TM4C129X.
    1) EEPROM is using dedicated CS pin SSI3SS,
    2) SD card CS is connected to port PH4 (pin R3)

    I am missing some point, how SW could manage that port and simultaneously prevent SSI3SS signal to select the EEPROM.

    My responsibility is new board design, so I need more understanding resources I have.

    Sincerely,

    Anatoli R.
  • Anatoli Rapoport said:
    I am missing some point, how SW could manage that port and simultaneously prevent SSI3SS signal to select the EEPROM.

    Don't configure the SSI to use the built-in slave select.

    Seriously, that not only solves this issue but prevents others. The on-chip implementation is more trouble than it's worth.

    Robert

  • Poster Robert - after demanding that (cb1 shovel snow from his walkway) now "beats me to this answer."

    In the case poster (now) presents - the use of any (added) chip makes (little) sense - individual GPIO - again w/"one and only one" active as SPI CS at a time - proves fully sufficient for your requirement. (when the number of SPI devices exceeds four - then the mux/decode IC - employing just 3 GPIO - may service up to 8 SPI CS...)

    Robert may note that I've (almost) cleared a path to his long, descending street/driveway. (it is not (always) wise to "lose any bet" - especially when "shoveling" is dictated as the outcome...)

  • Hi Robert,

    I looked in the Data Sheet how to configure SSI not to use built-in slave. Could you point on some documentation in that regard?

    All the best,

    Anatoli

  • Anatoli Rapoport said:
    I looked in the Data Sheet how to configure SSI not to use built-in slave. Could you point on some documentation in that regard?

    Nothing explicit.

    Hoever you are overthinking the problem, the way to program not to use the slave select is to not configure it to use the slave select. If you are as wary as I am about the narrow view of the IC designers you can also avoid using the I/O pin that the slave select is on.

    Robert

  • Hello Anatoli,

    As Robert said, it's just about configuring the SSI module to not use the slave select pin on MCU's.

    Hello Robert,

    Even us vendors have some MCU's or applications where we don't trust the built-in SSI or SPI to handle the slave select perfectly. :) Back in my NFC days, our example codes using MSP430 used a GPIO for SS for simplicity of being able to control the timings.
  • Hi All,

    Thank you for answers.

    I think I'll implement the external decoder solution proposed by cb1_mobile.

    Sincerely,

    Anatoli R.

  • Good that - might you additionally, "Click upon that specific (external mux/decode) post" - as "it" was the one which RESOLVED your issue?

    This method "best enables" such "external device expansion" - while offering the (only) "clear design safeguard" of, "One and only one - external device's Selection!"     (all other methods "fail" in that regard...)