Receive FIFO Drain Flag never getting set.

[sonaltanksale]

Hi,

We are Using MQX RTOS for our custom board based on MK60DN512ZLVQ10 series of Kinetis ARM Cortex-M MCUs. We have developed our application based on MQX 3.7 RTOS for our custom board and its working fine But we need to migrate from MQX3.7 to MQX 4.1.0.1. We have ported from MQX3.7 to MQX 4.1.0.1 and our application to MQX 4.1.0.1.

We are facing issue with the SPI communication.

There are 3 devices on the SPI channels and two are working fine.

For the third device, the Receive FIFO Drain Flag never seems to set on receiving the byte from the slave device. I am able to see the received byte in the RXFRn registers.

Our code is working fine on the MQX3.7 but is facing problems on MQX 4.1.0.1.

Can you please suggest any ideas due to which we might be facing this problem?

Regards,

Sonal.

[RadekS]

Difference: MQX 3.7 uses old SPI driver (now called legacy SPI) but MQX 4.1.0.1 has new DSPI driver.

Problem could be for example in some settings or in some wrong implementation of driver.

As first, could you please check whether you define all three CS lines in init_gpio.c file?

New SPI driver allow use two ways how to generate CS signal(s):

1. You can generate CS signal directly by SPI module
2. You can handle CS signal by CS callback

Please let me know which option you use for CS signals.

Could you please place here your SPI code that we can check it?

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[sonaltanksale]

HI,

Thanks for your response!

We are handling CS signal by CS callback. We have also checked CS signal on oscilloscope. The signal is coming correctly.

We are sending 2 bytes on the SPI line. We can see the RXFRn registers getting updated for these two bytes with the response from the chip . Also RFDF flag is getting set for one byte. But not getting set for second byte.

The function _dspi_tx_rx  in spi_dspi.c file is being used for SPI communication. Since there is no RFDF flag set for both the bytes the function gets stuck in forever while loop.

Regards,

Sonal.

[RadekS]

Thank you for additional information.

Could you please check and potentially disable DMA for SPI for avoid DMA influence?

In user_config.h file please use #define BSPCFG_DSPI0_USE_DMA               0

If you use different SPI module instead of SPI0, please modify it according your configuration.

Unfortunately we know about potential issues in DMA with unaligned transfers (problem is in hardware module and it is not reflected by software driver). This issue is not presented when we use DMA only for SPI. But general recommendation is do not use DMA for SPI at currently supported platforms.

Could you please specify your transfer parameters?

Could you please check whether you use flush operation after every access to SPI (read/write)?

[sonaltanksale]

Thanks for your reply.

We are not using DMA with our SPI module. Also after every operation there is a flush operation.

Can you suggest some other pointers for us to debug?

[RadekS]

In fact, I am not sure what could be reason.

We do not know about similar issue.

Could you please create some small example project only with SPI which highlight described issue that we can reproduce it on our side?

Just for sure: You saw on oscilloscope that CS signal goes low , SPI transfers two bytes and CS signal goes high. Correct?

Did you made any modification in SPI code? - For example in some timing or delay settings?