Does TIVA support hardware SSI for multiple devices (slaves) on same port:

For many years now - folks here (and predecessor forum) have, "freed" the normal "SPI_FSS" (chip select) pin to better ease their SPI operations.  I don't recall that simple act - done correctly - having caused a fault.  Usual suspect in such event is not that slave select pin - instead you've not properly, first enabled that particular SSI module!

Potential "gotchas" lurk when talking to multiple SPI slaves - how certain are you that their, "data formats" are equal?  If not - you experience the "joy" of "on the fly" MCU SSI reconfig - to meet the varying tastes of the SSI slaves.

As you suggest - you'll have to bit-bang the SSI-CS line(s) - but if you properly choose the MCU's SSI mode/data format you may employ the great bulk of "normal" SSI data transfer as delivered by your MCU.  Another (potential) issue - you must insure that each/every "non-addressed" slave SSI output "really" enters hi-Z when inactive.  (I'd not assume this to be the case - check it.)   And always best to follow/employ KISS - start with one SSI slave at a time - do not tie all 3 together!  Get each one to work independently - then try for 2 - and only then for all 3.  (not to ask just, "how I know?"

I certainly agree in principal.  I know that all three work together properly, because they do with an MSP430 (e.g. without the cs integrated into the SSI / spi) and I have the first one working with bit-bang.

It's tempting to go directly for the, "sure to work, fast/efficient, kitchen-sink" approach.  But - too often - it fails.  And - with so many variables in play - resolution is made more complex and lasts longer.

Unclear the extent of your, "bit-bang."  In most all SPI situations you can find one of the MCU's SSI data formats to "near match" that of your slave.  That limits the bit-bang to "only" the SSI CS lines, even when those exist in multiple.

You're silent as regards the concern for your routing of each SSI Slave's output signal back to the MCU master.  We've noted problems when the slave does not properly release that line when inactive - especially when that effect is transitory...

And - best for last - had you properly enabled your SSI Peripheral?   That's the usual "escape" from MCU faults...

This is a purchased board that is related to a board used in one of the TI msp430 labs.  It works with hardware SPI driver on the MSP430.  So it would seem reasonable and helpful to ask if the more advanced hardware can decouple the chip select line.

Under the being helpful.  I have spent 12 hours with multiple oscilloscopes and all the reference manuals and found that the TIVAWare SSI library works if you enable the Clock, RX, and TX pins ass SSI and the CS and GPIO.  It leaves the chip select up to you.  So it is possible.  I found that the timing of the CS is tricky and requires the use of a while (SSIBusy (SSI2_BASE)), an interrupt, or clever timing (i.e. you know the speed of the SSI so you could calculate a delay).  

Bit-Banging code

void writeData(u_char data) {
LCD_SELECT;
for (u_char c = 0; c < 8; c++) {
    (data & 0x80) ? (TX_LINE_HI) : (TX_LINE_LO);
    PULSE_CLOCK;
    data <<= 1;
  }

LCD_DESELECT;
}

I will update the hardware SSI code when I move it from TI-RTOS to TIVAWARE as the interrupts are currently overlapping and I'm out of time on this project right now.

Michae