AnsweredAssumed Answered

i.MX6Q ECSPI rx byte shift

Question asked by Anders Nielsen on May 3, 2018
Latest reply on May 6, 2018 by Anders Nielsen

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

Attachments

Outcomes