Frame buffer in internal RAM is empty

[SThon.1]

Hi,

I have a custom board setup using a display connected via SPI and I've used the example code from the STM32L496G-DISCO board as a reference.

My SPI display driver works correctly as I am able to send data directly to the display and show it on the screen.

However, I have not been able to interface TouchGFX to display anything on the screen. By using the STM32CubeIDE debugger I can see that the frame buffer is empty, so I suspect something with setting up TouchGFX is incorrect.

I have been able to use the simulator in TouchGFX designer to show my design. And I have also ran my application on the STM32L496G-DISCO board successfully.

I followed the suggestions and defined the frame buffer globally in main.c: https://support.touchgfx.com/docs/development/board-bring-up/how-to/03-display-internal

Is there a checklist of things to look for when starting up TouchGFX, or a suggested starting point for debugging when the frame buffer is not being updated?

Any help would be much appreciated :)

Best regards,

Steinar

[Martin KJELDSEN · Accepted solution]

TouchGFX may not be rendering anything.

Are you creating your project from CubeMX ? What are you using to drive TouchGFX? If no tick, nothing is rendered, Are you able to break inside setupScreen() of any of your views? (you'll only be if you signal TouchGFX engine to continue after receiving a sync signal from your display, or similar).

/Martin

[Jagdish Bisawa]

Hi @SThon.1​ ,

It appears you are using an LCD display that has a controller chip ( & a frame buffer ) on it, to which you have been successfully been able to communicate over SPI.

Your graphic logic is correct, so you are able to successfully run it on the simulator & the Discovery board.

By the above presumption, when you use an LCD display with a built-in controller, you might be defeating the purpose behind using TouchGFX, which has been designed to be used with the STM32 microcontrollers with the DMA2D hardware.

If, however, the above presumption is incorrect, then it needs further investigation.

Can you share the details of the display you are using ?

/Jagdish Bisawa

[SThon.1]

Hi Martin,

thank you for the quick response!

I used CubeIDE to create the project and TouchGFX designer to create the GUI. I also compared and ported code from a working example for the STM32L496G-DISCO board.

TouchGFX is driven from the same timer as the HAL_IncTick() with a 1 ms interval by calling TouchGFX_TickHandler() from the timer callback in main.c

I am not able to break inside setupScreen() when running on my custom board, but I was able to on the STM32L496G-DISCO board so that proves your insight is correct that TouchGFX is not driven properly.

Also, when I drive the TouchGFX_TickHandler() from the interrupt I never see a call to TouchGFXHAL::enableLCDControllerInterrupt() which I expect from comparing with the implementation on the Disco board. If I don't drive the interrupt, then I see the call and also a call to enableInterrupts(), but no flushFrameBuffer() obviously since the engine is not driven.

I am not sure how to signal the TouchGFX engine after I receive sync from the display, so that sound like the culprit.

Best regards,

Steinar

[SThon.1]

Hi @Jagdish Bisawa​ ,

thank you for your insight.

Your presumption is correct that I am using a LCD display with a built-in driver chip. It is using the ST7789, which is similar to the Discovery board LCD which use ST7789H2. Here is a link to the display (the 1.54" version): https://learn.adafruit.com/adafruit-1-3-and-1-54-240-x-240-wide-angle-tft-lcd-displays?view=all Also, For reference, I am using the STM32WB55 microcontroller communicating over SPI to the display.

However, from my understanding TouchGFX can be used for a multitude of display type and its main purpose is not only to support STM32 microcontrollers with DMA2D hardware, but allow an easier way of implementing a functioning GUI with touch interface. In my previous workplace we used TouchGFX which interfaced with STM32 microcontroller without the DMA2D hardware successfully. Although this was before TouchGFX was owned by ST.

I hope it is not the case that TouchGFX now only supports STM32 microcontrollers with DMA2D hardware, because I have been very happy with TouchGFX in the past and this would prevent us from using TouchGFX for this project.

Best regards,

Steinar

[Jagdish Bisawa]

Hi @SThon.1​ ,

Have you been able to make any breakthrough ?

I have gone through the TouchGFX help link sent by you & the datasheet(schematic) of the Discovery board referred by you & have the following observations :

1) From the TouchGFX help link, it is clear that you will have to write a driver for the display controller chip ( it is required to init the chip after power up & do required configuration ). Further, the framebuffer content in the internal RAM has to be continuosly sent to the display controller/driver chip. This means that TouchGFX will render to the internal RAM & another piece of code will transfer the internal framebuffer RAM content to the display. Have you been able to locate/know where is this happening ?

2) The L496 Discovery board interfaces to the display controller chip in a parallel manner. So, there is a difference in the way the Discovery board works & your board works;

3) You have mentioned about signalling the TouchGFX framework after receiving a sync from the display. What does this mean ?

/Jagdish Bisawa