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

[AKG]

@vtunr​ ​ : option 1 it is for us.

But I do not understand when you say MPU is disabled ? Does it mean you don't use external SDRAM and QSPI ?

I see in one of your answers above that you use QSPI and external RAM. so may be you can try to check its configuration once again if that helps.

[Martin KJELDSEN]

@AKG​  amazing find!

[Martin KJELDSEN]

I forgot to tell you "nice find". This is still interesting and something we want to investigate and possibly document re external memory/dma2d configuration.

[Martin KJELDSEN]

Look at this code we have in an old demo for STM32F769-EVAL. Look at the comment.

 /* Configure unused area of QSPI region as strongly ordered.
    * This is *important* to avoid unintentional fetches from illegal
    * addresses due to cache/speculation which would halt the MCU.
    */
    HAL_MPU_Disable();
    MPU_Region_InitTypeDef MPU_InitStruct;
    MPU_InitStruct.Enable = MPU_REGION_ENABLE;
    MPU_InitStruct.BaseAddress = 0x90000000;
    MPU_InitStruct.Size = MPU_REGION_SIZE_256MB;
    MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
    MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
    MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
    MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
    MPU_InitStruct.Number = MPU_REGION_NUMBER2;
    MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
    MPU_InitStruct.SubRegionDisable = 0x00;
    MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
 
    HAL_MPU_ConfigRegion(&MPU_InitStruct);

[Martin KJELDSEN]

Out of curiosity - What in particular did you fix in your configuration?

[Martin KJELDSEN]

Hi @vtunr​ ,

It seems, from the fixes that have been proposed, and the MPU configuration that we have ourselves in some of our old demos, that memory configuration is really important here.

Is it possible for you to run in internal ram to see if the issue goes away? In the meantime i'm trying to get some feedback on the fix for the external ram configuration

[vtunr]

@Martin KJELDSEN​ Framebuffer is too big for internal ram unfortunately.

Though from what I read, MPU should be enable for F7, so I guess I'll try this, and follow what @AKG​ found. I'll report back.

[JLee.32]

@Martin KJELDSEN​ 

Is this issue solved in 4.17.0? It seems I got the same issue. I upgraded TouchGFX from 4.13.0 to 4.17.0 yesterday. My UI ends up freezing, but it never happened for 4.13.0. Is there anything I can do if you are still interesting in this issue?

[Ruslan Manianov]

Hi. So is this problem still not resolved? I have got it after few month of developing GUI. I try fix it two days and i can't it. And what now? Other gui library?

[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)