Diagonal tearing on LCD_DSI_VideoMode_DoubleBuffering on STM32F469I-DISCO DK32F469I$AU

[Richard-CRT]

[If this would be better off in one of the other STM32 MCUs sub-forums, please feel free to move it admins]

I have spent a very long time removing the BSP initialisation calls from the LCD_DSI_VideoMode_DoubleBuffering example on STM32F469I-DISCO, however it behaves exactly the same using the "stock" example and with my modifications. I am not using TouchGFX.

The symptom is a consistent diagonal tear in a fixed location on my landscape configured display regardless of where the region of the screen I am editing is. Naturally, if the region I'm editing doesn't cross the diagonal, the tear isn't visible. Slow mo video of issue is attached.

In both the example and my modified code, the screen is waiting on HAL_LTDC_LineEventCallback to switch to a new buffer like so:

In my modified code as shown above, Buffers[front_buffer] is written to (using DMA2D) while the state machine is at the state before BufferPrepared, and then the state machine moves on to BufferPrepared 200ms later (same behaviour when this is much higher). 200ms allows the DMA2D plenty of time to complete, so when the interrupt above fires with the buffer state correctly set the data should be stable and unchanging.

So in summary, I have 2 buffers in SDRAM. The DMA2D is only ever writing to the one that the LTDC is not reading. And there's a significant enough delay between the DMA2D operation and the LTDC swapping buffers that the DMA2D must have completed in time. So why does the display end up displaying half (not exactly half, but whatever) of the old buffer and half of the new buffer, split by a diagonal line?

The first of the previous tickets below indicates that this is caused by the screen updating in a 'portrait' manner while the LTDC is updating in a 'landscape' manner, but I don't fully understand this, and neither did the OP of that question (@S.K.Matters), but they never received any further explanation. What's more, even if that is an explanation of the issue, why has the LCD_DSI_VideoMode_DoubleBuffering example got this issue?

The second of the previous tickets below has the same issue, complete with a similar video, but received no reply. I'm hoping someone will be able to reply to this one.

The last ticket I have linked from just a few days ago refers to the same exact issue on a different DISCO board (STM32H747I-DISCO) and the ST employee there said he has reported it internally.

Previous tickets going back 5 years ago with seemingly the same issue but no solution:

https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/some-kind-of-tearing-effect-with-lcd-dsi-videomode/td-p/398477

https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/stm32f469i-disco-screen-tearing-on-double-buffer-example/m-p/668979#M37372

Previous ticket with seemingly the same issue on a different dev board and a ST employee saying the issue was "reported":

https://community.st.com/t5/stm32-mcus-products/stm32h747i-disco-tearing-in-double-buffering/m-p/647508#M237425

[Tesla DeLorean]

ST has an internal support/ticketing system that's opaque to the forum users. This may contain other answers (FAQ) and solutions to problems.

https://www.st.com/content/st_com/en/support/support-home.html

https://ols.st.com/s/

If you're a customer, doing a quantifiable amount of business, you can push in support requests via your FAE, or local reps.

[Richard-CRT]

Thank you - I'm not a big customer but I've kicked a support request on there anyway.

I've had a break through on the issue also, however I still can't explain the original problem. By initialising the NT35510 in portrait mode and configuring the LTDC to be portrait instead of horizontal the problem is no longer present. Of course, now I have an issue that my frame buffer is portrait instead of landscape, but at least I can work around that except when using DMA2D mem-to-mem.

If anyone can explain the original issue, I still need to understand it, as eventually I will be replacing this display (and controller) with a different off the shelf one.

[Alekseus]

---

@Richard-CRT wrote:

So in summary, I have 2 buffers in SDRAM. The DMA2D is only ever writing to the one that the LTDC is not reading. And there's a significant enough delay between the DMA2D operation and the LTDC swapping buffers that the DMA2D must have completed in time. So why does the display end up displaying half (not exactly half, but whatever) of the old buffer and half of the new buffer, split by a diagonal line?

---

I have to add that even without buffer memory update (using DMA2D or directly) but just swapping buffer address (CFBAR) leads to the same effect. So I can assume that the issue is closely tied to the hardware (defective display or maybe it initially has poor video mode support or poorly designed MCU's DSI/LTDC etc).

[MM..1]

In video mode your setup must equal to hw display controller. If in pdf is for example 480x1024 you cant config LTDC 1024x480. Orientation can be handled be register config , but data stream is only valid as portrait.

[Richard-CRT]

That's interesting, thank you for your insight!

Something I don't understand, if the data stream is only valid as portrait, what's the point in having the orientation config register? Indeed, the presence of the orientation register implies to me that the data stream can be valid in landscape.

Feeding a landscape data stream to the screen when the register is set to portrait ends up looking very broken as below (as I would expect):

Whereas switching the register to landscape the same data feed renders like this (complete with the diagonal glitch that we're talking about):

This makes it seem to me like the display thinks it can support a landscape data stream, but actually is not able to do so properly, causing the diagonal line.

[MM..1]

As you can see is portrait native

but with GRAM, then config can handle this display too as landscape... I wrote for example , then exist displays that only support native configs. In your config with DISCO you must have other mistake with diagonal trouble.

[Richard-CRT]

I think I understand now. All of the photos and videos above are in video mode, so GRAM is not in use. Let me just confirm what you're saying:

• The display is native portrait and so works in portrait video-mode, but does not necessarily work in landscape video-mode
• The built-in GRAM allows this display to work in command-mode
• In command-mode using the GRAM the display can function in landscape mode
• The diagonal seen in my pictures is because of the first bullet point. The display is trying to work in landscape video-mode but is not able to fully work

Is that all correct?

[MM..1]

Video mode not equal GRAM not used, then your all phrases miss. Video mode is only next method of many how fill GRAM. My tip for your trouble is bad timing setup for LTDC and DSI porch system. 

[Richard-CRT]

OK thank you - unfortunately then I think we're back to square one.

The issues with the diagonal are present on the examples direct from ST, it's not something I/we have introduced. There are several years worth of people talking about this issue on and off and there has never been any conclusive solution. I myself have already played with the timing of the LTDC and DSI quite a bit and it hasn't fixed anything. As @Alekseus has said, that really only leaves a fault/lack of support or incompatibility of the display with the STM peripherals.