Crash in TouchGFX draw() function (waiting on framebuffer semaphore)

[Michael K]

I have a page with many textboxes in a swipe container, half of which have wildcards. Occasionally the TouchGFX task will freeze (other RTOS tasks continue as normal). Unfortunately I have not yet found a way to reproduce it, however the symptoms are similar each time.

The UI freezes. I click pause in STM32CubeIDE, I usually end up in a DMA Handler. I step through until the DMA handler completes, and then I land in a TouchGFX textarea draw function.

The stack trace is always something like this:

touchgfx::TextAreaWithOneWildcard::draw(touchgfx::Rect const&) const at 0x8057353
touchgfx::Screen::JSMOC() at 0x......
touchgfx::Screen::JSMOC() at 0x......
touchgfx::Screen::JSMOC() at 0x......
<a number of these JSMOC lines...>
touchgfx::Screen::JSMOC() at 0x......
touchgfx::Screen::startSMOC() at 
touchgfx::draw()
touchgfx::Application::draw()
touchgfx::Application::cacheDrawOperations()
touchgfx::HAL::tick()
touchgfx::HAL::backPorchExited() at HAL.hpp:541

The topmost function is always a TextArea, TextAreaWithOneWildcard, or TextAreaWithTwoWildcards draw() function.

Edit 2021-04-06: I was able to reproduce the issue where the draw function called was a member of Line.

Regardless of the exact object the draw function was part of, the program counter in the disassembly always stops at one of these two instructions:

08057353: add.w r1, r2, r3, lsl #1
08057357: ldrb.w r2, [r2, r3, lsl #1]

When I click step, the program counter doesn't step to the next one, however instead it continues the execution of the program.

Once, the stack trace said the topmost draw function is at address 0x8057356, but the add.w instruction is at 0x8057353 and the ldrb.w instruction was at 0x8057357.

Please see attached for a screenshot of the CubeIDE during one of these crashes. I am running a custom board, however it is based off of the STM32F769-DISCO application template (either v3.0.1 or v3.0.0).

Thanks for any assistance.

[Michael K]

Update: I can reproduce the issue by constantly sliding the swipe container. I guess it increases the draw rate, since the page only normally refreshes itself a few times per second. The crash occurs after around 2-3 minutes of sliding. Perhaps there's a race condition somewhere?

[Michael K]

Update 2: I seem to have found a way to stop the crash, however it is seemingly unrelated to any of my TouchGFX code. When running the TouchGFX task in isolation, the issue does not occur. I suspected a stack overflow issue so I increased the stack size of all my tasks, but that didn't solve the problem. More investigation to be done... but the root cause is probably unrelated to TouchGFX.

@Alexandre RENOUX​ , or @Martin KJELDSEN​ , perhaps you could share some information about what those library draw functions are actually doing around the lines of those addresses that would help me narrow down my issue? I'm using TouchGFX 1.16.1 and code optimizations are off. Perhaps a failed assertion?

[Martin KJELDSEN]

Hi Michael,

Let me get back to you tomorrow - It's getting a bit late here. I can share some information maybe help track down the problem.

/Martin

[Michael K]

Update 3: I thought that loading the texts from the QSPI may have had something to do with it, but moving the Text and Font flash sections to the internal flash yielded the same results. That said, I did get a hang in a Line Draw() method, so that rules out the Texts or Wildcards as being issues specifically. Here is a recent crash. I set the timeout from osWaitForever to 2000, so that I could catch the exact stack trace that was waiting on the framebuffer.

[Martin KJELDSEN]

Okay, the framebuffer semaphore is not available. Are you running a single framebuffer configuration? Which display interface are you using? You may not be triggering TouchGFX to release the semaphore.

/Martin

[Michael K]

Single framebuffer, "Custom" interface (in cubemx) with ChromArt. Built on top of the STM32F769-DISCO 3.0.0 template, though I have added other peripherals. I don't know if this information helps, but I replaced while(1) with giveFrameBufferSemaphore(); takeFrameBufferSemaphore(); in the status check but it remained frozen. I could see from instruction stepping it was looping somewhere in the drawGlyph function.

[Michael K]

Update 4: A newly added feature on another task causes this problem to happen again. In this case, changing the TouchGFX priority to be equal to the other tasks in my system seems to have stopped the problem.