I have a problem with VSYNC and TouchGFX since a recent update of the toolchain. model::tick is called too often.

[WSchr.1]

The change in the generated code is in TouchGFXConfiguration.cpp touchgfx_taskEntry().

Before the update it called OSWrappers::waitForVSync();

Now it calls

 if (OSWrappers::isVSyncAvailable())

 {

  hal.backPorchExited();

 }

which does not reset vsync_sem in OSWrappers. So the tick is called again and again.

I am not sure if the change came from CubeMX 1.6.10 or TouchGFX 4.15 or STM32H7 1.8.

I am using STM32H743, LTDC with internal framebuffer, a RGB565 Display and no RTOS.

As soon as AZURE RTOS is available, I plan to use it, but until then I have to keep my application running.

I can change the code back to waitForVSync(), but it will be overwritten, when I regenerate the code with CubeMX.

[Lagodolio]

Do you check the "to LTDC (Mhz)" in CubeIDE/Mx Clock Configuration? It is in the central zone of the Clock Config Page, under "to FMC" and "to Quad SPI". It must be set to the right values of your monitor spec.

[Lagodolio]

Ops, I notice you are not using CubeIDE... I'm sorry for my mistake.

[WSchr.1]

Thank you for your answer.

I am using CubeMX and CubeIDE for my project.

The LTDC pixel clock is ok. It is set to 6 MHz, which gives me ~65 Hz @ 240x320.

Currently my workaround is placing an additional line in Middlewares\ST\touchgfx\framework\include\touchgfx\hal\HAL.hpp:

virtual void backPorchExited()

    {

        swapFrameBuffers();

        tick();

        OSWrappers::signalRenderingDone();

    }

[Lagodolio]

Hi, I checked my projects and none has "OSWrappers::signalRenderingDone()" line, but I always use FRERTOS...

[Lagodolio]

What do you select in "Software Packs-> STMicroelectronics.X-CUBE-TOUCHGFX...->TouchGFX Generator->Driver-Real-Time Opereting System"? and in "Middleware->FreeRTOS->Interface"?

[WSchr.1]

Middleware FreeRtos Interface: Disable

TouchGFX RTOS: No OS

But I think I can live with this workaround until Azure Rtos with TouchGfx integration is available.

I use H7 CPU, which according to STM will be supported first.

I just made a copy of my project and activated freertos according to a PDF from a STM workshop (0.Lab Startup Project Full Setup New Template.pdf).

I got it to run on RTOS without the call to OSWrappers::signalRenderingDone();

So maybe I give the RTOS a try.

[AFroi.1]

Yeh, I think there is a bug since TouchGFX 4.15 with calling Model::tick

I have the same problem after update from 4.13 to 4.16 and I found the same reason as WSchr.1

I solved it more or less in the same way.

From my point of view there is a concept failure in Vsync handling since 4.15

I think the intention was to provide functions which notify the start of a frame (static void signalVSync()) and an indication if the rendering of the next frame is done (static void signalRenderingDone()). For this indication the variable vsync_sem is used. It will be true as long as the rendering process takes.

But here is the first failure: signalRenderingDone() will never called from a rendering process. I'm not deep enough in TouchGFX to find the right place to change this.

But even if signalRenderingDone()) would be called, the variable vsync_sem would be a longer time true and isVSyncAvailable() return for the whole rendering time true and at the end Moedel::tick would be called very often instead of once per frame.

This is the concept failure I'm talking above.

[AWeng.2]

I have the same, took me quit some time to debug... but how can we change that without inserting code at places where it gets overwritten from the toolchain?

[moredatalesscenter]

@Martin KJELDSEN​ I recently upgraded from TouchGFX 4.14.0 to 4.16.0 and it has increased the CPU usage significantly. Could you describe if calling OSWrappers::signalRenderingDone() is the solution and what the body of it should contain?

[AWeng.2]

@moredatalesscenter​  after the update the TouchGFX does not wait anymore for VSYNC Interrupts, so it tries to do as many updates as it can. Thats the cause you see the CPU usage increase.

In fact the vsync_sem gets set in in the interrupt, but never reset. So you need to add the function OSWrappers::signalRenderingDone(); somewhere.

 /* Infinite loop */
 /* USER CODE BEGIN WHILE */
	while (1) {
 /* USER CODE END WHILE */
		MX_TouchGFX_Process();
 /* USER CODE BEGIN 3 */
 OSWrappers::signalRenderingDone();
	}
 /* USER CODE END 3 */