cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F769I-DISCO - Really noisy TFT LCD display

lucky38
Associate II

I am a new user of an STM32F769I-DISCO MCU and the problem I'm having is with one of the examples called "BSP". I'm using the STM32CubeIDE to build and run the files. The program does build and run successfully. However, the TFT LCD display looks really noisy: it looks like one of those old CRT TV noisy channels (picture below).

The part that produces this noise is the function BSP_LCD_Init() in the 100th row of the main.c file, which can be found here: (new members can't post links, but it's the BSP example, that can be found by Googling bsp example stm32f7.)

The rows after this function don't do anything, and the picture stays noisy.

The funny thing is that this is an example that comes with the IDE, but it doesn't work for some reason. I already tried this with my laptop and my PC and it comes up with the same result.

Thanks in advance!


_legacyfs_online_stmicro_images_0693W00000bkG1ZQAU.png

7 REPLIES 7
KDJEM.1
ST Employee

Hello @lucky38​  and welcome to the Community :) ,

I confirm the issue and I reported internally.

Internal ticket number: 152338 (This is an internal tracking number and is not accessible or usable by customers).

Thank you for reporting this issue.

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Harvey White
Senior III

At certain stages of development, this is actually a good sign The display controller is reading memory and properly (looks so far) writing it to he display. You are looking at uninitialized memory, most likely. If you know what memory locations are mapped to the display, you can try writing to them directly and see what happens.

It is likely that the example may be pointed at the wrong section of memory to clear, or the LTDC is looking at the wrong section of memory, both are possible.

The reason why this is "good" is that you're setting up the display scanning properly, a necessary first step.

JTP1
Lead

Hello. You seem to have latest version of this display board, MB1166-A09. The type of display has been changed, the user manual um2033-discovery-kit-with-stm32f769ni-mcu-stmicroelectronics.pdf says in revision history:

Board MB1166 revision A-09
The revision A-09 of the MB1166 board corresponds to:
• LCD FRIDA FRD397B25009-D-CTK replaced by FRIDA FRD400B25025-A-CTK

There is some discussion and solution for F469 discovery which has same display change.

https://community.st.com/s/question/0D53W00001x40J8SAI/example-touchgfx-application-does-not-work-on-all-stm32f469i-discovery-boards

You can check also the F4 sw package, does it allready have implement the workaround.

MOBEJ
ST Employee

Hello ,

The fix is available on GitHub  

you just need to enable the right target hardware as defined in stm32f769i_discovery.h

By default, the old board version with OTM8009A is selected ,

/* options in order to select the target board revision: !!!!!!!!!! */
/* USE_STM32F769I_DISCO */ /* Applicable for all boards except STM32F769I DISCOVERY REVB03 */
/* USE_STM32F769I_DISCO_REVB03 */ /* Applicable only for STM32F769I DISCOVERY w/ MB1166-A09 LCD daughter board connected on */

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hey and thank you for all the answers.

These changes actually worked. However, there is still a small "noisy box" in the right corner of the LTDC screen. Looks like the screen resolution is messed up, but the variables that set the resolution seem to be fine. I'll attach a picture to this message.


_legacyfs_online_stmicro_images_0693W00000bklOtQAI.png

The noise looks like uninitialized memory. Please try another background/picture to write, preferably one that ST itself uses. That would close to guarantee the file.

Some possibilities:

  1. that noise is in the file itself
  2. some of the copy settings to write an image are rather wrong.

We can assume that the display is scanning the proper areas of memory, since having that wrong would cause a memory access fault.

One easy test you can do is to write a fixed value to all the memory locations that are supposed to make up the picture. You should get a solid color on the display.

Note that the image seems to be written in blocks, and you're either missing some or they seem to be bad. I'm thinking the file.

oh, and if the resolution were bad, you wouldn't be able to read anything coherent on the screen, so the V and H settings are good.