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]

But a loop in my higher priority task won't let the hand to the TouchGFX's task cause at the end of the loop my task will start again.

I'm may be missing something important here sorry :/, trying my best to understand.

[Xzhiy.1]

with OS run under preemt topology, high pri CPU_BURNER task have more oppotunity to run than ToughGFX engine, sometimes will preemt ToughGFX to left it to wait, if you use osDelay() to suspend scheduler, making TouchGFX starved, even if TE signal arrived as usual and IT handler send msg to permit TouchGFX to render again, but It have little chance to run, so freeze happened. I don't really know what difference between osDelay() and for loops(use for loops will not suspend scheduler), maybe little diffrence... but I strongly feel higher pri and osDealy is the source of freeze problem. I never see codes use long time int as parameter of osDealy(), you can use this function but just delay a few ms, use timer if you want dealy more, I know you want make some stress on TouchGFX, but TouchGFX make right reaction. so keep heavy task lower pri and make TouchGFX engine higher pri may consider a good thought？ I'm not sure about this ,my opinoin may be incorrect, wish someone can help you.

[LBESO.1]

okay, thank you for this detailed answer.

[N. SANTINI]

Hi,

I can see in your .icf file that your using both external SDRAM (from frame buffers most probably) and external FLASH (for graphic assets I guess), moreover you are using a Cortex-M7 based MCU.

This kind of unexpected crash in this context is usually due to an incorrect MPU (Memory Protection Unit) configuration.

The ARM Cortex-M7 is performing some optimizations at runtime, including "speculative accesses" that can sometimes lead try and access memory addresses of memory that are not even physically connected which lead to an hardfault !...

The only way to prevent that is to use the MPU configuration to first disable all accesses to the full address range of external memories and then define an MPU region per connected memory.

Please see our dedicated video:

https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/STM32_MPU_tips.html

Arm documentation :

Arm Cortex-M7 Processor Technical Reference Manual

Best regards,

Nicolas

[LBESO.1]

Hello,

Thanks you for your answer.

I checked the MPU configuration on STM32CubeMX, and it's activated for 5 regions with :

• Background region priviledged accesses only + MPU privileged default
• MPU TEX field level 0,
• All acces permitted
• And others parameters disable.

The symptoms mentioned in the video for the speculative accesses read lock are different than mines. Here only the Touchgfx Task freezed, the main loop with other task is still running and i can still use the debugger.

I don't know if MPU is the real issue here...

Best regards,

[LBESO.1 · Accepted solution]

Hi,

I just worked again on this issue, so here is an update and a summary about my problem.

-> The problem :

I'm working on a STM32H747-DISCO with the graphic library TouchGFX. I'm only using the M7 core under FreeRTOS. I added an other task called "CPU_Burner" to stress the CPU with some calculation to see how the TouchGFX's task respond and if the lagging effect is acceptable at some degrees. Of course the CPU_Burner task got an higher priority than the TouchGFX one or it won't get impacted.

When I flash the card and set up my CPU burner at 30% of the total load for example, after swiching between the two screens 1, 2 or 3 times, the TouchGFX GUI task freezed. And it's impossible to get it run again. The other task got no problem and is still runing, only TouchGFX and the screen remains fixed.

-> What I have done so far :

• I debugged the program to see where TouchGFX is stucked and it seems that it's in the file "OSWrappers.cpp", in the function "void OSWrappers::signalVSync()". If I understood correctly, the message queue to tell TouchGFX that the VSYNC buffer is ready to render is full.
• I added SystemView to monitor the application and i got the same result, TouchGFX stucked in signalVsync.
• I tried different screens setup and others projects and it allways endup freezing.
• For the MCU hint I disabled it and it didn't fixed anything. I will set up the precise address range for each external memory next week.

Some people managed to solve a similar issue with the MCU reconfiguration, in

this ST forum :

https://community.st.com/s/question/0D53W00000e067WSAQ/ui-stuck-in-takeframebuffersemaphore

-> The only solution that I Found :

• On that ST forum someone had a problem close to mine and apparently related to the DMA/DMA2D. He found a solution for his problem, adding some code in TouchGFXHAL.cpp to this function :

void HAL_DSI_TearingEffectCallback(DSI_HandleTypeDef* hdsi)

" if (!refreshRequested)

          HAL::getInstance()->allowDMATransfers(); "

• I did the same and now everything seems fine but I didn't really understood why. The problem seems related to a framebuffer lock but I can't manage to access it and monitor the lock and unlock.

I made a simplier project with System View with with the same issue. You can download it and try my project to see the freeze by yourself.

Thanks again to all the people trying to solve this ! :)