Skip to main content
Associate II
February 9, 2024
Solved

low costs Touch gfx gui freezes

  • February 9, 2024
  • 2 replies
  • 4473 views

Hi.
I started a small project using a custom board with STM32G0B0, SPI flash and 3.5 inch ili9488 LCD, communicating via SPI using the TE pin, without RTOS. Everything loads fine and quite fast, but after 5-40 seconds the uC freezes. Especially when changing the screen, using widgets like the scroll wheel, or even updating text/widgets after n ticks with a random value.

What I noticed, before I used more than 3 screens and updating the values, nothing happens, even the animation with texture wrapping works. The logo screen containing the black box, image and text loads immediately after the LCD display initializes. Now I need to load the boxand then display the image and text.

 


Any ideas what I should check?
Thanks for the help.

Best answer by GaetanGodart

Hello @Jin454 ,

Sorry for coming back to you so late.

 

The 18 bits format might indeed be a problem as TouchGFX uses 16 bits and even the more commonly used ili9341 also uses 16 bits color format.

 

You can close this thread by selecting a best answer, however, since your problem has not been solved I invite you to keep us updated once you have tried running your project with the updated drivers.

 

Sharing your project could also help us support you.

 

Regards,

2 replies

GaetanGodart
Technical Moderator
February 12, 2024

Hello @Jin454 ,

 

1 )
What are the TE pins?

2 )
I have found this post that seems to have fixed a freeze issue for 2 people. You could give it a try!

3 )
If that doesn't help, could you run your program in debug mode and see where you end up when you freeze?

 

Regards,

Jin454Author
Associate II
February 13, 2024

Thanks for answer.
1. TE pin - Tearing Effect Interrupt from LCD

3. for some reason I can't debug using st-link. It looks like the uC is slowing down dramatically and the TouchGFX gui is not starting. I haven't had this problem using RTOS and LTDC in other applications. What I noticed - the problem appears at various times and only when widgets/entire screen need to be updated. It works stably without it.

GaetanGodart
Technical Moderator
February 14, 2024

Hello @Jin454 ,

 

I will try my best to help you.

1 )
From what I have seen, the TE pins are just extra pins that are not taking care of the data transfer to the screen.
They are just used to send an interrupt when tearing is detected ?
Why did you mention that in your post, do you think it may be part of your issue?
This post seems to say TE pins caused issues for him with TouchGFX.
If you think it is part of the issue, have you tried not using them? What do you do when receiving an interrupt form it?

2)
Have you tried this solution? Were you able to find the TouchGFXHAL.cpp file in your project? (I assume it will also be in a project not using any RTOS.)

3)
That is a problem.
You say you can't debug using ST-Link, are you able to debug some other way?
Can you send message to your computer's console through UART?
You could also try to look at the addresses pointed by PC and LR registers.
What IDE and compiler are you using?
Also, which version of TouchGFX are you using?

4)
Have you looked at our guide to create your own board : board bring up 
Do you know where you put your framebuffer?
Is it DMA?

 

Regards,

February 1, 2026

Hello ST Community,

A developer working on a low-cost TouchGFX project with an STM32G0B0, SPI flash, and a 3.5" ILI9488 SPI display is facing random GUI freezes occurring 5–40 seconds after startup, especially during screen transitions, scroll wheel interaction, or periodic widget updates, despite smooth performance when the project was simpler with only a few screens and animations. The system runs bare-metal without an RTOS and uses the TE pin for display synchronization, suggesting the issue may be tied to SPI bandwidth limits, memory constraints, stack/heap overflow, or blocking operations during dynamic asset loading—particularly now that additional UI elements (box, image, text) are being rendered sequentially after initialization. The behavior points to resource management or timing bottlenecks common in constrained embedded GUI builds like MovieBox-style media interfaces, where increasing graphical complexity can silently push the MCU beyond safe operational margins.
Best Regards!!