cancel
Showing results for 
Search instead for 
Did you mean: 

Basic TouchGFX application don't work

Luca1
Senior

Hi to all!

I'm not able to run a very basic (a black screen) TouchGFX application on my hardware. I have follow the TouchGFX documentation and the STM32L496G-DISCO application example, but i wasn't lucky..

In particular I never reach the breakpoint that i put in the TouchGFXHAL::flushFrameBuffer(const touchgfx::Rect& rect) method. Also, if I suspend the debug, i see that the application stack arrive at the method touchgfx::HAL::lockFrameBuffer().

I have modified only the TouchGFXHAL class, in attatched there are this class files, following the documentation and the example metioned above, but maybe i miss something.

Please someone can give me some help?

18 REPLIES 18
Martin KJELDSEN
Chief III

It's not easy to tell unless i have your hardware. My first guess was that you've taken the lock in a custom widget without releasing it again, but i doubt that's it.

Are you calling HAL::getInstance()->lockFrameBuffer() at any point in time?

/Martin

Hi Martin!

I know that it's not easy to tell me something, but i don't know how to search a solution!

I think that is not an hardware problem because i call the lcd controller routine only in the initialize method. I think, but maybe I can wrong, that is a software problem, maybe a wrong setting in the project.

It's possible to have a very basic workng project template that don't depend of the LCD hardware or microcontroller? Or if it's not possible, what steps I do (like write or override some methods) for having a working project?

I have searched HAL::getInstance()->lockFrameBuffer(), but I don't see any call to this function:

0693W000001rHuQQAU.png

Martin KJELDSEN
Chief III

Which Operating system are you using? lockFrameBuffer() ends in a call to a function inside OSWrappers which uses the constructs of your RTOS to syncrhonize the framebuffer.

/Martin

I use the FreeRtos os. I use the CMSIS v2 wrapper for the os.

I have tryed using CMSIS v1, but the result it's the same..

Hi Martin!

I have a news. I have changed the TouchGFX setting from this:

0693W000001rKgvQAE.png

to this:

0693W000001rKhAQAU.png

With this new setting I hit the breakpoint in the TouchGFXHAL::flushFrameBuffer(const touchgfx::Rect& rect) method.

I can't see the correct screen on the display, I think that i need to modify the display setting in appropriate way (horizontal back porch, horizontal front porch etc..) for see something.

I don't know if possible to change the display resolution in this way, i'm not an expert in this area, however the application seem to run..

There are some problems with the 1024x600 resolution @ 1bpp colordepth in TouchGFX?

The problem seem to be the colordepth. Using the RGB565 the application run, i see something on the display but this happens only once. After complete the write to the display, nothing else happens. If I put an image, the application go into the lockFrameBuffer for ever, even if i use the RGB565 colordepth..

Also if I change the colordepth using all the other pixel format, the application go into the lockFrameBuffer for ever...

I know that it's hard to tell me something, but what I do? Am I that I made some wrong settings, is the framework that don't works as expected or is the hardware that don't work?

I'm here to learn, but i don't waste my time in this way. 

What happens if the same situation happens in a real work environment?

I don't pretend nothing, but i think that hasn't much sense to develop a framework that run only on stm32 board.

Maybe I have waste my time, but you have lost some costumers..

Hi Martin@Martin KJELDSEN (ST Employee)​

This is timely as I'm experiencing a similar problem. https://community.st.com/s/question/0D53W00000BJYliSAH/flushframebuffer-is-not-called

Just to update people in this thread - Turns out there was no issue after all. FreeRTOS + NoDMA also works for me here on my L496-DISCO.

/Martin