Problem with TouchGFX on STM32H747-DISCO: freezing while an other task runing with higher priority.

[LBESO.1]

Hi ! I'm currently working on a STM32H747-DISCO with TouchGFX to test and discover this graphic library. 

My touchGFX app is only 2 screens with a button to go screen 1 or 2 with a slide animation.

But when I'm implementing an other task in FreeRTOS with a higher priority, TouchGFX freeze at some point when i'm changing screen. My goal was to see when the animations of the library would lag with an other task running on the M7.

Do you have any idea why the screen freeze ? It may be linked to the slide animation of screen.

[LBESO.1]

Hi,

Some updates over my problem :

• I tried all the different animations for screen's transition in touchGFX and when i stress the CPU the task still freeze.
• I noticed that I'm not using the optimize for size option (Os) of the builder but it doesn't really changed anything.
• I used SEGGER SystemView to monitor the runing app. Here are the results. The touchGFX task will stopped after few screen transition.

Here is the file SVDat if you want to look at it : https://drive.google.com/file/d/1Z3YvgpPZ90nGc7_hL4iW0EWeuJfaSyFT/view?usp=sharing

Thanks !

[Xzhiy.1]

May be you cannot use osdelay() in task, use delay in task is not a good idea from my opinoin.

[Xzhiy.1]

I'm Wong, for the reason of we can replace osDelay() with for(;;).

[LBESO.1]

Hi, thanks for your advice.

But i already tried to use HAL_delay() or vTaskDelay(), same result.

An OsDelay() is calling vTaskDelay() so...

[Xzhiy.1]

But...，osDelay() will call vTaskDelay() which will call vTaskSuspendAll(), this means you suspend the scheduler and leaves interrupts enabled, when TE （GPIO line）arrived, HAL_DSI_TearingEffectCallback()（） is called in interrupt handler, DSI start to transfer the frame buffer data to screen with help from LDTC interface , and call OSWrappers::signalVSync() to signal TouchGFX egine to start render work again，this function put a message in queue and returned, this procedure avoid tear effect on srcreen.

so when CPU_BURNER_task1 run and suspend the scheduler somehow, TouchGFX engine lost chance to render. TE always come, and signalVSync() called again and again, the message queue just one place, you can't put them in?

You may instead osDealy() by for() to see what happed.

[Xzhiy.1]

And use printf in ISR ususally not good way, a better way is printf to RAM and print out in a low pri task, it my personal opinoin.

[LBESO.1]

Oh i see your point. I will try with some loop instead to suspend the task.

For the printf just using it when I want to test the duration of my task burner. I'm not using printf when i try with the both task. And anyway I'm using JLINK from SEGGER to get RTT printf set up as No block skip mode.

Thanks a lot for your help !

[LBESO.1]

Okay, It seems I don't really understood what you meant by "You may instead osDealy() by for() to see what happed."

My goal is to suspend my CPU_BURNER task to let TouchGFX's task breath and see what happen if i stress it too much.

I can't suspend a task with a loop? I need to use vtaskDelay() anyway no ?

[Xzhiy.1]

I mean use for loops instead of osDealy(), something like this:

volatile uint32_t c;

for(uint32_t i = 0; i<1000000;++i)

{ ++c;}

it may not help, but I guess delay too long will cause somthing no good. especially with higher pri task.

[LBESO.1]

oh yea sure