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.

CCS/TM4C1237H6PM: SSI Slave Mode No Replies After the First Transmission

Part Number: TM4C1237H6PM

Tool/software: Code Composer Studio

Hello,

I am trying to implement a SSI slave where I read 1 byte commands and return the result when the next command is received. 

The problem I am facing is after the first transmission I receive zeroes even If I put new data to the TX buffers.

Also when I poll GetDataNonBlocking It shows RX buffer to be empty even though on the logic analyzer I see the master sending the data.

To check the operation I put 2 bytes in the TX buffer and send 2 commands waiting sometime in between.

Here is my configuration: 

And I tried to read using 

SPIDataGet and the nonblocking version like this 

while(!SSIDataGetNonBlocking(SSI0_BASE, &ret_val)){}

After the first receive this is the status of the flags: 

As it is seen the transmit fifo still has data but because SSI is somehow stuck that data never gets sent.

If I reconfigure the SPI after the first transmission I see both of the values on transfers so I am not sure why the issue gets the module stuck. 

Does anyone have any clue on why the module might be getting stuck? 

Thanks for reading.

  • Hello Tuna,

    The API's you show are only for receiving, can you share what is being done for the transmit as well? Without that it's hard for me understand the whole picture.

    Also couple additional questions:

    Is this setup between two TM4C devices or another host device and the TM4C?

    Your clock setting for the SPI is unconventional, what's the reason for the value chosen over a flat 1 MHz?

  • Hello Ralph,

    Thanks for the reply. 

    The communication is between a Raspberry Pi Model 3B+ and the tiva chip.

    The SPIDev library for the Pi was the reason why for the unconventional value. 

    I just realized there was a problem on the FSS connection which created the issue. 

    My guess is that the chip though it was still sending data over and waiting for the transmission to finish.

    Now I get the expected behaviour. 

    Best Regards,

    Tuna Bicim