LTDC Layer 2 pixels are mysteriously horizontally offset

[Chris Rice]

Hello, we are creating an application on an STM32F7 that uses the LTDC and DSI outputs to control a touchscreen display. We are implementing a moderately sophisticated UI, with translucency and sliding panels, and we were hoping to use the layer 1/2 features of the LTDC peripheral in order to achieve some of these effects with hardware.

We are encountering a very strange effect where we configure the LTDC layers to point at two different frame buffers in SDRAM (CFBAR) with the correct widths and heights and formats (CFBLR, CFBLNR, PFCR), drawing pixel information to the frame buffers, and then updating the screen by enabling the DSI wrapper, the same way as the accompanying sample code (DSI->WCR |= DSI_WCR_LTDCEN). This combines the two layers of pixels and outputs them to the screen.

This was working well in our early experiments, but lately we are seeing a *very* weird effect, possibly correlating to larger framebuffers, where layer 1 and layer 2 are horizontally offset from each other. When we inspect SDRAM, everything is correctly positioned relative to the top left of the frame buffer, but layer 2 ends up appearing randomly offset 20-100 pixels left or right from layer 1.

The effect changes each refresh, and doesn't seem to depend on our rendering or refresh timing; we can draw our pixel data in one step, and then wait, and then call DSI->WCR |= DSI_WCR_LTDCEN slowly, every few seconds and layer 1 will appear correctly, and layer 2 will jump around on each refresh to the left and right several dozen pixels, wrapping around the left and right edges.

This is a bit of a mind blower, since it sort of a suggests a problem *within* the LTDC, which (I believe) is doing all of this: grabbing the data from both framebuffers, combining them, and sending the resultant RGB data to the DSI. In order for the two to be mismatched, it suggests a problem with this grabbing/combining operation. I have no idea what we could have done to cause that.

Has anyone encountered anything like this, or have any thoughts on troubleshooting steps? If we can't use the layers individually, we will have to significantly scale back our UI plans, which would be a heartbreaker...

Thanks very much for any thoughts.

[Amel NASRI]

Hello @Chris Rice​ ,

The behavior you are seeing is most likely related to bandwidth limitations on your application.

In fact, using two layers creates bandwidth constraints on the system. It is preferable to use only

one layer and to do the composition with the Chrom-Art Accelerator® during the framebuffer

calculation.

With 2-layers configuration, it is recommended to locate the framebuffers in the internal SRAM as this allows the maximum performances and avoids any bandwidth limitation issues for the LTDC. 

If the size of your framebuffers doesn't allow you to use the internal SRAM, then you need to opt for other choices in order to optimize performance.

There are also some special recommendations as you are using Cortex-M7:

• Disable FMC bank1 if not used 
• Configure the memory protection unit (MPU)

For more details, I recommend you to review the following sections in AN4861 (LCD-TFT display controller (LTDC) on STM32 MCUs available on https://www.st.com/resource/en/application_note/dm00287603.pdf):

• 3.3 Two programmable LTDC layers
• 4.2 Checking the display size and color depth compatibility with the hardware configuration
• 4.5 Graphic performance optimization
• 4.6 Special recommendations for Cortex®-M7 (STM32F7 Series)

-Amel

[Chris Rice]

Thank you very much. Can you help me understand why layer combination by the DMA2D does not create bandwidth issues, whereas the layer combination by LTDC does create bandwidth constraints? It's the same amount of activity, is it not?

[Amel NASRI]

This is indeed the purpose of the DMA2D: it offloads CPU for graphical operations.

Have a look to "Chrom-ART Accelerator (DMA2D)" dedicated presentation in the STM32F7 Online Training (https://www.st.com/content/st_com/en/support/learning/stm32f7-online-training.html).

-Amel