STM32H747I-DISCO - screen burning.

[HTD]

It happened again, after changing some configuration in STM32CubeIDE ioc file. Breaking change, the application hanged with black screen for no apparent reason. As I tested with the debugger - it passes all initialization in main(), then hangs when starting TouchGFX.

Not the first time. I reverted all changes from Git, downloaded the previous version and I got a burned screen. A rounded white rectangle burned in the display, blinking, random horizontal lines scattered and blinking.

BTW, the screen was not hot. Not even warm. I once seen it happening on white background. It looked like the corners of the screen started to burn away to black. After fixing the software issue I've seen a negative of that pattern. After 15 minutes of being powered off the screen worked normally, without artifacts.

After turning the device off for 15 minutes it got back to normal. I tried to power the device earlier, but I still got some artifacts, but they seemed to fade away with time.

Does anyone know why something like this happens? Is it dangerous? How could I prevent it in the future?

[Osman SOYKURT]

Hello HTD,

Can you share with us a picture of your screen when it's happening ?

/Osman

[HTD]

Notice the light ring around the screen content, also the horizontal lines - they are not there normally.

Here's the larger version of the bottom of the screen.

The picture was taken a few minutes after it happened. Earlier it looked far worse, the ring was solid white, the original content was barely visible, the whole screen blinked.

I don't know how to even reproduce it. I don't know if it would be even safe to reproduce it.

[Tesla DeLorean]

Looks more backlight/diffuser

[AMars.4]

I've seen this before when I connected a different screen to a board that was programmed to send initialisation code for another screen, same as you describe, got better over time after the correct initialisation code was added.

Usually the panel manufacturer will provide a sequence of commands to send to the screen on power up via SPI or whichever means, if I remember rightly some of these include voltage levels which will vary between panels.

Anthony

[HTD]

I discovered WHY it happened the last time: STM32CubeIDE without any warning reset several GPIO pins, including LCD_RESET and LCD_BL. The bug is reproducible, I stumbled upon it again and this time I had no other changes on my git repo. So - disable those pins and the screen fryer is ready.

So - without those signals the screen seems to "burn out". It goes pretty quickly, fortunately not as quickly to cause problem in the time I flash the changes to the chip.

When it happened before, I just disconnected the LCD panel before downloading the flash update.

The good news is today my device survived over 20 minutes in this state and it seems there's no permanent damage.

[Osman SOYKURT]

Hello HTD,

Ok, thanks for reporting this issue, I don't think it's dangerous but just in case, better ask to STM32CubeIDE Team. @mattias norlander​ do you have an idea ?

/Osman