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

[Gom]

I noticed that reducing the priority of the DMA2D interrupt from 5 to 9 highly reduces the frequency of the bug. With priority 5, it always hangs after a few seconds. With priority 9, it can run several hours before freezing.

Unfortunately, there's no way to know exactly what happens inside TouchGFX in relation with interrupts and the framebuffer lock. Which makes this problem very hard to debug. It would be really helpful to have some insights from the TouchGFX guys on that subject.

Thanks

[vtunr]

Hi, i'm @Gom​  colleague.

Could someone take a look at our problem ? We'd like to understand and fix this issue once and for all.

Thanks

[Michael K]

If you run the TouchGFX task on its own, does this issue still occur? E.g. don't allow any other task to create. I've been having a strangely similar issue myself and I "fixed" it by removing seemingly unrelated code (RTOS Event Flag processing in another task).

See my thread...

[Michael K]

@Martin KJELDSEN​ this sounds oddly familiar...

[vtunr]

So, after adding systemview to the project, I can have a better view of what's happening. I disabled most interrupt and most of the tasks that were not needed for the device to work. All ISR are instrumented (except Systick so I can record all the other events without overflow). I also added an error message when there is an error release the semaphore :

In the SystemView data, to find the moment it hanged, go to the last error releasing.

As is, we have a crash every minute when switching screens quickly. Here's the initial SystemView file : https://foobot-my.sharepoint.com/:u:/g/personal/tony_foobot_io/EXZrj5YAW7lKowqbPLSE11IB3d6v07Os2ase-T4dj3PpQA?e=Dkqtat

 

We can see that it tried to release the mutex twice, as it defaultTask (the touchgfx task) is not taking it between the two interrupts.

It happens before without any problem, so it shouldn't be the root cause of the issue.

So there is DMA2D releasing it, defaultTask trying to take it without success apparently. DMA2D interrupt are not fired anymore, probably because GUI task is stuck ? or GUI stuck because DMA2D interrupt are not fired anymore ? Hard to answer ...

Then we can see the DMA2D interrupt is fired and process in the middle of LTDC interrupt. It's the only time that we have release mutex twice and DMA2D during LTDC interrupt. LTDC interrupt had prio 9 and DMA2D 5, so it might be the culprit ?

I changed LTDC prio to 5 & DMA2D to 6. It improves the situation as it takes 20-30 min to hang, but it doesn't disappear. SystemView file here : https://foobot-my.sharepoint.com/:u:/g/personal/tony_foobot_io/EUOXkdB9JnpPjurLLI5dpkUBIsh4uaTuf6C5E2xeALu9Tw?e=F4FYOB

So now, we can see the same behavior, except that no LTDC interrupt have been triggered during DMA2D interrupt, so it's not the root cause, but it improves the situation. We can also see that the only things happening at this moment, is DMA2D interrupt & defaultTask, so the external part of the system seems not to have an effect.

The problem is, defaultTask is a black box so I feel we can't go much further. We really need some input from ST on this and since the issue has been open since 15 days ago, the sooner the better. Let us know if you need more information.

Thanks

[vtunr]

@Martin KJELDSEN​ Could you take a look at our issue? As @Michael K​  said, it looks like a similar issue as his.

[Martin KJELDSEN]

Hi, been on easter vacation - Let me see if i can take a look at this writeup today.

[Martin KJELDSEN]

Can you check the actual status of the task? And the semaphore? There are plugins for some IDEs to do this. Switching screens quickly shouldn't have any impact except that the default task may try to take the semaphore while the DMA2D is busy with the framebuffer. And that should be fine - What isn't fine is if the DMA2D interrupt (when done) isn't releasing it.

[Martin KJELDSEN]

I think you may need to share more on the configuration of the project - Single/double framebuffer? Display interface?