DMA on iMX6SL not working properly

[adamgarrison]

Camera Interface DMA goes bonkers and we need a work around or understanding of how this can happen so we can stop it. We currently are running the IMX6 SL @ 792MHz with X16 DDR3L @396MHz. Core voltage is 1.375V we are finding that the CSI peripheral gets into a state where the DMA is broken . Its beyond repair at the user register level. we must power cycle to fix it. only a power cycle will recover the HW functionality again. also verified entire register stack for CSI and CCM with no difference from normal correct operation. DMA will write 16pixels of a new image at the previous last left write address that is stopped @ from last frame. ( not following te destination address register @ first.) then after those 16 pixels written in old addresses it will then jump to the correct buffer address and complete with image. the result is a shift and 16 pixel short image. also there are 16 byte repeat data strips spread at various places in the image. mostly random. also there are 16byte skips in the image where no writes took place. impossible to make the camera DMA do this even if you wanted to. none of this can be related to code as there is just a buffer start address and data transfer count so skipping within the buffer is impossible plus we validates the setup on frame start to be correct. we just do not know what is causing this. it happens somewhere between 150K images and 8.5M images. we are using an SXGA sensor from aptina with active area of 1280x960 and is running @ 66MHz pixel clock rate. sensor is good for 74MHz and sensor does not appear to be capable of making the DMA write at incorrect addresses or skip buffer pixels and continuous still creating a coherent image at the same time. there is another case where no data is written but events operate as though its working correctly. buffer done ISR and all. not writing but reading all the data out is not something we could explain. destination address validated too. also our SD interface (uSDHC) drops at the same time. assuming the DMA is also going down with the camera DMA simultaneously. we are not doing any SDCARD accesses during the testing but have repeatedly noticed that every time the camera DMA faults the SD goes off hook. this is a very strange and seemingly unrelated peripheral but yet that is what it’s doing. so this feels much like the CPU DMA system folds on us. Ethernet continues to operate correctly so it is not all DMA goes off hook. Help? I have but see no issues that overlap with the camera interface. a bunch of video out but not parallel video in and DMA issue. I find this link to be of interest… there is a tie between the CSO and SD Controller (see attached). PLL_ARM= 0x80002042 PLL_SYS= 0x80002001 PLL_AUDIO= 0x00011006 PLL_VIDEO= 0x0001100C PLL_ENET= 0x80102001 PLL_PFD_480= 0x1311100C PLL_PFD_528= 0x1018121F ANALOG_MISC0= 0x04010080 ANALOG_MISC2= 0x00672F67 CCM_CCR= 0x040110FF CCM_CCRDR= 0x00020000 CCM_CSR= 0x00000038 CCM_CCSR= 0x00000100 CCM_CACRR= 0x00000000 CCM_CBCDR= 0x00018900 CCM_CSCDR1= 0x00490B00 CCM_CS1CDR= 0x0EC102C1 CCM_CS2CDR= 0x000736C1 CCM_CBCMR= 0xFC26 0034 CCM_CSCMR1= 0x00900000 CCM_CSCMR2= 0x02B92F06 CCM_CDCDR= 0x33F71F92 CCM_CHSCCDR= 0x0002A150 CCM_CSCDR2= 0x00029150 CCM_CSCDR3= 0x00010041 CCM_CWDR= 0x00000000 CCM_CDHIPR= 0x00000000 CCM_CLPCR= 0x00000079 CCM_CISR= 0x045A0000 CCM_CIMR= 0xFFFFFFFF CCM_CSCDR3= 0x00010041 CCM_CWDR= 0x00000000 CCM_CDHIPR= 0x00000000 CCM_CCOSR= 0x000A0001 CCM_CGPR= 0x0000FE62 CCM_CCGR0= 0xFFFFFFFF CCM_CCGR1= 0xFFFFFFFF CCM_CCGR2= 0xFFFFFFFF CCM_CCGR3= 0xFFFFFFFF CCM_CCGR4= 0xFFFFFFFF CCM_CCGR5= 0xFFFFFFFF CCM_CCGR6= 0xFFFFFFFF CCM_CMEOR= 0x7FFFFFFF OCRAM == L2 cache for us after boot up. cache appears to be fine as my assumption would be it would kill the CPU if it was stalled. TZASC == unused we don’t use any low power modes. we are full tilt 100% of the time. we use an eMMC device. 2GB micron eMMC. actually in looking at the driver setup structure. it does not look like we are using the DMA Mode. after further study... we are looking at a possible source of the issue. I want to run it by you to see if it helps. we think that it’s a DataBuss overload issue. somehow this results in breaking the DMA system to the camera. likely the DMA is held off too long and is getting additional requests to move data or doesn’t have a way to handle the error. we must force image processing work to overlap with capture and Ethernet activity to get the error. Ethernet continues to function. when the error happens we also develop a memory leak. we are also working to track the source of the memory leak. the leak happens immediately or soon after the camera breaks. not 100% of the time does the leak appear but it has done it often. is there a way to make the arbitration favor DMA over CPU? I could not find anything about setting buss priority in the manual.

[weidong_sun]

Hello Adam ,

>>is there a way to make the arbitration favor DMA over CPU? I could not find anything about setting buss priority in the manual.

     About the contents, Maybe you will have to consult those documents of ARC Cortex-A9 or ARM-V7 from ARM Website.

Cortex-A9 – ARM Developer 

   Hope above message can help you!

Best Regards,

Weidong