2378637_en-US

[#1]

SPI Underrun

Hello:

I am using the SPI of S32K312 as a slave to communicate with external devices, in the actual test I found that it works fine when the SPI bus is 5MHZ, but because of the demand I need the SPI to communicate at 10MHZ rate, the test found that the trigger event of SPI is LPSPI_IP_EVENT_FAULT and the SPI is configured for DMA, I have set the DMA in the

void Lpspi_Ip_IrqTxDmaHandler(uint8 Instance).

void Lpspi_Ip_IrqRxDmaHandler(uint8 Instance);Interrupt point observation to SR register for observation.

Found out that triggering RX first at this point SR = 6914, after that it will return to the callback function I registered, then triggering TX at this point SR = 3;

By checking the datasheet I found out that an SPI underflow and FIFO overflow problem occurs when triggering the RX. I have run the slave's asynchronous transceiver program Lpspi_Ip_AsyncTransmit before the host initiates the communication, I would like to know why and how this problem occurs, and how I can optimize it hope to get some suggestions. Attached is my SPI configuration.

Re: SPI Underrun

Hello @siyuanzhengwei,

What do you mean by this statement:

"Without monitoring the slave device's SPI interrupt trigger events, the master device can receive the correct data sent by the slave device."

TX underrun (SR[TEF]) is set only when the master starts the transfer while the slave TX FIFO does not contain valid data, i.e. the driver or DMA did not write the next data word in time. There is no other condition under which this flag is set. Therefore, this error cannot be explained by SPI signal quality; it indicates that the slave transmit path was not serviced early enough before or during the transfer.

BR, Daniel

Re: SPI Underrun

Hello:

I roughly say the workflow, MCU slave will start the first reception after power on, the external master device sends about 15ms to initiate a communication, after that the slave will be based on the information received to parse and send the corresponding data, in the not pay attention to the slave SPI interrupt triggering event, the host is able to receive the correct data sent by the slave. There is about 10ms from the first time the slave calls Lpspi_Ip_AsyncTransmit to the time the host initiates the communication, and the SPI error occurs not after a period of time, but the first time the communication is faulty. I call the slave's Lpspi_Ip_AsyncTransmit every 2ms through a timer, 10ms should be enough time to prepare the data, but every SPI trigger event is FAULT, I have used a logic analyzer to check the waveform of the data, and I can observe the correct send/receive data, but through the oscilloscope to observe the quality of the signal is not good and not a smooth square wave. The signal quality is not very good and not a smooth square wave, is it possible that this is also related to the signal quality?

Re: SPI Underrun

Hi @siyuanzhengwei,

The return status of Lpspi_Ip_AsyncTransmit is LPSPI_IP_STATUS_SUCCESS because this is an asynchronous transfer (it only indicates that the transfer was started, not completed).

The key issue is the TX underrun (SR[TEF]). This means the slave did not have data available in the TX FIFO when the master started clocking.

In SPI slave mode, the TX FIFO must be populated before the master asserts CS and starts the transfer. 

The RTD drivers introduce some overhead, and starting the transfer on the slave side takes time. As a result, Lpspi_Ip_AsyncTransmit is called too late and the first data words are not ready in time.

Do you monitor the TX line with an oscilloscope? What do you measure there?

Regards,

Daniel

Re: SPI Underrun

One more piece of information to add; although the SPI trigger event is LPSPI_IP_EVENT_FAULT, the return status of Lpspi_Ip_AsyncTransmit is LPSPI_IP_STATUS_SUCCESS, the LpspiHwStatus is LPSPI_IP_BUSY, and the received data again is correct.