SSP in SPI slave mode: How to flush the transmit FIFO?

[lpcware]

Content originally posted in LPCWare by MindBender on Wed Jul 29 05:01:03 MST 2015
The SSP peripheral doesn't seem to clear the transmit FIFO upon deselection. When the SPI master request information, but prematurely aborts reading, a data of a consecutive command will be preceded by residual data in the transmit FIFO. Is there any way to manually flush the transmit FIFO?

[jtmiii]

From the wayback machine - found the link above...

https://web.archive.org/web/20141023230925/www.lpcware.com/content/forum/lpc1114-ssp-tx-fifo-clear

[CraigMcQueen]

It appears that the SSPx in many LPC chips is an ARM Primecell PL022. There are test registers, which can be used to read the TX FIFO, thus could be used to flush it.

[lpcware]

Content originally posted in LPCWare by DF9DQ on Tue May 03 08:44:17 MST 2016
SPI is no well-defined standard, but if you wanted to name one then it would have to be the original Motorola spec: https://web.archive.org/web/20150413003534/http://www.ee.nmt.edu/~teare/ee308l/datasheets/S12SPIV3.p...

That specification describes the two modes with CPHA=0 as requiring the slave select line to become inactive between frames, while in the two modes with CPHA=1 the slave select line is allowed to stay active continously. ARM's Primecell PL022 (which is what you find in NXP chips) strictly enforces the "SSEL must go inactive between frames" rule for CPHA=0.

As you rightly said, there are many devices out there violating this aspect of the Motorola specification. So I see the reason for the incompatibility more on the part of these devices, but you might also blame ARM for their intolerance  :)

[lpcware]

Content originally posted in LPCWare by MindBender on Tue May 03 05:56:46 MST 2016
I had found that work-around before, but dismissed it as too sloppy. However, after you hint I have tried it anyway, and it seems to work. So thanks for the reminder.

I do agree that this should go into the errata sheet, but perhaps it's even better to revise the SSP peripheral entirely, because it is seriously borked: In two of the four possible SPI modes no more than one byte can be transferred per !SSEL active period. These two modes are CPOL=0 CPHA=0 (Mode 0) and CPOL=1 CPHA=0 (Mode 2). Since many SPI uses the first of these two modes, and often multiple bytes must be transferred, !SSEL must be raised in between bytes. We use the SSP peripheral as a slave device and the master doesn't deactivate !SSEL in between bytes. This is all written in the manual, but still it's a really inconvenient short coming, because in many protocols !SSEL is also used for framing.

We work around this short coming by using an interrupt-capable gpio pin as our !SSEL on the bus, and another gpio pin to manipulate the SSP !SSEL after each byte.

[lpcware]

Content originally posted in LPCWare by firmwear on Tue Jan 26 01:11:13 MST 2016
https://www.lpcware.com/content/forum/lpc1114-ssp-tx-fifo-clear



I recently encountered the same problem as you. It looks like the above countermeasure will work.

To NXP: Why is this not mentioned in the errata sheet for SSP? I performed a cursory forum-search and found multiple complaints about this issue.

[CraigMcQueen]

Since the link is no longer available... in brief, the solution described is to reset the SSPx module via LPC_SYSCON->PRESETCTRL:

LPC_SYSCON->PRESETCTRL &= ~(0x01 << 0);
LPC_SYSCON->PRESETCTRL |= (0x01 << 0);

(Then reconfigure the SSPx after that.)