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.

RTOS/CC1310: SPI Master slave comms between two launchpads

Part Number: CC1310

Tool/software: TI-RTOS

I've configured one of the launchpads as the SPI Master and the other as a slave and am trying to transmit info between them. I'm running them in callback mode. According to what I've read, the SPI slave is supposed to call SPI_transfer() BEFORE the master starts transmitting.

In my case, however, I get errors if I turn the master off while it's transmitting to the slave (the slave starts receiving an array with more incorrect data). Every subsequent SPI transmission is this same erroneous array.

However, I fixed this by having a delay of 2 seconds in the SPI slave launchpad so that when the two devices are powered on at the same time, the SPI slave starts AFTER the master starts transmitting; I do not get errors this way. 

Any comments/thoughts on this would be very much appreciated.

Kind regards,

Savinda

  • Where did you read that the slave must start its transfer first?

    One thing to always observe in callback mode is that subsequent SPI_transfer() calls MUST NOT OCCUR until the previous transfer is complete (ie the callback has been called). The internal transfer operation operates on the buffer passed to it in the SPI_transfer() call, not a copy of it. Therefore the integrity of the buffer must be maintained until the transfer is complete.

    Alan
  • Hi Alan, thanks for the quick reply. I read it in the SPI.h file reference document in the simplelink installation directory under "Overview":

    The SPI protocol does not account for a built-in handshaking mechanism and neither does this SPI driver. Therefore, when operating in SPI_SLAVE mode, the application must provide such a mechanism to ensure that the SPI slave is ready for the SPI master. The SPI slave must call SPI_transfer() before the SPI master starts transmitting. Some example application mechanisms could include:
    Timed delays on the SPI master to guarantee the SPI slave is ready for a SPI transaction.
    A form of GPIO flow control from the slave to the SPI master to notify the master when ready."
  • From your explanation maybe what happens is that when I power cycle the master whilst the slave is in the middle of a transfer the buffer integrity is lost and the only way of fixing this is by power cycling the slave?