Unable to send more then 8 bits on SSI

The device I am communicating with requires a 16 bit word with CS held low.  I don't care if I send one 16 bit or two 8 bit words.

I just need to hold CS low the whole time.

Oddly, if I don't set the CS line low and sent the bytes, they both are sent.  It is as if the CS line is somehow tied to the SSI function.

I may have to use a different line for CS.

Thanks

I know, but the SSI FIFO does fill up and may perhaps block.

    GPIO_PORTF_DATA_R &= ~(0x4u);		/* Select chip		*/
    for( index=0u;index<2u; index++) {
         SSIDataPut(SSI0_BASE, ~out_data[index]);
         }
....

    SSIDataPut(SSI0_BASE, ~out_control);

	      	/* Wait until SSI done */
    while(SSIBusy(SSI0_BASE)) {
        }

    GPIO_PORTF_DATA_R |= 0x4u;			/* De-select chip	*/

    for( index=0u; index<3u; index++) {
         SSIDataGet(SSI0_BASE, &data_in[index]);
         }

Above is extracts from my SPI write, data_in is a dummy just to flush the buffer. At the very least I need to also perform reads from other devices so I must clear the buffer.  Even if I didn't now it would be a could code hygiene practice.

Checking my init, I see I do assign FSS even though I don't use it.

    		/* Configure SPI pin muxing */
         GPIOPinConfigure(GPIO_PA2_SSI0CLK);	
         GPIOPinConfigure(GPIO_PA3_SSI0FSS);	
         GPIOPinConfigure(GPIO_PA4_SSI0RX);	
         GPIOPinConfigure(GPIO_PA5_SSI0TX);	
    		/* Configure SSI to use pins */
         GPIOPinTypeSSI( GPIO_PORTA_BASE, GPIO_PIN_5 | GPIO_PIN_4 | GPIO_PIN_3 |
    		GPIO_PIN_2);

The FSS really shouldn't come into play if it's not used. Maybe Amit or Sai can comment on the TI implementation?

Robert

Here is an example of my output using 16 bit.   /CS is PA3

The code:

// Enable and configure SSI0
MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI0);

MAP_GPIOPinConfigure(GPIO_PA2_SSI0CLK);
MAP_GPIOPinConfigure(GPIO_PA4_SSI0XDAT0);
MAP_GPIOPinConfigure(GPIO_PA3_SSI0FSS);
MAP_GPIOPinConfigure(GPIO_PA5_SSI0XDAT1);
// Setup SSI Port for Touch Screen
MAP_GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_5 | GPIO_PIN_4 | GPIO_PIN_3 | GPIO_PIN_2);

MAP_SSIConfigSetExpClk(SSI0_BASE, g_ui32SysClock, SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER, 4000000, 16);
MAP_SSIEnable(SSI0_BASE);

MAP_SSIDataPut(SSI0_BASE, 0x02F0);

while ( MAP_SSIBusy(SSI0_BASE)) {
}

The output:

Okay.    Got it!

See if you can tell by looking at this screen shot why it worked.

Sam Virgillo97352 said:

Well if you haven't guessed by looking at the screenshot, the MISO line is low. Due to a wiring error the line was being held high and the MCU was waiting for a response which is why the second byte never got set

Um, that makes no sense to me the SPI peripheral shouldn't care about the state of the MISO line. Pretty much by definition.  After all how would you distinguish between a returned value being all high and the line being stuck?

The miss-wiring maybe affected something else?

Robert

May I (Like) & "second,"  poster Robert's statement.

We've past used Display Controllers - which had (both) SPI TX & SPI RX capability - and "TX only" operation succeeded!

I2C - w/the dreaded ACK/NAK - indeed requires a (proper) bit return/presentation - but "not so" under SPI...

My "bet" - while you surely altered that cabling - the "return" of any data bit did NOT (then) enable a (desired) 16 bit transmission.

During development - it's "usual" for code changes to occur. Either that - or another impact of your hook-up efforts - may prove a better explanation of your "mystery"...

Wise man once said, "We truly understand something when we can "Break - and then FIX" it - not when it runs by itself - minus our understanding..."

Your reestablishment of the original (errant) connection would prove of interest!   (assumes that you (really) want to know/master...)

Sam Virgillo97352 said:

When I forced that line low even before fixing the wiring error, it worked correctly.

May I dispute that statement as, "causal nexus?"

Firm/I have long employed SPI-based, flash memories for data, font & graphic image storage.   And often - "ALL NON-ZERO bytes and/or 16 bit words" are returned.   And the SPI memory works - and we log 0xFFFF.

Have you a 2nd board to test/verify?   I'm (almost) sensing that you've a "bad pin" or "external device/signal" on "MISO" - yet that (fails terribly) to explain how your first 8 bits pass untarnished...

Seems most fitting to carefully "monitor" MISO - it may be rising in voltage beyond its spec - and the "grounding exercise" restores it to acceptable levels.   (for a brief period - that's why this "fix" may NOT be what it seems...