cancel
Showing results for 
Search instead for 
Did you mean: 

Hang using DynamicGraph

Mark999
Associate

Hey all, experienced developer but new to ST ecosystem.

I have a STM32H7B3I-EVAL board and made my first project using TouchGFX Designer 4.21.4.  I put on a Dynamic Graph and a few Text Areas with wildcards, and coded up some random data to try it out.  Sporadically, I'd see the UI hang.  I was able to catch it with a debugger and found it deadlocked with this stacktrace:

Thread #2 [TouchGFXTask] 604023232 (RUNNING) (Suspended : Breakpoint)        

touchgfx::OSWrappers::takeFrameBufferSemaphore() at OSWrappers.cpp:72 0x800186a        

touchgfx::HAL::lockFrameBuffer() at 0x8010c06        

touchgfx::HAL::lockFrameBufferForRenderingMethod() at 0x8010c3a        

touchgfx::Canvas::render() at 0x8024c82        

touchgfx::GraphElementLine::drawCanvasWidget(touchgfx::Rect const&) const at 0x8012116        

touchgfx::CanvasWidget::draw(touchgfx::Rect const&) const at 0x8010f44        

touchgfx::Screen::JSMOC() at 0x8017540        

touchgfx::Screen::startSMOC() at 0x8017596        

touchgfx::Screen::draw() at 0x80175c4        

touchgfx::Application::draw() at 0x8015ab4        

touchgfx::Application::drawCachedAreas() at 0x8016948        

touchgfx::HAL::tick() at 0x8010266        

TouchGFXHAL::taskEntry() at TouchGFXHAL.cpp:68 0x8001682        

touchgfx_taskEntry() at TouchGFXConfiguration.cpp:72 0x8001f2e        

TouchGFX_Task() at app_touchgfx.c:89 0x8001366

I have no custom code that deals with the framebuffer; just stock widgets as mentioned.  I attempted to find who was holding the semaphore, and found it was *maybe* _ZN8touchgfx13DMA_Interface10addToQueueERKNS_6BlitOpE, but can't help any further because that's in closed code with no debug info.

The hang is very irregular.  Sometimes it would happen after nearly every reboot within 10 seconds.  Sometimes I've gone for weeks with nothing.  Once it took a whole weekend to hit.  The following is speculation since it happens so rarely:  It might happen more if the DynamicGraph rescales and does a slow invalidate of the entire graph.  Having an opaque Box behind the graph seemed to make it happen less often.  I have turned off DMA2D and have not seen it hang lately but don't have enough run time to confidently say it's related.

I've since moved on in this project and sorry that I don't have any minimal reproducible code to share.  I thought I'd throw this stack trace out there to see if anybody else has seen it.  I'm also investigating a custom OSWrappers workaround to detect and recover the hung UI task without affecting other FreeRTOS tasks.

4 REPLIES 4
Panchev68
Senior

Try increasing the TouchGFX task stack size. I had a similar problem when it was 1024 bytes. I am currently at 2048 and everything is ok.
Regards, Bobby

Thanks for the reply.  I am at the project defaults for this board and it looks like the task has 4096 words of stack; I can't imagine why that's not enough.

const osThreadAttr_t TouchGFXTask_attributes = {
  .name = "TouchGFXTask",
  .stack_size = 4096 * 4,
  .priority = (osPriority_t) osPriorityNormal,
};

 

It's more than enough. Apparently it's not that

Roger SHIVELY
ST Employee

Hello @Mark999 ,

There has been a case created to resolve this question and we will be reaching out to you directly.

Regards,
Roger