AnsweredAssumed Answered

Strange i.MX6ULL SDMA behavior

Question asked by courk on Aug 7, 2017
Latest reply on Aug 7, 2017 by courk



I'm currently playing around with custom SDMA scripts using the i.MX6ULL. My software is based on official kernel 4.1.15_2.0.0.


I mainly based my work on resources available on the Reference Manual and on the following blog posts: Jonah's Blog by skrap 


I use the SDMA event SDMA_EXT_EVENT01 (event 15, lMX6UL_PAD_JTAG_TMS__SDMA_EXT_EVENT01) to make my custom SDMA channel eligible. From this channel, I use the eCSPI1 shared peripheral to read a burst of data. This data is then copied to the ARM main memory.


My issue seems to be linked with the detection of the SDMA_EXT_EVENT. My custom SDMA channel is only run at the right time when the main ARM CPU is loaded enough.


For instance, here is the observed (and correct) behavior while I'm running the stress -c 1 command on the ARM core.


Expected behavior


When the stress command is not running, I observe a strange and inconsistent behavior. The SDMA script is sometimes run twice in a row and SDMA_EXT_EVENT01 is not correctly detected.

Strange behavior


I know it's not advised to create custom SDMA scripts and that there is probably better ways to achieve the same results (by using the hardware SPI_RDY feature of the eCSPI peripheral for instance). Nevertheless I really don't understand this behavior.


How can it be explained? Can it be linked to what's described on section Clock Gating and Low Power Modes of the reference Manual? Something to do with the SDMA scheduler (even though increasing my channel priority level doesn't improve the situation)?