AnsweredAssumed Answered

i.MX6ULL, ECSPI Transmission Corruption

Question asked by Wolfgang Mües on Oct 16, 2017
Latest reply on Jan 8, 2018 by Wolfgang Mües

We are using a i.MX6ULL CPU with eCSPI:

eCSPI1: not used

eCSPI2: LCD Frame Buffer Update, Transmission only, PIO+DMA

eCSPI3: Transmission only, Loop DMA, 2 Callbacks/sec

eCSPI4: Audio Codec, Transmission only, PIO

Linux System, Android 7 running.


When the Loop DMA from eCSPI3 is running, we observe transmission errors (timeout from the linux driver) in eCSPI2 and eCSPI4.

We spent several days to debug this error, without success. Some additional information:

- if we use DMA in eCSPI2, we got memory corruption after some hours of operation. We got no memory corruption if we use only PIO in eCSPI2.

- We testet with the SDMA ROM Script, and with the Rev. 3.3 "Q" Script. No difference. We have not found a special ULL script.

- In PIO mode, Transmission is started, but not completed (no end interrupt).

- It makes no difference if the DMA buffer of eCSPI3 is located in internal RAM or in DDR3 RAM.

- The error is not reliable, sometimes it runs without problems, and we have to restart several times.

- The error is not related to the not used receive direction of eCSPI3. Setup a cyclic DMA transfer for the receive data of eCSPI3 does not cure the problem.


Now, we are running out of ideas to debug this problem. A eCSPI port should not influence another port. Same for a SDMA channel. Where is the hidden link between these ports?


DMA for eCSPI 3 is:


dma-names = "rx", "tx";
dmas = <&sdma 7 8 1>, <&sdma 8 8 2>;


&sdma {
gpr = <&gpr>;
fsl,sdma-event-remap = <0 14 0>, <0 13 0>; // eCSPI RX Event is muxed with I2C1, eCSPI TX Event is muxed with I2C2

Does anybody observe a similar problem or has a suggestion howto fix or debug this incident?