Glitching/Tearing when transitioning from one screen to another

[Nicholas Yunker_2]

Hello,

I am in the process of creating a modifying a TouchGFX project using the example project for the STM32H735G-DK kit.  I generated a project in TouchGFX and then modified it to use a larger custom 7" Display/touchscreen.  So far I have been able to get the display to show static images perfectly and I've even been able to modify the generated program to use a GT911 touch controller library for touch control instead of the default FT5336 controller.  All the works perfectly.  Static images look good and touches are registers and transitions from one screen to the next work.  The problem I'm having now is that during the transition the images seem to tare/glitch and I'm not sure what is causing this.  I've modified all the timings to match that of the new display, I've changed the LTDC clock to match that of the new display.  I've changed all the framebuffer settings to match the larger display.  Are there other timing settings I need to manually change in the code to match the new display as well?

This project created by TouchGFX also uses FreeRTOS...this is my first time using an RTOS in my programs, is there some settings here I need to manage for memory or something?  Could there be too little memory allocated to the process?

I've attached a video of what I'm seeing when I trigger a screen transition.  I've also attached my CubeMX .ioc file as well as the datasheet for my display.

[Nicholas Yunker_2]

Interestingly I just tried to change the framebuffer strategy to a single buffer at location 0x70000000 and that improved the glitching so now only the bottom half of the screen glitches while the top half looks perfect and with the reduced glitching you can see that the "wipe" transition is occurring under it all.  Perhaps this is a clue as to what's happening??

[GaetanGodart]

Hello @Nicholas Yunker_2 ,

You have move to single framebuffer strategy, but what strategy did you use previously?

You say the screen is having tare/glitch. Do you mean tearing?

If the tearing happens during transition, you can measure the rendering time to see if you are having render time issue. You can then try to use n animation that require less screen redraw.

You can then setup compensating-for-lost-frames.

Regards,

[Nicholas Yunker_2]

Hello,

Thank you for your response.  Previously I used a double buffer strategy placing the framebuffers at 0x70000000 and 0x70119400.  Changing to Single Buffer strategy didn't really fix anything so I just went back to double buffer.  What really does seem to help the problem (though it still is happening to a much lesser extent) is disabling the ChromeArt Accelerator in CubeMX under the settings for TouchGFX.

I call it a glitch/tearing but I don't really know what to call it.  If you watch the video I previously attached to my post you will see what I mean.  I am attaching another video to this reply showing the "glitch/tearing" effect with the ChromeArt Accelerator disabled.

I have reviewed the page about measuring the rendering time. I'm not clear, using an oscilloscope, what signal would I be measuring on?  This seems to imply that my refresh rate may be set too high...I don't see in the code where the refresh rate is set...can you point me in the right direction and I will lower than and see if that helps?

[Nicholas Yunker_2]

Hello,

I’ve managed to get rid of the glitching, even with DMA2D ChromeArt Accelerator enabled, though I’m certain my method is not the correct way to do it.

So, I was thinking about what is different between my custom setup, the original STM32H735G-DK setup with the Rocktech Display and timing since this seems to be an issue with the framebuffers and LTDC bus switching between framebuffers.  The only thing I changed timing wise was the LCD Clock.  The RockTech Display says it operates at a nominal of 10MHz and the CubeMX is set for 9.6MHZ (within tolerance).  The EastTop display I’m using says it wants 33.3MHz, so I set mine to exactly that by changing the DIVM3 to /6 and DIVR3 to /36.  I’ve been sticking to this assuming the display just wouldn’t work at all if I “under clocked” it, turns out I was wrong.  So just for fun I decided to change settings back to DIVM3 = /25 and DIVR3 /30 (9.6MHz) and not only does the display work, but the “glitching” is completely gone.

Now I know this isn’t the right way to fix the issue long term, this display should be clocked at 33.3MHz.  One thing I notice now is that depending on the colors I’m displaying there is a noticeable pulsing to the display…it’s minor, and for a proof of concept this is perfectly acceptable to move forward with, but for a final project it definitely is not.  I suspect the actual problem is that the TouchGFX project is written with a 9.6MHz pixel clock in mind and this is factored in when timing the refresh rate of the framebuffers.  Where this is in the code I have no idea, and I don’t even know where to look.  If someone could point me in the right direction and tell me exactly what file to look in it would be immensely helpful.  Considering that using the proper pixel clock and turning off the ChromeART in the TouchGFX window in CubeMX significantly reduced it, is there a ChromeART or DMA2D setting I need to adjust?  Is there another clock that needs to be a multiple of 33.3MHz to match peripheral timings?

[Nicholas Yunker_2]

OK, so I think I figured out what is going on.  It appears I was violating the limit of the Pixel Clock limit of the MCU:

Using the LTDC and the DMA2D with the 8bit HyperRAM connected to OctoSPI2 appears to limit the Pixel Clock to 22MHz and with a 24bit RGB 800x480 display apparently working near 60FPS (I probed the VSync signal with my o-scope) puts the Pixel Clock calculation at 25MHz using the equations outlined here: https://support.touchgfx.com/docs/development/scenarios/running-graphics-from-external-ram#step-2-display-requirements-and-pixel-clock-calculations.

Even though my display datasheet says it should run the LTDC at 33.3MHz I tried underclocking the display at 24MHz using CubeMX which my o-scope showed the FPS down to 42FPS and the calculation saying my pixel clock is now near 17MHz.  This works perfectly now.  Unfortunately I don't think this is the proper way to reduce the FPS of the LTDC.  Is there away in the Code to to adjust this?  If so, where?  Or is this the correct way to set the FPS?