i.MX6Q ECSPI rx byte shift

[apni]

Hi,

During development of an spidev based application running on a i.MX6 quad processor I have come across the following behavior:

root@imx6q:~# ./spidev_test -s14000000 -H 1 -O 1 -D /dev/spidev4.0 -v
spi mode: 0x3
bits per word: 8
max speed: 14000000 Hz (14000 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D  | ......@....�..................�.
RX | 0D FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0  | .......@....�..................�

It appears that the application using spidev is triggering a bug that shifts the ECSPI input by one byte.

E.g. the first RX byte after an SPI transaction is from the previous transaction. The speed and mode does not affect the behavior. The port works fine at first, but after some time the issue appears and reboot is required to correct the behavior. I have tested this on ECSPI port 0 and 5. The issues is triggered on port 5 after only a few minutes while it takes several hours on port 0. Looks like this issue disappears if DMA is disabled. The latest FW (v3.3) does not solve the problem.

Have anybody seen this issue or have an idea about what can cause this?

Best regards
Anders

[igorpadykov]

Hi Anders

what bsp used in the case, one can try with nxp releases

linux-imx - i.MX Linux kernel 

Documentation:

i.MX Software|NXP 

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

[apni]

Hi Igor,

Currently we are using Yocto rocko with upstream kernel version 4.14.15.

We will try if using the bsp version solves the problem.

Regards,

Anders

[apni]

Hi,

My collage Sean found the problem. It was caused by a DMA misconfiguration of the SPI5 port:

https://patchwork.kernel.org/patch/10425383/

Best regards
Anders

[apni]

Hi,

Looks like the patch above did not solve the problem so we are still looking for a solution.

Regards
Anders