low costs Touch gfx gui freezes

[Jin454]

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.

[GaetanGodart]

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,

[Jin454]

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]

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,

[Jin454]

1 )
Yes, but for the TE interrupt I use an additional function - vsync partial buffer, so there are some differences in the code. To implement this function, I used a video on the STM channel https://www.youtube.com/watch?v=Ra-83E1heB4&t=7s Without this feature (TearingEffect) it seems to freeze faster and run much slower.

2)
My TouchGFXHAL.cpp file doesn't contain void HAL_DSI_TearingEffectCallback(DSI_HandleTypeDef* hdsi). But i try this function( HAL::getInstance()->allowDMATransfers(); ) after frame update and doesn't help.. maybe it works only on DSI interface

3)
i tried some options to debug via st link. And its look like slow down but not. It hangs in HAL_Delay, before HAL_Init. Maybe there is some problem with internal oscillator ? It start normally without debug.

4)

Framebuffer is in internal RAM on default address. Everything is in internal memory without 2-4 pictures placed on spi flash.

Designer 4.23.0
IDE Version: 1.14.1

[GaetanGodart]

1)
It is great to use VSYNC partial buffer.
Have you implemented a VSYNC timer (they implement it at the end of the video you sent but they call it HSYNC). After that you also need to implement the code. The video doesn't show that. You could look at the TBS of the H503 where we implement the function in the TouchGFX_HAL.cpp file. To check a TBS, just create an empty project with the mentioned board from Designer, the TBS is all the files generated by the creation of the project.

3)
Internal oscillator shouldn't have a problem. Are you using the internal oscillator or did you put an external one on your custom board?
Did you set up your clock on your CubeMX project accordingly (choosing between HSI for internal or HSE for external)?

You could still get some info by printing on the computer's console, this doesn't take much resources from the MCU. Enable one of the USART and read it through Putty for instance by using the function HAL_UART_Transmit.
Here is a video guide by ST : https://www.youtube.com/watch?v=JWOV4j5fCS4
And here one from a third-party : https://youtu.be/dEQwSl8mCFs?si=l8EYJgAjIqcLvEhK&t=38

4)
So everything is in internal RAM except for 2 to 4 images that are un the screen's external memory?

Is the freeze occurring when one of the assets from the external memory have to be displayed?

5)
The screen you use is 480 by 320 pixels with 16bit color depth. This seems to be a big screen for a 64MHz MCU (assuming you use STM32G0B0CET).

What is your baud rate?

Regards,

[Jin454]

1)
The H503 example uses the TE pin and VSYNC/HSYNC. I only use the TE pin. The movie has a second part.

3)
I only use internal oscillator for test, probably LCD + Debugging via stlink is too much for this uC.

4)
Even everything is in internal flash/RAM. It crashes fastest when using a text-only scroll wheel.

5)
32 Mbit/s. The problem with this LCD is that I have to change the framebuffer format from RGB565 to RGB666, which may cause problems.
For now I'm trying to rewrite the entire LCD driver, so we can close this topic for now.

Thank you for your time. Regards.

[GaetanGodart · Accepted solution]

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,