Hello,
Using SPI and the fsl_dspi official driver, I noticed that when I used DSPI_MasterTransferBlocking function intensively, I sometime end-up waiting indefinitely for this function to exit.
Here is my setup:
I realized that the problematic code was as follow:
while (remainingReceiveByteCount > 0)
{
if (DSPI_GetStatusFlags(base) & kDSPI_RxFifoDrainRequestFlag)
{
if (rxData != NULL)
{
/* Read data from POPR*/
*(rxData) = DSPI_ReadData(base);
rxData++;
}
else
{
DSPI_ReadData(base);
}
remainingReceiveByteCount--;
DSPI_ClearStatusFlags(base, kDSPI_RxFifoDrainRequestFlag);
}
}
I guess what happened is that the function missed a byte in reception and later on, waits for it ( endlessly ) .
It seems that this is a very dangerous behaviour, as the MCU code can stay there forever !
I went further on to investigate why it missed a byte. I notice that DSPI_MasterTransferBlocking, on two occasions, uses
/*Wait until Tx Fifo is not full*/
while (!(DSPI_GetStatusFlags(base) & kDSPI_TxFifoFillRequestFlag))
{
DSPI_ClearStatusFlags(base, kDSPI_TxFifoFillRequestFlag);
}
But if a byte is received when the MCU is waiting in that piece code, it can miss it (and then totally block the function).
While it can happen that DSPI_MasterTransferBlocking misses some RX bytes (because some other high-priority function being called, for example), the latter piece of code greatly increase that probability.
IMHO, the official driver should not wait blindly for TX Fifo, nor should it leads to infinite loop if a RX byte is missed.
Did you find a way to solve this issue?
Im facing the same issue with KSDK 1.3.
I did 2 things:
kDSPI_TxFifoFillRequestFlag, instead of looping on nothing, I check as well if a byte has been received;
Add an escape condition on all the while() used in that function (both for tx and rx).
(1) decrease the probability of having the problem to happens ;
(2) prevents your code to be blocked, but exiting the function does not guarantees that all bytes have been received, so additional checks are required.
Another possibility is to use interrupts for these transfers.
I just opted to update to the non blocking functions!
It was a minor impact on the software, and now it works!
Thanks
Hi,
I think this is the drawback of the polling mode.
BR
Xiangjun Rong
Hi Guylejeune,
there is community for Kinetis SDK:
https://community.nxp.com/community/kinetis/kinetis-software-development-kit
I'd recommend to post your question there.
Regards
Marek