STM32H747I-DISCO and Custom STM32H747 Board – Persistent Horizontal Lines and LCD Corruption
Hello everyone,
I have been experiencing a persistent LCD display corruption issue with my STM32H747I-DISCO board, and despite trying several suggested solutions on this community, I have not been able to resolve it. I would appreciate any suggestions from ST engineers or anyone who has experienced similar behaviour.
1. Hardware and project details
-
Board: STM32H747I-DISCO
-
Board revision: MB1166 A03
-
Board identification: A225300870
-
Development environment: STM32CubeIDE / TouchGFX
-
STM32CubeH7 package: V1.13.0
-
LCD controller: OTM8009A (according to the board revision history for the standard A03 configuration)
I initially created a project using the STM32H747I-DISCO template in TouchGFX Designer.
2. Problem description
When displaying a static image or video using TouchGFX, horizontal lines and display corruption appear after the board has been powered on for some time.
The problem occurs even when displaying a static image, although video playback causes the corruption to appear much sooner.
Once the corruption starts:
-
The horizontal lines progressively become worse.
-
Resetting the MCU does not restore the display.
-
The display only returns to normal after completely removing power from the board for several seconds and powering it on again.
-
The problem eventually reappears.
3. LCD controller configuration experiments
Initially, I suspected that the issue might be related to an LCD controller mismatch.
According to the STM32H747I-DISCO board revision history, the standard MB1166 A03 configuration should use the OTM8009A controller.
However, I also tried implementing the NT35510 controller configuration based on the solution discussed in the following ST Community thread:
STM32H747I-DISCO BSP Example 1.11.0 doesn't display on LCD screen
After implementing the NT35510 configuration, the problem did not disappear. However, the time before the corruption appeared increased significantly. With OTM8009A, corruption sometimes appeared within seconds or minutes, whereas with NT35510, it could take several minutes or even hours.
I also tried changing the display pixel format from RGB888 to RGB565 with both controller configurations, but the issue persisted.
4. Additional hardware testing
To determine whether this was specific to the STM32H747I-DISCO board, I also tested my own custom-designed PCB based on the STM32H747.
Surprisingly, I observed similar display corruption on both the custom board and the STM32H747I-DISCO.