Hi,
When using the LPSPI EDMA transfer API, sometimes when my callback is called from the SDK (when EDMA is complete), if I look at the LPSPI SR register, about one in 5-10 times it has the REF bit set (Read error flag / overflow). My SPI clock is running at 500Khz. I'm not really sure why I'm getting this SPI RX overflow as the SPI clock is nowhere near fast enough to cause DMA to not be able to keep up. Is there any way I can troubleshoot this and has anyone else seen this problem? The data always looks correct even when I get the overflow (I zero my buffer between each transfer, so I know it's not old stale data I'm looking at). I'm doing simultaneous TX/RX using the transfer API, and doing the transfer every 4ms. There shouldn't be any issues with timing.
Thanks,
-m
Hi @nxp16 ,
Thank you so much for your interest in our products and for using our community.
SR[REF] indicates a receive FIFO overflow. If this flag is really set during a transfer, the recommended recovery is to stop the transfer, empty the RX FIFO, clear REF, and restart the transfer.
However, at 500 kHz, this does not look like a normal DMA bandwidth issue, assuming the RX EDMA channel is already prepared/enabled before the SPI clocks start. Since the received data is still correct, I suggest first check whether REF is a stale flag or is being set by the transfer start/stop sequence.
For troubleshooting, please try the below:
1. Clear SR[REF] before starting each new transfer.
2. Make sure RX DMA is enabled before TX starts generating clocks.
3. Check whether LPSPI is disabled/re-enabled between transfers. If yes, apply the applicable errata workaround: clear REF after enabling LPSPI, or reset LPSPI before re-enabling.
Wish it helps you
Best Regards
May
The errata mentions two workarounds, clearing the bit in SR, and resetting the peripheral. Unfortunately, the errata seems to be incorrect about the first one as the SDK already does that and it doesn't workaround the problem. Unfortunately, for me, resetting the peripheral is not an option as I would have to reconfigure everything afterward (it clears ALL registers). For now, I'm going to assume that if DMA completed successfully and we get a REF error, then it's a false error and I'll just ignore it.
Thanks,
-m
Unfortunately, the SDK is disabling and enabling the LPSPI peripheral between transfers and I have no control over that.
Thanks,
-m
Hi @Mike_M3 ,
Please check whether LPSPI is disabled and re-enabled between transfers. If yes, avoiding this sequence would be preferable. If disable/re-enable is required, please follow the documented workaround.
After clearing REF, please verify the RX FIFO state and the received data before starting the next transfer, and log/count this condition for further debug.
Best Regards,
May
Thanks for the update.
The SDK may disable/re-enable LPSPI internally, but the application should still ensure that the previous LPSPI bus transfer has completed before starting the next transfer.
The EDMA callback only indicates DMA completion. If the next transfer is started immediately from the EDMA callback while SR[MBF] is still set or SR[TCF] is not set, the SDK may enter the next transfer setup while LPSPI is not fully idle.
Please wait for SR[TCF]=1 or SR[MBF]=0 before submitting the next LPSPI EDMA transfer.