STM32F7 - SDRAM concurrent access between DCMI and LTDC

Stanley Lin · ‎2017-11-09

Posted on November 09, 2017 at 10:13

Hello,

Recently I've developed a graphical application on the STM32F746G discovery board. It displays gray-scale frames (400x400/8bpp/120Hz) from an image sensor.

Firstly it worked fine while the frame buffer was located in local SRAM, but it went wrong after switching the frame buffer to external SDRAM. The DCMI DMA FIFO errors always occurred, however it was still able to work at this time.

Then I changed the system clock from 216 MHz to 200 MHz to meet maximum SDRAM allowed speed (100 MHz). It went worse since The DCMI DMA transfer errors occurred and it stopped after about 1 second.

There is no problem if the LTDC was turned off, so that's why I think it is a SDRAM concurrent access issue between DCMI and LTDC.

I've read DCMI and LTDC related documents (AN5020 & AN4861) and tried to solve the issue by modifying their configurations, but still couldn't find a proper solution. Maybe possible workaround is to changed the SDRAM bus width from 16-bit to 32-bit, but output frames became stripped (I don't know why...).

My code is based on the HAL and BSP drivers in STM32Cube_FW_F7_V1.8.0 package which was modified only for custom sensor extension.

The frame data flow is like (Page 56 in AN5020)

Both DCMI and LTDC uses the same frame buffer.

Professional assistance is necessary for me...

Thanks in advance.

#sdram #stm32f7-discovery #ltdc #dcmi

stm322399 · ‎2017-11-17

Posted on November 17, 2017 at 10:17

Stanley,

There are a lot of competitors in that design: LTDC and DMA2 (for SDRAM), and DCMI as well. The fact is that DCMI is stalled when DMA2 is accessing the SDRAM (which could be stalled as well by LTDC access, and maybe SDRAM refresh).

One big issue (I already met using STM32f476) is that DCMI output FIFO (to AHB) is only 4 x 32-bit words. At the speed of pixels, this leaves almost no room for stalling DCMI transfer to DMA2.

Using SRAM for unloading DCMI data might not be an option. When you need SDRAM for holding big buffers, use another DMA from SRAM to SDRAM. This is the way I solved this problem on F476: using SRAM as FIFO between DCMI and SDRAM.

View solution in original post

stm322399 · ‎2017-11-17

Posted on November 17, 2017 at 10:17

Stanley,

There are a lot of competitors in that design: LTDC and DMA2 (for SDRAM), and DCMI as well. The fact is that DCMI is stalled when DMA2 is accessing the SDRAM (which could be stalled as well by LTDC access, and maybe SDRAM refresh).

One big issue (I already met using STM32f476) is that DCMI output FIFO (to AHB) is only 4 x 32-bit words. At the speed of pixels, this leaves almost no room for stalling DCMI transfer to DMA2.

Using SRAM for unloading DCMI data might not be an option. When you need SDRAM for holding big buffers, use another DMA from SRAM to SDRAM. This is the way I solved this problem on F476: using SRAM as FIFO between DCMI and SDRAM.

Stanley Lin · ‎2017-11-19

Posted on November 20, 2017 at 07:52

Hi Gonzalez,

Thanks for your kindly suggestion. I will try your way later.

My further question is that when did you transfer DCMI data from SRAM to SDRAM using DMA?

In line event (hsync) or frame event (vsync)?

Regards,

Stanley

stm322399 · ‎2017-11-20

Posted on November 20, 2017 at 10:49

Stanley, I am afraid that I did solve exactly the same problem you have.

My concern was to get a single snapshot of 1.3M picture. Transfers from SRAM to SDRAM were tailored to require an integer number of loops over the SRAM buffer to fill correctly a single 1.3M buffer into SDRAM. DMA to SDRAM was triggered by halves being filled from DCMI.

When your DCMI data has fixed size (it should!), this should be possible to make something similar, and even manage a double buffer in SDRAM to avoid tearing. Probably not easy to do, but definitively possible.

Last, I got best results with DMA FIFO threshold at 1 quarter full. It is not the best for bursting data, but it maximize DMA FIFO room, and it is critical to make sure that DCMI can always unload data from its tiny internal FIFO.

Stanley Lin · ‎2017-12-29

Posted on December 29, 2017 at 10:35

Hi Gonzalez,

Sorry for my late reply since I'm busy finishing this work these days.

As you said, the key to this problem is to firstly set the target frame buffer of DCMI DMA to SRAM, and the frame is copied from SRAM to SDRAM afterward by DMA (I did the DMA transfer in DCMI line event interrupts).

On the other hand, LTDC is also an AHB competitor here. To ease the AHB traffic, an extra buffer in SDRAM should be assigned for LTDC and frames should be copied into it during idle time (Why I did this is because the original buffer in SDRAM is necessary for my application, and it should work to have LTDC fetch the original buffer in SDRAM if it isn't used by other AHB masters).

Appreciated for your replies.

HAPPY NEW YEAR 2018!

Cheers,

Stanley