SPI Underrun

[siyuanzhengwei]

您好：

       我使用S32K312的SPI作为从机与外部设备进行通信，在实际测试中我发现在SPI总线为5MHZ时工作是正常的，但因为需求的原因，我需要SPI在10MHZ的速率下进行通信，测试发现SPI的触发事件为LPSPI_IP_EVENT_FAULT，并且SPI配置了DMA，我在

void Lpspi_Ip_IrqTxDmaHandler(uint8 Instance);

void Lpspi_Ip_IrqRxDmaHandler(uint8 Instance);中打断点观察到SR寄存器进行观察。

发现先触发RX此时SR = 6914,之后会返回我注册的回调函数，再触发TX此时SR = 3;

通过查询数据手册发现触发RX时发生了SPI下溢以及FIFO溢出的问题。我在主机发起通信前就已经运行了从机的异步收发程序Lpspi_Ip_AsyncTransmit，我想知道为和会出现这种问题，我该如何优化希望得到些许建议。附件是我的SPI配置。

[danielmartynek]

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

[siyuanzhengwei]

您好：

        我大致说一下工作流程，MCU从机上电后会启动第一次的接收，外部主设备的发送频率大概是15ms发起一次通信，之后从机会根据收到的信息解析发送对应的数据，在不关注从机SPI的中断触发事件时，主机是可以接收到从机发出的正确数据的。从机第一次调用Lpspi_Ip_AsyncTransmit到主机发起通信这里大概有10ms的时间，并且SPI出现错误并不是在通信一段时间后，而是第一次通信就出现了问题。我通过定时器每2ms就调用一次从机的Lpspi_Ip_AsyncTransmit，10ms左右的时间准备数据应该是足够的，可是每一次SPI的触发事件均是FAULT。我有使用逻辑分析仪查看数据波形，是可以观察到正确的收发数据，但通过示波器观察信号的质量不是很好并不是平稳的方波，这是否也可能和信号质量有关？

[danielmartynek]

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

[siyuanzhengwei]

再补充一个信息；虽然SPI的触发事件是LPSPI_IP_EVENT_FAULT，但Lpspi_Ip_AsyncTransmit的返回状态是LPSPI_IP_STATUS_SUCCESS，LpspiHwStatus是LPSPI_IP_BUSY，并且接收到的数据又是正确的。