AnsweredAssumed Answered

DSPI_MasterTransferBlocking is blocked :)

Question asked by guylejeune on Jan 26, 2017
Latest reply on Feb 22, 2017 by carlossilva


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:

  • IDE: KDSK 2.0
  • chip: MK22

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);

        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.