DSPI_MasterTransferBlocking is blocked :)

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

DSPI_MasterTransferBlocking is blocked :)

3,010件の閲覧回数
guylejeune
Contributor III

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:

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

ラベル(1)
0 件の賞賛
返信
5 返答(返信)

2,590件の閲覧回数
carlossilva
Contributor I

Did you find a way to solve this issue?

Im facing the same issue with KSDK 1.3.

0 件の賞賛
返信

2,590件の閲覧回数
guylejeune
Contributor III

I did 2 things:

  1. While waiting for the kDSPI_TxFifoFillRequestFlag, instead of looping on nothing, I check as well if a byte has been received;
  2. 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.

2,590件の閲覧回数
carlossilva
Contributor I

I just opted to update to the non blocking functions!

It was a minor impact on the software, and now it works!

Thanks

0 件の賞賛
返信

2,590件の閲覧回数
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi,

I think this is the drawback of the polling mode.

BR

Xiangjun Rong

0 件の賞賛
返信

2,590件の閲覧回数
MarekTrmac
NXP Employee
NXP Employee

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

0 件の賞賛
返信