SPI slave mode details

[CraigMcQueen]

I have a number of questions about SPI slave mode on the LPC11U6x, which are not answered in the user manual. Most of them are concerned with the correct TX of data (which is more challenging for the slave side of SPI).

• If the TX FIFO is empty, what is transmitted on MISO -- 0x00, 0xFF, or a repeat of the previous byte?
• If SSEL is deasserted while the TX FIFO still contains data, is the TX FIFO flushed?
• Can I flush the TX FIFO?
• Can I preload the TX FIFO with data while SSEL line is idle?
• Is it possible to detect TX underflow?
• Can I get an interrupt as soon as the SSEL line is asserted? (so that I know I need to prepare data to be read). Either from the SSP, or from the PINT.
  • Is it possible to configure a pin for PINT if the pin is configured for a function other than GPIO? Or, would I need to connect the SSEL line to a second pin to provide the PINT functionality?

[kerryzhou]

3  About the interrupt adequately kept up with supplying TX data, it also depends on the  SPI clock speed.

You need to choose the proper baudrate which mee you demand, and the also make sure the interrupt have enough time to process it.

4 I also think you can use the SPI data to indicate the ssp data frame is ending.

5 Design the software function to realize it.

6 Software can flush it when the TX fifo is empty.

If you still have question about it, please let me know.

If your question is solved, please help to mark the correct answer, just to close this case.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[kerryzhou]

Hi Craig McQueen,

      Yes, the chip manual didn't describe that details which you mentioned, but actually, if you test the chip SPI, you will easy to know it.

     Now, answer your several questions:
 1   If the TX FIFO is empty, what is transmitted on MISO -- 0x00, 0xFF, or a repeat of the previous byte?
= I have tested it, it should be 0X00 if none data input to the transmit buffer, this is my test result

The yellow wave is the MISO, you can find it is the 0x00.

 2   If SSEL is deasserted while the TX FIFO still contains data, is the TX FIFO flushed?

=

If the slave SSEL is not selected, I think the TX FIFO won't be flushed.

 3  Can I flush the TX FIFO?

= You can write the TX FIFO, then when the Slave is selected, and the SPI_SCK come in, the TX FIFO data will be transfered.

 4   Can I preload the TX FIFO with data while SSEL line is idle?

== Of course you can, just as I have said, you can write the data to the TX FIFO at first, then just wait the master's signal.

 5   Is it possible to detect TX underflow?

==From the user manual, I find IMSC[TXIM]: Software should set this bit to enable interrupt when the Tx FIFO is at least half empty.

  This may useful to you.

 6   Can I get an interrupt as soon as the SSEL line is asserted? (so that I know I need to prepare data to be read). Either from the SSP, or from the PINT.

== You don't need to detect SSEL, you just need to detect the receive FIFO buffer, more details, you can check the SPI register.

 7  Is it possible to configure a pin for PINT if the pin is configured for a function other than GPIO? Or, would I need to connect the SSEL line to a second pin to provide the PINT functionality?
==SSP module hardware don't have the SSEL interrupt directly, if you want to get the SSEL pin interrupt, you can connect it to the second PINT pin.

Wish it helps you!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[CraigMcQueen]

Kerry Zhou wrote:

 1   If the TX FIFO is empty, what is transmitted on MISO -- 0x00, 0xFF, or a repeat of the previous byte?

= I have tested it, it should be 0X00 if none data input to the transmit buffer, this is my test result

I have tested this further. If I transmit data, then stop writing to TX FIFO, and the TX FIFO underflows, then it appears that the SPI repeatedly transmits whatever was the 8th-most-recent byte sent (I guess because that's the next byte in an 8-byte circular FIFO).

E.g., if I write to the TX FIFO with:

0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A

... and then stop writing to the TX FIFO, but the SPI master continues clocking out, then it will transmit:

0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x03, 0x03, 0x03, 0x03, ...

That's not ideal, but now that I know it, I'll work with that.

[CraigMcQueen]

Thank you for your response. It answers most of my questions.

The reason I ask these questions is, for many SPI applications, we want SSEL not merely to enable data transfer, but to frame a transaction. That is, SSEL asserted marks the start of the transaction, and SSEL deasserted marks the end of the transaction. That is how many SPI devices operate (EEPROM, Flash memory, SPI MAC+PHY chips, etc).

When the LPC11U6x is a master device connecting to something like a Flash chip, then firmware can do explicit framing by manually controlling a chip select as a GPIO output. So that's fine.

When LPC11U6x is a slave device, then the SSPx doesn't provide much help with framing an SPI transaction. What would be good is:

* Start-of-frame (SSEL asserted) and end-of-frame (SSEL deasserted) are indicated by an SSPx interrupt, and ideally by data markers in the RX FIFO so the firmware can know the transaction boundaries.

* For a responsive transaction (not requiring multiple dummy bytes between master's "command" and slave's response), the RX and TX interrupts can have a configurable FIFO threshold.

* To know if the interrupt hasn't adequately kept up with supplying TX data, a TX underflow status/interrupt.

* Optional automatic flush of TX FIFO at the end of the transaction (SSEL deasserted), so that any unread TX data is discarded and not included in the following transaction.

* Capability to manually flush the TX FIFO if the firmware wants to for some reason.

* Setting a default value to TX in case the TX FIFO is empty (e.g., it might be useful to always transmit 0xFF if the TX FIFO is empty).

These added capabilities would enhance the usefulness of the SSPx, for handling SPI transfers that are "framed" by chip-select.

[kerryzhou]

Hi Craig,

   The LPC11U68 SPI module hardware won't be changed any more.

  So, the detail SSP function can use the software to realize the detail usage.

1. If you really need to detect the SSEL, you can connect it to another PIN interrupt.

   But, I think it is not necessary, you totally can use the SPI data to detect the start, you can define the SPI data protocol by yoursef between the master and the slave.

2. Whether have dummy bytes, it is determined by your Master and slave data protocol.

  About the FIFO threshold, you can use the softeware to detect it in the SSP interrupt.

[CraigMcQueen]

Kerry Zhou wrote:

   The LPC11U68 SPI module hardware won't be changed any more.

Yes, I understand that. But I hope a future NXP processor could have an improved SSP module that provides enhanced slave-mode SPI functionality.