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?
regards
Wolfgang
The peripheral type 8 (shared eCSPI) of the SDMA controller is broken in 6ULL.
Using type 7 (MCU eCSPI) for all eCSPI channels cures this problem.
dmas = <&sdma 7 7 1>, <&sdma 8 7 2>;
Thanks NXP for support !
We were able to reproduce this issue with the NXP i.MX6ULL eval board and the NXP linux kernel.
Now waiting for NXP investigations.