TM4C123GH6PM: SSIDataGet blocking for SPI slave

We got this to work by connecting the FSS pins between the two boards. But we still have an issue, this needs to work without FSS. We're interfacing to inertial units using SDLC / SPI. We currently use MSP430s for this, they work fine, but we want to upgrade to the TM4Cs. The interface there only has clock and RX to the microcontrollers. Do all the MOTO modes require FSS? Is there a mode that doesn't? 

Thank you Charles, I think this helps. Please don't lock the thread yet.

The person who did the MSP430 implementation is gone. Slave select is not connected there. The pin for that is multi-function and one of the other functions is selected. What we're guessing, based on your answer, is slave select when not selected is in a state that tells the slave that data is always valid. The software matches that, it's reading continually, including all filler between actual data. ?!

Hi David,

  When you write back to this thread, the thread will automatically set the status to open and I will be notified. 

I dug deeper into the existing MSP430 design that is working. That has an STE (slave transmit enable) for SPI in addition to clock and data. So STE is the same as Fss on the TM4C? The MSP430 has a 3-pin mode in which STE is not used, and that is the mode we're using.

Per your response FSS is required for a SPI slave on the TM4C. So there is no equivalent to the 3-pin mode on the MSP430?

On the pair of TM4C evaluation boards, running SPI master on one and SPI slave on the other, it worked in MOTO_MODE_3 with the FSS just grounded on the slave, not connected to the boards. But tried that on SPI slave connected to the sensor we're trying to listen to and the data is still not right. We have the sensor output split to go to both an MSP430 and a TM4C, the MSP430 still reads the data correctly.

Hi,

David Honcik said:

But tried that on SPI slave connected to the sensor we're trying to listen to and the data is still not right.

Can you elaborate what is not right? 

David Honcik said:

Per your response FSS is required for a SPI slave on the TM4C. So there is no equivalent to the 3-pin mode on the MSP430?

Reading the datasheet again, it has the below description about mode 0 and mode 2. You will need Fss for these two modes. 

However, in the case of continuous back-to-back transmissions, the SSInFss signal must be pulsed
High between each data word transfer because the slave select pin freezes the data in its serial
peripheral register and does not allow it to be altered if the SPH bit is clear. Therefore, the master
device must raise the SSInFss pin of the slave device between each data transfer to enable the
serial peripheral data write. On completion of the continuous transfer, the SSInFss pin is returned
to its idle state one SSInClk period after the last bit has been captured.

David Honcik said:

On the pair of TM4C evaluation boards, running SPI master on one and SPI slave on the other, it worked in MOTO_MODE_3 with the FSS just grounded on the slave, not connected to the boards

For mode 1 and mode 3, below is the description. 

uous back-to-back transmissions, the SSInFss pin remains in its active Low state until
the final bit of the last word has been captured and then returns to its idle state as described above.

For continuous back-to-back transfers, the SSInFss pin is held Low between successive data words
and termination is the same as that of the single word transfer.

Can you elaborate what is not right? 

A couple of things. The incoming data uses SDLC, there is supposed to be a sync at start and end of actual data composed of six 1 bits preceded and followed by a zero bit. The message between those is about 30 bytes. In between messages and sync markers are filled with xFF. I took the MSP430 code over to the TM4C as closely as possible. It finds start and end sync on the MSP430, it only works occasionally on the TM4C. Most of the time on the TM4C it doesn't find sync, some of the time it does but early, other times it's close.

We also modified the hardware we're working with so that sensor clock and RX output goes to both an MSP430 and a TM4C. I put software on both to simply take SPI input and transmit out a UART after discarding the xFF filler. And recorded both at the same time on a PC. It's different. I can find a unique byte sequence in the MSP430 output, and can't find same in TM4C output. And vice versa

Both of the above are in MOTO_MODE_3 with FSS grounded.  From the description of mode 1 & 3 it sounds like that should work? But there's noise coming in from something.

Small update. We checked the UCA control registers in the MSP430. They're set to clock polarity 0, clock phase 1, 8-bit, 3-pin SPI slave. So we retested on the TM4C using MOTO_MODE_1, incoming data is still not clean.

Hi,

  It is true that between bytes the Fss (chip select) is held low. However, I wonder with Fss tied to GND, the slave state machine does not know when is the correct beginning of a transfer.  

If the QSSI is enabled and valid data is in the transmit FIFO, the start of transmission is signified
by the SSInFss master signal being driven Low. The master SSInDAT0/SSInTX output is enabled.
After an additional one-half SSInClk period, both master and slave valid data are enabled onto
their respective transmission lines. At the same time, the SSInClk is enabled with a rising edge
transition.

David Honcik said:

It finds start and end sync on the MSP430, it only works occasionally on the TM4C. Most of the time on the TM4C it doesn't find sync, some of the time it does but early, other times it's close.

Do you see any error in SSI such as Receive Timeout ?

David Honcik said:

The message between those is about 30 bytes. In between messages and sync markers are filled with xFF.

What is the duration between bytes within a message? How long is the gap between message? Since the Fss is tied to ground, please make sure time-out  counter is reset o

The RX FIFO has an associated time-out counter which starts to down count at the same time the
RX FIFO is flagged as not empty by the RNE bit in the SSISR register. The counter is reset any time 

a new or next byte is written to the RX FIFO, thus the counter will continue to count down to zero
unless there is new activity. The time-out period is 32 periods based on the period of SSInClk.
When the counter reaches zero, a time-out interrupt bit, RTRIS, is set in the SSIRIS register. The
time-out interrupt can be cleared by writing a 1 to the RTIC bit of the SSI Interrupt Clear (SSIIC)
register or by emptying the RX FIFO. If the interrupt is cleared and there is residual data left in the
RX FIFO or new data entries have been written, the timer count down initiates and the interrupt will
be reasserted after 32 periods have been counted.

Before you start the slave, did you first clear the receive FIFO?

//
// Read any residual data from the SSI port. This makes sure the receive
// FIFOs are empty, so we don't read any unwanted junk. This is done here
// because the SPI SSI mode is full-duplex, which allows you to send and
// receive at the same time. The SSIDataGetNonBlocking function returns
// "true" when data was returned, and "false" when no data was returned.
// The "non-blocking" function checks if there is any data in the receive
// FIFO and does not "hang" if there isn't.
//
while(SSIDataGetNonBlocking(SSI0_BASE, &pui32DataRx[0]))
{
}

I tried to upload images of the clock & data lines from a scope, they look like they upload but then nothing shows up in the preview pane.

The messages come out at ~400 Hz. Clock line from then sensor (SPI master) is1.0152 MHz, and is always running. On the scope you can see each message is ~0.25 milliseconds long, then the data line is high for 2.25 milliseconds until the next message. And you can see that rising edge of the clock is centered on each data bit.

I don't see receive timeouts. I'm using the blocking SSI call to read data. I added the following preceding the reads :

            nInterruptStatus = SSIIntStatus(SSI1_BASE, false);
            if ((nInterruptStatus & SSI_RXTO) != 0)
            {
                nTimeoutCount++;
            }
            SSIDataGet(SSI1_BASE, &nData);

I let that run for awhile in the debugger then break and timeout count is zero. And I'd expect that, because the clock is always there, and the data line is high between messages, the reads between messages are returning 0xFF, and there is always something to read.

Yes I do clear the receive FIFO before starting the slave, that is at the bottom of InitializeSSI1 in the code samples I originally uploaded. I am doing that after enabling SSI1, that's how it was done in all the samples I've seen.

Hi,

  You can drag the file into the editor. If you still have problem then capture the images into a file and then drag the file over. It is good to see the images but with your description I should be clear about the questions I asked. 

  I have some questions:

  - Does the slave fail to capture the first message correctly or it is always some later messages?

  - If you focus just on the the first message, does the slave correctly decode the start (01111110b) and end (01111110b) of the message?

  - I think the answers to above questions will help answer if the problem is due to the absence of Fss - where the slave is unable to recognize the first bit of a SPI transfer.

  - I will suggest you send out the received data on the TX pin instead of sending out dummy '0'. This way you can view both RX and TX on a logic analyzer. This is easier to see where TX and RX starts to deviate. 

I see the images but this is just what is sent by the master. I can't really decipher it. Can you please answer the questions I asked earlier. Logic analyzer will greatly facilitate debugging especially for stream of messages. 

I modified the code to write out to SPI Tx each byte right after it was received by SSIDataGet. Also have switched back to MOTO_MODE_3, that matches TM4C documentation best, slave select low and data bits sampled on rising clock edge.

Focusing on the first message. Messages are 31 to 33 bytes in length. I did 10 runs in the debugger, with a breakpoint set where the code either thinks it has seen both start and end markers for a message, or knows it has gone too far (> 60 bytes) without finding the end marker. Just went to the first breakpoint, the first message. Only one of the runs looked like it might be legitimate, the rest were either stopped after 60 bytes or early.

I'm also running the same code on the MSP430, on the same input. It finds both start and end markers every time, with end always coming 31 to 33 bytes after start.

We do not have a logic analyzer. If you think that's critical we'll find a way. I really appreciate your help.

I think there's a break in the case. I wrote test applications to do what you suggested, simply look for the start marker. I did the MSP430 first, it worked fine. Then I did the TM4C, with identical scanning code from the MSP430. It didn't work. But ... then I check endianess of the bit stream. On the TM4C the bits are inverted, MSB is what LSB is on the MSP430. I switched the TM4C to invert scanning per that, and it's successfully finding start markers now. I checked the MSB/LSB last week, but must have made a mistake. Now I'm going to look for the trailing sync to see if that works.

Hi David,

  That is a great find. Looks like you have narrowed the discrepancy between Tiva and MSP430. Let us know if you are able to scan the trailing sync successfully. 

I'm now reliably getting trailing sync as well. Thank you so much for your help!

Here's a summary for anyone that ends up here.

We are doing a hardware upgrade, and plan to use TM4Cs to replace MSP430s. We're interfacing with an IMU that uses SDLC and is a SPI master. We are only connected to SPI lines for clock and RX (TX from the IMU). There are two other lines involved, TX and FSS. We leave TX unconnected, that works on both the MSP430 and TM4C. The clock out of the IMU is always on.

The MSP430 data sheet refers to the 4th SPI line as STE, not FSS, And we're using a 3-pin mode that ignores it. So on the MSP430 that is unconnected. It works fine, with the oddity that there is always data to read. Between actual data frames the lines are tri-stated, which reads as 0xFFs.

To get similar code to work on the TM4C, we didn't find a 3-pin mode. What seems to be working is running in SSI_FRF_MOTO_MODE_3 with FSS grounded. For MOTO_MODE_3, FSS is low when data is valid. Grounding it appears to tell SPI slave in Mode 3 that data is always valid. With that we get 0xFF filler between data as we do on the MSP430. And the final piece of the puzzle was the bit stream was inverted on the TM4C from what it was on the MSP430. Taking that into account we are now finding the SDLC start and end markers bracketing data in the bit stream. Also for what it's worth we're using SSI_MODE_SLAVE_OD since we only listen :

SSIConfigSetExpClk(SSI1_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_3, SSI_MODE_SLAVE_OD, 1000000, 8);