• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 549 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1237H6PGE: SSI Slave for simple command-response protocols

Aaron Mills
Prodigy 90 points
Part Number: TM4C1237H6PGE

I'm trying to use the TM4C as a SPI slave which will generate responses to queries/commands issued by a separate master microcontroller. I'm running in SPI mode 1 so that I don't need  CS asserted after every byte.

For example, the master would send a frame: [cmd1, dummy] and simultaneously receive [dummy, cmd1_response]. I think this is an extremely common task but the SSI in the TM4C appears to make this very hard in slave mode.

The problem is the 8 byte FIFO cannot be bypassed or disabled and the fact that for slave, there are really only three useful interrupts, but I can't see any combination of them which are really useful here due to the FIFO:

  • RX FIFO half full or more: will only trigger after at least 4 bytes are in the fifo. Useless here because that would only trigger by the time the 2nd command frame has been completely sent by Master. Meanwhile the slave has been busy transmitting whatever was in the FIFO, which obviously cannot have any relation to the commands. 
  • TX FIFO half full or less:  it will immediately trigger 4 times before you've even had a chance to receive the first command ????
  • RX timeout: also useless because, again, by the time it triggers you have been given no chance to actually read the command; at best you've already received the two bytes and send back two (random) response bytes. 
  • Also the most potentially useful interrupt, the EOT interrupt, is only available in Master mode!!

Am I missing something here? I suppose it may be possible if you force the command to be four bytes, and always have the slave initially send out 4 wasted/junk bytes at the start of frame, but these constraints seems disastrous when you have no control over the Master's protocol ?

  • 0
    TI__Guru**** 158815 points
    Hi,
    Please check your external SPI device on the command and response exchange. When the master sends a [cmd1, dummy] then I think it is likely it is expecting to receive dummy data as well. If the master is expecting to receive a valid data such as an acknowledge frame then you will need to prepare the data to be returned by the slave in the slave's TX FIFO ahead of time before the master sends its SPICLK. This is how it works for the Slave SPI. The slave SPI will only transmit when it sees the master clock. Before the master clock is initiated by the master, the slave must prepare the data beforehand.
  • 0 in reply to Charles Tsai
    Prodigy 90 points

    Hi Charles,

    I understand that the slave must prepare at least one response byte in advance, before the Master sends the first clock. It could be arbitrary fill byte or some generic status byte which all commands get back as a first byte. But eventually slave code needs to actually read the command and respond to it.

    What I'm struggling with is what kind of interrupt scheme allows that. For example if Master sends  [cmd1, dummy]  and RXFF and RXTO interrupt is active, the interrupt will occur after the Master has already sent the two bytes. Any response that the slave "sends" will actually just be enqueued and come out during the next command. So the response is always delayed by a command because of the FIFO and coarse grained interrupt (at best, every 4 bytes). How to avoid that?

  • 0 in reply to Aaron Mills
    TI__Guru**** 158815 points
    Hi Aaron,
    I think to work around the SSI limitation (as the FIFO cannot be disabled), you will need to somehow establish a protocol of data exchange between the master and the slave that defines the command as a 4-byte sequence. For example, the master may first send a command byte followed with 3 dummy bytes. After these four bytes are received, the slave is interrupted and in the ISR the slave will decode the command to determine the number of bytes to return and preload the TX FIFO with these data. Since the master knows what command was sent earlier it knows how many bytes of data it is going to receive from the slave. Let's say you send a command (a command is one command byte + 3 dummy bytes) that is to read 8 bytes of memory location from the slave. The slave will decode the command in the ISR and know that it needs to read 8 bytes of memory. It will read the 8 bytes from the memory and write them to the TX FIFO. Since the master is expecting to read 8 bytes from the slave the master will generate 8 bytes of SPICLK. During these 8 bytes the master can send either dummy data or some meaning command/data. Even though during these 8 bytes of transmission, the slave will be interrupted twice but the slave may decode the received data to be invalid or dummy command and choose to do nothing in the ISR. You can add more intelligence to your overall protocol of data exchange between the master and slave.

    Another option is to use polling mode by polling the Receive FIFO not empty. This is similar to the FIFO is disabled but you need to keep the CPU polling all the time.