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

[Martin KJELDSEN]

Checklist:

• When did it start happening? Maybe you can try down-grading since you're just using the framework files to see when it started.
• Introduce lock/unlock counters
• Using any modified copies of .cpp files from an old framework version? You'd be missing out on potential bugfixes.

The HAL code generated from TouchGFX Generator would most likely give you a decent speed boost since we switched to pure register-access only. You might just generate a bogus project from cubemx and steal the code from the STM32DMA class.

/Martin

[vtunr]

Hi Martin,

Thanks for the answers. It looks like the problem is very similar ! Hopefully we'll be able to get the bottom of it with you and @AKG​ .

I'll make more test in the coming days with your checklist and let you know.

[Martin KJELDSEN]

Sounds great!

/Martin

[Luca G.]

I have the same issue! I'm using TouchGFX Generator 4.16.1, I have created the project with STM32CubeMX (6.2.1) and I'm using STM32CubeIDE (1.6.1).

In my case I do not use OS.

I awaintg any news! I am not able to go on with the project.

Luca G

[Martin KJELDSEN]

I need details of your hardware setup. Thanks

[Martin KJELDSEN]

Also, can you show me a screenshot of your application or give me a list of widgets you're using? How does it happen? When does it happen?

/Martin

[AKG]

Hi @Martin KJELDSEN​ :

Please find the details for your checklist.

1) Till now we were in development phase and never tried to stress test the device. Therefore I cannot say since when this was seen. May be this issue was always there and it is now we are observing it.

2) I added the counters in lock/unlock functions. I was able to reproduce the issue again. Here is log :

 

I had programmed to break when the lock counters are 2 more than unlock counters. But unfortunately it did not break there.

This trace is when the function takeFrameBufferSemaphore waits forever.

3) I am pretty sure that we have updated all the widget files while upgrading the touchgfx. I also now cross-verified the files and they are indeed the latest one's.

I am testing the device further and hopefully we get a break in lock counters section. I will inform here as soon I have any update.

[Martin KJELDSEN]

This is really helpful @AKG​, thanks for being thorough​.

[AKG]

Hi @Martin KJELDSEN​ : I have few more questions regarding this problem.

1) I compared my OSWrappers.cpp with the generated one. Most part of the file is similar. The only major difference I see is that the HAL::getInstance()->backPorchExited(); being called in function void OSWrappers::waitForVSync() in generated file. I am not calling invoking backPorchExited() in my OSWrappers. Does this have any effect on this issue ?

2) I saw this particular fix in known issues section of touchgfx https://support.touchgfx.com/docs/miscellaneous/known-issues#textarea-and-chromart-dma2d

 

At the moment I do not have this change in my source code. Does this have any effect on this issue ?

3) I am thinking of creating a global uint64 variable and set every bit at the start of widget draw function and reset it at the end of draw. By doing this, we may find out which widget draw is trying to lock the buffer and not unlocking it. Does this technique help in finding the problem ?

Can you please help in clarifying ?

[Luca G.]

Sorry for delay but I was investigating for the problem.

Fortunally I fix it: the problems was in the external memory (where there are the graphic buffers) that wasn't initialized in the right way.

However this post is very interesting because seems that in particular cases the touch gfx stucks in takeFrameBufferSemaphore.

Many thanks for support.