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.

[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.

[Tesla DeLorean]

Looks more backlight/diffuser

[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

[mattias norlander]

I have no clue... Not even sure I am able to follow exactly how events unfolded in this thread...

I assume this is a follow-up thread of a previous thread?

My interpretation and attempt so summarize my understand of the events in this thread leading to the current status:

1. Git stored v1 of application works well on H747I-Disco
2. A change is made to the ioc-file and the v2 application is loaded to the board
3. v2 Application hangs with black screen
4. HTD reverts to back to v1
5. The photos are taken which is submitted with the "circle" and the "lines" these are with previously working v1 of application?!
6. CubeIDE reset GPIO pins? With which version of your application v1 or v2?
7. Which lines in the ioc did you change?

General thought? Have you compared your configuration of this board with some working example project?

Wearing "IDE-team hat" I can fairly confidently say that this issue is very unlikely an "IDE issue" (compiler/debugger issue). It is a CubeMX/FW or board issue. But given the information available we have nothing to analyze.

@Adam �?yskawa​ , I think we need you to supply the project with re-producible issue and a working version. Alternatively you need to further debug and try various settings, possibly compare with example projects.

Kind regards, Mattias

[HTD]

UPDATE: I've just created the project on GitHub, it reproduces the screen burning issues, step by step, from creating new TouchGFX project to the issue first appearing, I made screenshots of the invalid changes in CubeIDE, screen burning patterns, then provided screenshots from workarounds removing the issues, also there are commits from every step. Please read further, because I still need advice regarding how to report the issues I found the most proper and recommended way.

BTW, when creating the test project I also made a nice debugging function that shows debug messages on the LCD screen, also it mounts the USB disk via OTG as the last step of making everything work. However - the intermediate commits show issues that are not related to my code and indicate that there might be some bugs either with the code generated by TouchGFXDesigner, or STM32CubeIDE, or both.

---

Well then, it is a quite time consuming task, but I will provide the GitHub repository to reproduce this issue. However, it probably be best if I start a new thread about IDE issues. Here we have 2 issues that are loosely related. One - when a certain combinations of signals are by mistake (or any kind of user code bug) applied to the LCD, something disturbing is happening to it. It makes it malfunction for 15 or more minutes, that looks like a permanent damage, but it eventually goes away. The second issue is the IDE applies random and unnecessary changes to the project that are completely unrelated to the user requested change. To be specific - when you start a new TouchGFX project and open it with IDE, then you configure USB OTG HS configured as External Phy - the IDE resets GPIO pin configuration for nearly all pins on GPIO J port despite it doesn't need those pins for anything. This should not happen, but it does. When I was testing USB issues - I triggered the behavior 3 times, so that's why I guess it's reproducible.

If you the IDE developer, then there are more issues. Like generating the code for USB host initialization. The function MX_USB_HOST_Init() is put inside a __weak function in main (TouchGFX_Task() AFAIR). That function is overriden by a code that is generated by TouchGFX. It is not called.

Those are only issues specific to USB OTG on STM32H747I-DISCO.

I don't know what team is responsible for addressing those issues and how to report them the best way. My guess would be it's the specific board setup issue, not the IDE itself that is just a tool that does what it is configured to do.

My idea to help with reproducing and solving those issue would be to create a new git repository, then create a branch for each issue and then provide a commit for each step leading both for the issue to occur, then the commit with a workaround for that issue. It will take a significant amount of time, so I will be able to do it when I finish with my current project - so it will be like a week or 2.

BTW, I start new projects with the TouchGFX designer. Is it the recommended way to start TouchGFX projects?