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

[vtunr]

So @Martin KJELDSEN​ :

• I remember roughly when it started happening. In the end, removing the update of the widget we added around this time (custom one with one image + textarea) seems to improve things, but it still locks after a few hours.
• Same as @AKG​ , counters are ok, it never goes above 1 difference.
• Tried the guard code that @AKG​  posted, it doesn't change a thing for me.

[Martin KJELDSEN]

Great information guys.

We've already started investigating the issue and have replicated the problem with 4.16.1 - debugging underway :)

/Martin

[AKG]

@Martin KJELDSEN​  : It' good to hear that you were able to reproduce this problem.

We hope to hear back soon from you.

[Martin KJELDSEN]

I'll report back. Another customer had the same issues and we re-created his view-stack of widgets/components. This is on an L4.

[AKG]

@Martin KJELDSEN​  : another stack trace if it helps.

 

doesn't look like the problem is just with text widgets.

[Martin KJELDSEN]

We've discovered an error in one of our old application templates (L4R9 DSI), so if you've based yourself on that then that could be a culprit. There is a chance for the semaphore to never get released if the UI task is suddenly suspended.

/Martin

[Martin KJELDSEN]

That's to say - We have not found any widgets where a lock is not released again properly. We have found some target-based code that under some circumstances would not release the lock depending on the state of the UI thread.

[vtunr]

Hi @Martin KJELDSEN​,

Can you elaborate a bit more on the error you have in your template so we can look if we have the same ?

[AKG]

Hi @Martin KJELDSEN​  : Our display uses regular RGB interface. We do use the DSI peripheral. In any case can you please show or highlight the exact error location and possible fix to it ?

Additional point:

As far as I understand, normally you cache all possible widgets in the current active screen and then the draw calls from these cached widgets are invoked by cacheDrawOperations(). Thereafter the cacheDrawOperations() locks the framebuffer.

If there are more widgets in current active screen that are not cached then these widgets try to draw on its own and therefore lock the framebuffer individually.

If I am not wrong, the current failure occurs when framebuffer is already locked by cacheDrawOperations() and before this lock is released some other non-cached widget is locking the framebuffer again and therefore this deadlock.

Could this possibly happen ?

one more point to note here is that, this error is more frequently seen when optimizations is enabled. Does touchgfx has any problem when optimizations() are enabled ?

Would you like to have a look at our project ?

[Martin KJELDSEN]

It's important to note that these findings are based on the L4.

I think the easiest thing to do is just to post/send your TouchGFXHAL.cpp (or whatever yours is called if you're working with older projects).