2026-01-05 12:48 PM - last edited on 2026-01-06 2:09 AM by Andrew Neil
Hello Forum,
I’m working with a custom display that uses an ST7789V controller (GRAM) connected via FMC and MDMA.
The single framebuffer is located in .RAM2.
The microcontroller is an STM32H750.
The application (the .text section) runs from QSPI flash, while the internal flash contains only the bootloader.
Some widgets (such as TextArea) are rendered correctly, but others (like ToggleButton) appear corrupted.
Additionally, the background image shows horizontal line artifacts.
Please compare the two pictures:
Has anyone experienced similar issues or has suggestions on what might be causing this behavior?
2026-01-05 1:19 PM
The same behavior occurs when using a partial framebuffer located in .RAM2.
Also, L8 compression has no effect on the graphical artifacts — the distortions and horizontal lines remain unchanged.
2026-01-06 2:08 AM
Hello @Andi ,
Could you share your linker file and the map file of your application?
2026-01-06 11:59 AM
2026-01-06 1:33 PM
Hi Osman,
I previously shared the linker script used for the single framebuffer configuration. For the partial framebuffer setup, the linker script might need to be different.
The partial framebuffer is actually my preferred solution, but I also implemented the single framebuffer to compare the behavior and experiment with the graphical artifacts.
Could you please provide example linker scripts for both variants (single framebuffer and partial framebuffer)?
Thanks,
Andi
2026-01-09 5:37 AM
Hello @Andi ,
I can see from your map file that your assets are placed in external flash. Are you sure you have configured it well and that your hardware can read from it? (is it mapped or unmapped?)
By the way, in the linker you have no mention of this extflash section, I'm not sure how you place the assets in external memory with this linker.
2026-01-13 1:10 PM
The STM32H750 has only 128 kB of internal Flash, so the project is structured as follows:
The two attached linker scripts are well commented and describe this memory concept in detail.
The application starts correctly from external flash, and the behaviour on the display matches what I described at the beginning of the discussion. The FMC appears to work in general, as the text on the display is shown correctly.
2026-01-20 6:51 AM - edited 2026-01-20 6:52 AM
Hello @Andi ,
I think you need to isolate your issue first of all. I mean, you need to try with a small & basic project with just 1 image (like a box in red color #FF0000) and put it in internal flash - then check the memory and the display if it shows correct framebuffer. Then if that works, move the image to external flash and redo the same. Because we don't know now if the issue is coming from the external flash or if it's a display issue, or even a framework issue.
I've verified your linker STM32H750ZBTX_FLASH_EXT.ld. It looks ok to me.
2026-01-20 1:15 PM
Hello Osman
I followed the approach that was suggested in your response, and with the help of Copilot I was able to run several code reviews and test to isolate the root.
It turned out to be related to the image orientation handling in TouchGFX. The global default orientation was actually correct, but it wasn’t applied to the individual image entries. Each image — including button graphics — needs its own format and orientation explicitly configured. Since these per‑image settings are somewhat hidden in the UI, it was easy to miss.
I now have a working solution with only minor visual defects remaining. These will be the focus of further optimization and experimentation.
I’ll share more details about the final solution once I’ve completed the next round of improvements.
2026-01-21 4:17 AM
Hi Andi,
Happy to hear that you were able to find the issue :)
For the image rotation, each image can have its layout rotation parameter configured here:
If you select "default", it will use the layout rotation set in the default image configuration window: