SPI in SLAVE mode - please clarify MOSI (i.e. Tx) behaviour when DR is not written

[waclawek.jan]

Posted on February 07, 2017 at 17:45

When an SPI in SLAVE is clocked continuously (with NSS active) and DR is *not* written upon every TXE set, there are several possible scenarios for MOSI behaviour after the last explicitly written data bit is transmitted:

1. MOSI is set permanently at a predetermined level (0 or 1)
2. MOSI remains permanenlty at the last transmitted bit's level
3. MOSI is threestated
4. MOSI 'echoes' the received data on MISO, delayed by N SCK clocks
5. MOSI transmits the last written data as if they would be written repeatedly
6. unspecified/undocumented

Currently, the behaviour of SPI in STM32 (namely STM32F40x) is undocumented in this regard. Hereby, I would like to ask ST to properly document this behaviour in the Reference Manuals.

Rationale:

STM32s' SPIs in slave configuration are often used with masters with continuous clocking and no option for byte/word framing (e.g. various Cortex-A based SoC) (the 'F4xx itself, when used as a master, has no practically usable provision for framing, too). Also, often the highest possible clock is used, primarily to reduce data transfer latency rather than to increase bulk data rate. This means, that data are transferred quickly but with ample time between valid data. As slave is not in control of clock, to minimize latency for slave-to-master signalling, clock has to be continuous. Usually, data are packetized and a 'neutral' non-start-of-packet character is transferred between packets.

Due to need for continuous high-speed clock, it's usually impractical to impossible to use polled or interrupt-based transmission in the slave, and DMA is the only viable option.

There are two possibilities how to use DMA - continuously in circular mode, or discontinuously, per demand. Note, that there's seldom any provision to throttle the master, so we need to assume a continuous uninterrupted SCK  thus TXE being set regularly.

In the case of circular DMA, when requirement for Tx-to-master arises in slave's program, the processor has to disable interrupts, get the current NDTR, calculate a suitable displacement so that DMA won't start to read the partially written data, write the data with wraparound (using mem-to-mem DMA for this may not be of much help due to the need for wraparound) and enable the interrupts. And, after the data have been transmitted to the master, the processor needs to clear the data from the DMA so that it won't get transmitted the circular-DMA gets around to the same spot in the buffer.  For this, the program would probably set a timer to be interrupted at the moment when transmission finishes, and then store a string of 'neutral' characters to the buffer, again under disabled interrupts. This all is an overly complicated procedure which may occupy significant amounts of the mcu's resources. (A scatter-gather-capable DMA would alleviate all this and simplify the procedure but the general-purpose DMA in STM32's is not such.)

In case of single-shot DMA, when requirement for Tx-to-master arises in slave's program, the processor simply sets the DMA's source pointer to the data wherever they already are, sets NDTR and enables the transmission. When transmission ends, possibly in NDTR interrupt, SPI is set to transfer the 'neutral characters', if this is needed at all (the observed but undocumented behaviour allows to omit this by adding the 'neutral' character to the end of transmitted data). However, this implies the slave transmitter has a known behaviour when clocked without DR having explicitly written.

Thanks,

Jan Waclawek

[Amel NASRI · Accepted solution]

Posted on March 23, 2017 at 18:13

Hello Jan,

Here we are typically speaking about underrun condition at SPI slave which is a communication error, not a standard situation.

Unfortunately, the SPI peripheral embedded in STM32F4 does not provide an underrun indication at SPI mode.

It doesn’t matter if clock is continuous or not: the slave starting sequence is the same for each data as it is described at RM:

“

when the slave device receives the clock signal… the data are parallel loaded from the Tx buffer into the 8-bit shift register during the first bit transmission, and then shifted out serially to the MISO pin. The software must have written the data to be sent before the SPI master device initiates the transfer.

�

When no new data is written to the Tx buffer, the lastly written value of the Tx buffer is transacted again as an “underrun pattern�.

If software writes new data late but still while the first bit transaction is ongoing, the MOSI signal can change even during this bit transaction (which could lead to a bad sampling of such a transacted bit). At this case, this new data is accepted and fixed at Tx shift buffer at the end of the first bit transaction when TxE flag is released.

If SPI peripheral has a TxFIFO (e.g. STM32F0, STM32F3, STM32L4), the behavior is the same with following exception: the “underrun patternâ€� comes from the oldest value stored at TxFIFO.

-Amel

[waclawek.jan]

Posted on March 23, 2017 at 19:44

Amel,

When no new data is written to the Tx buffer, the lastly written value of the Tx buffer is transacted again as an “underrun pattern�?.

Thanks for the info, this is what I was looking for (basically a confirmation for what I've found out by testing and am already using 😉 )

If SPI peripheral has aTxFIFO (e.g. STM32F0, STM32F3, STM32L4), the behavior is the same with following exception: the “underrun pattern�? comes from the oldest value stored at TxFIFO.

Good to know too.

If software writes new data late but still while the first bit transaction is ongoing, the MOSI signal can change even during this bit transaction (which could lead to a bad sampling of such a transacted bit).

Yes, that's what I reported in

https://community.st.com/0D50X00009XkW6HSAV

. While this may be seen as a feature in master mode (transmission starts as soon as data are written), IMO in slave mode this is a flaw. As I explained in that thread, it's impractical for the slave to wait for a particular phase in the clock it cannot influence.

Thanks again.

Jan