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]

Hi @Martin KJELDSEN​ : Thanks for your quick response. We are using touchgfx version 4.16. We have a similar problem where the method takeFrameBufferSemaphore() waits forever.

[Martin KJELDSEN]

No problem. Okay, it should have been fixed there. Are you able to share your project in any way? In the middle of 4.17.0 release testing, so won't have much time this week, but - This is the second person who's reported this, so i should take some time to investigate this properly if i can re-construct the issue here at my desk.

[Martin KJELDSEN]

takeFrameBufferSemaphore() is OS-specific - Which OS are you using?

[AKG]

@Martin KJELDSEN​ : Sorry for not providing complete details. We are using embOS. So takeFrameBufferSemaphore() is OS-specific. Could it be that the OSWrappers is not properly implemented ? Should I quickly share you my OSwrappers.cpp ?

Our project is very huge. So, I will see how can I share you my project.

[Martin KJELDSEN]

@AKG​ @vtunr​ - Here's a small task for you. HAL::lockFrameBuffer() and HAL::unlockFrameBuffer() are virtual. Could you try overwriting these and introduce some counters? At any point in time the lock counter should only be 1 higher than the unlock counter.

And then maybe break if the lock counter becomes 2 higher, and send me a stack trace.

Can you both describe the nature of the application in terms of widgets? If it's easy for you to reproduce then you may start with a blank application (set all widgets invisible from the designer) then add more on gradually. We're investigating here if we have some missing unlocks for some widgets that require direct access to the framebuffer (canvas widgets, texturemappers, etc.)

/Martin

[Martin KJELDSEN]

Did you create the project usign the generator? The generator generates a CMSIS OS specific OS-driver (cmsis v1 or v2, depending on what you selected). Which should work with fine with embOS.

I'm more thinking it's an internal problem with us, but i'm investigating (see the above post - I tagged you - for details and some home-work for you, if you have the time).

[AKG]

@Martin KJELDSEN​ Thanks for your reply. We started this project long back with touchgfx version 4.9.3. If I am not wrong, there was no generator at that time. So our project was created without using the generator. Thereafter on every newer touhgfx version, we have only tried to upgrade touchgfx.

I can create a project using generator and compare the OSWrapper implementation.

Also I will try out the task you mentioned above. I will get back to you as soon I have any result.

[Martin KJELDSEN]

Aha, okay. (also, no need to be sorry). The issue was found in 4.9.3 - @vtunr​  is doing the exact same thing you're doing, just updating the framework, when there may be something additional (through the generator, like DMA2D code) that is missing for you.

[Martin KJELDSEN]

Have you modified some of the widget .cpp files from 4.9.3 and kept them? Because the bugfixes we did subsequently would then not be present in your modified versions.

[Martin KJELDSEN]

Also, when did this problem start occuring?

/Martin