MSPM0L1306: SPI RX FIFO not empty after TX?

SPI is intrinsically bi-directional. For each Tx byte, there is an Rx byte, even if you're not interested in it. Those bytes will pile up in the Rx FIFO until you read them out.

It's common for the first few Tx bytes of a transaction to be a request to the slave, followed by dummy bytes for the slave to respond. You need to account for the first few (unwanted) Rx bytes in the Rx FIFO when you're fetching the results.

This is also true on the MSP430, but there the Rx FIFO is only 1 byte.

For short transactions, I usually write a little function that writes a Tx byte then immediately reads the corresponding Rx byte; the caller is free to use or throw away the Rx byte, but I always know the correspondence. In this case, it might look something like:

uint8_t spix(uint8_t c) {
  DL_SPI_transmitDataBlocking8(SPI_0_INST, c);
  c = DL_SPI_receiveDataBlocking8(SPI_0_INST);
  return(c);
}

which you can use something like:

> (void)spix(WREN);  // Write Enable, ignore result

or

> gRxPacket[i] =spix(0xFF); // send dummy byte, capture result

Hi Bruce, so if I send a byte and expect to receive one, I must do 2 reads (one for the unwanted Rx byte and one for the response I was expecting)? Is the value of the unwanted Rx byte known (0x00 or 0xFF for example)? I suppose that when I send a dummy byte to generate a clock signal so the slave can respond, an unwanted Rx byte is received as well?

Thanks for your reply.