Screen Flickering on Custom HMI with Double Buffer Enabled (STM32H750 + RGB888, 800x480)

[Shekhar_Sukhabhogi]

Hi,

We are encountering a partial screen flickering issue when using a custom HMI with TouchGFX and double buffer enabled. The screen resolution is 800x480, but only the left portion (480x480) displays correctly. The remaining 320x480 area flickers during runtime, especially when updating data on the UI.

Key Observations:
This issue occurs only when double buffering is enabled.

In single buffer mode, minor flickering is still present, but it's significantly better than dual buffer mode.

The issue is isolated to our custom board and BSP configuration.

Cross-Test:
We tested the same TouchGFX button example on two different displays:

Custom Display Board – 800x480 (TFT-LCD, TST070WVBE-31)
→ Flickering observed

Test Board – 1024x600 (other manufacturer)
→ No flickering observed

The main difference:

Custom board: TouchGFX + BSP drivers (manually configured)

Test board: Fully CubeMX-generated configuration

System Configuration:
MCU: STM32H750

Display: TFT-LCD (TST070WVBE-31), 800x480, RGB888

TouchGFX: 4.24.0

STM32CubeIDE: 1.17.0

STM32CubeMX: 6.14.1

Crystal Frequency: 25 MHz

System Clock: 450 MHz

Display Timing Configuration:
Parameter Value
Width (Active) 800
Height (Active) 480
HSYNC 48
HBP 40
HFP 40
VSYNC 1
VBP 31
VFP 13

Horizontal Total = 48 + 40 + 800 + 40 = 928

Vertical Total = 1 + 31 + 480 + 13 = 525

Pixel Clock Calculation:

PLL3M = 5
PLL3N = 40
PLL3R = 6

VCO = (HSE / PLL3M) × PLL3N = (25 MHz / 5) × 40 = 200 MHz
DOTCLK = VCO / PLL3R = 200 MHz / 6 ≈ 33.33 MHz
Frame Rate ≈ 33.33 MHz / (928 × 525) ≈ **68.7 Hz**

Request:
Could anyone suggest what might be causing the flickering on the right side of the screen (320x480) during UI updates with double buffering?

Are there any known limitations with partial redraws or framebuffer alignment for RGB888 mode?

Could manual invalidateRect() or framebuffer region management be affecting this?

Any experience comparing CubeMX vs. custom BSP configurations in such cases?

We’ve attached the relevant configuration files and video evidence for reference.

Please let me know if additional details are required. Any insights or suggestions to help resolve this issue would be greatly appreciated!

Best regards,
Shekhar

[Shekhar_Sukhabhogi]

Hi, any update on this? I posted about the screen flicker issue with double buffer enabled two days ago — would appreciate any suggestions.

[Shekhar_Sukhabhogi]

Hello everyone,

Any update on my post.

[Osman SOYKURT]

Hello @Shekhar_Sukhabhogi ,

Where are your framebuffers stored? Are they in internal or external RAM? Do you use any assets, and where are they placed? Do you use the DMA to transfer your data? Have you tried testing with a simple UI (no images or text, just rectangles) to check if the issue is visible?

[MM..1]

Start with reading AN4861 (specialy chapter 5.5), plus optimize SDRAM config...

[Shekhar_Sukhabhogi]

Hi,

Thank you for your reply. Please find my answers below.

1). Where are your framebuffers stored? Are they in internal or external RAM? 

Ans: They are stored in external SDRAM at address 0xC0000000 (64MB).

2). Do you use any assets, and where are they placed?

Ans: Yes, we use assets, and they are placed in external FLASH at address 0x90000000 (64MB).

3).Do you use the DMA to transfer your data?

Ans: Yes, we are using DMA2D for data transfers.

4). Have you tried testing with a simple UI (no images or text, just rectangles) to check if the issue is visible?

Ans:

1. Yes, we tested with a simple rectangle (no other widgets or objects), and there was no screen tearing.
   However, once we added a Text widget and called invalidate() from ScreenView.cpp every 1 second, screen tearing occurred — specifically when double buffer mode was enabled.

Please find the attached files for reference.

Thanks

[Shekhar_Sukhabhogi]

Hi,

Thank you for your suggestions. Sure, I will go through AN4861 and try if any clues. 

Thanks.

[MM..1]

Simply solution is switch to RGB565 buffers.

[Shekhar_Sukhabhogi]

Hi,

Thank you for the suggestion.

I have converted the display format from RGB888 to RGB565 and tested again. Unfortunately, the screen flicker issue still persists. Please find the attached details for reference.

Observations:

#1. Framebuffer Mismatch:
One framebuffer is filling the full 800x480, while the other only updates 480x480. This mismatch appears to be the root cause of the flickering.
If we explicitly call bg_box.invalidate();, bg_image.invalidate();, or invalidate();, the flicker disappears.
However, calling these additional invalidate()s in the actual project causes performance degradation, notably touch latency.

#2. Unexpected Blit Behavior:
For an image of size 800x480, we observed:

• blitOp.nSteps = 480

• blitOp.dstLoopStride = 800
  This occurs in the secondary buffer, not in the buffer used during initial image placement.

Note:
This project was adapted from the STM32H750-DK (480x272) TouchGFX example.
However, it does not use CubeMX-generated .ioc configuration for LTDC, DMA2D, or SDRAM.
Instead, it uses custom initialization as per the BSP package.

Please find the attached files for reference.

Request for Guidance:

• Is there an official step-by-step guide or checklist for bringing up a custom display with correct framebuffer alignment and double buffer configuration?

• Any best practices to avoid such flicker issues without impacting performance?

Logic Reference:

void DemoScreenView::updateCountBuffer (int intValue)
{
Unicode::snprintf(countBuffer, COUNT_SIZE, "%d", intValue);
count.setWildcard(countBuffer);
count.resizeToCurrentText();
count.invalidate();

// If I enable any of the lines below, the flicker disappears.
// bg_box.invalidate();
// bg_image.invalidate();
// invalidate();
}

Looking forward to your suggestions.

Best regards,
Shekhar

[MM..1]

Required is change framebuffer format no display format. And for your trouble is not relevant cubemx or adapting.

Primary your memory must work especialy SDRAM. Seems as SDRAM over 2MB fail. First buff ends on 1,1MB ...
And appnote define max clock for double buff with DMA2D to 36MHz on 24 bit. You use 33,33 , then your memory and MCU config cant differ from optimal max more as 8%

Secondary switching from singel buffer target to double isnt one line change, i dont check but folder target in Touchgfx is important for this all.