UI stuck in takeFrameBufferSemaphore

[Gom]

Hi

When switching between screens fast, my UI always ends up freezing. Debugging reveals that it waits forever, waiting for the frame buffer semaphore.

Here is the call stack:

 

Inspecting other running tasks shows nothing wrong. Only the graphics task should touch the frame buffer semaphore, right? So it should never deadlock?

Environment:

• IDE: Atollic
• RTOS: FreeRTOS
• TouchGFX: 4.16
• OS: Windows

[davidev94_cloud]

Gents, I experimented same problem, with TouchGFX 4.20 in a custom board with STM32H723 and external FLASH and SRAM. The first thing I've done has been to implement a routine, like I saw in a comment here, to unblock in any case the touchgfx. In practice, in case the DMA doesn't report a "transfer complete" and get stuck, a timeout is triggered and the effect is a "lag" on the screen, but not a complete freeze that must be avoid in a final product. See image here attached of the modification in TouchGFXGeneratedHAL.cpp...

Then I started to investigate... A lot of things change the behaviour, causing the "bug" to appears from 1 time in an hour, up to dozens of time in a minute: here some operation that I've done that impact on the frequency the bug appears:

-Changing MPU settings (and so cache policy - I tried every possible combination and with some of then the bug appears very rarely);

-Changing the optimization settings;

-Changing the timing of the SRAM memory;

-Changing the pin output speed of SRAM and LTDC (this is the most strange and what initially scared me and make me to think of a layout problem with high frequency communication with SRAM and LTDC);

-Changing the DMA2D dead time to access AXI bus;

-Proabably other that I do not remember;

But finally...

See the issue I posted in Github: github.com/STMicroelectronics/stm32h7xx_hal_driver/issues/31#issue-1396786830

After the modification, the bug is never happened again. I retouched all the previous settings to tease the micro, using the worst combinations I discover previusly.. and no problem!

In brief:

try to change the line in stm32h7xx_hal_dma2d.c, in the function

void HAL_DMA2D_IRQHandler(DMA2D_HandleTypeDef *hdma2d){...}

from:

if ((isrflags & DMA2D_FLAG_TC) != 0U)

to:

if ((isrflags & DMA2D_FLAG_TC) != 0U || isrflags == 0U)