TouchGFX Crash with multiple text boxes

[justin11]

Hi,

I have a custom board project which I have been running for over a year and im looking to add some features to the layout. The screen is a 240x320 layout and the MCU is a STM32H757. I am running touch GFX 4.20 and it will be difficult for me to upgrade from this due to the ties within the cubide and code base.

Im looking to add a page with multiple test boxes,as i need to update sensor readings to the screen. Originally i built this in custom containers as i would normally, but it kept crashing on creating on the new page. So i have worked back making the page more and more simple untill i found a threashold of it occuring when i have 38 default text boxes on the screen (see pic), the text boxes have no buffers allocated to them and this is on a fresh screen so no functions or code running.

if i lower the number of text boxes to 34 its fine.

is this a limitation of 4.20 ?

I've tried increasing the canvas buffer and rtos heap and task memory but nothing resolves this crash (HardFault exception), i've attached the memory address in the diassembler.

[ferro]

Gfx allocates memory neccessary for its operation automatically at compilee time so there should not be a problem.Very difficult to tell what is going on. 10k does not seem much RAM. How much RAM you've got ?

Maybe try to enable freeRTOS config option configUSE_MALLOC_FAILED_HOOK and see if your program get to call error handler call.

[ferro]

When you link you app what does console say about ROM/RAM usage

[justin11 · Accepted solution]

Im running an STM32H757 so i should have pleanty of RAM

I think i have managed to resolve this. I changed the following task buffer size. this was originally 1024. no changing it to 2048 i've not seen the crashes.

// frertos.c

uint32_t guiBuffer[2048]; // Increase buffer size for gui task

// Update thread definition for gui

osThreadStaticDef(gui, Gui_Task, osPriorityNormal, 0, 2048, guiBuffer, &guiControlBlock);

[ferro]

Interesting that is happend with this specific screen - cannot see obvious reason for that as memory for screen objects is(should be) already alocated elsewhere, not on thread stack. Good to know.

There are some config options for freeRTOS to see how much/maximum of stack usage

configRECORD_STACK_HIGH_ADDRESS

configCHECK_FOR_STACK_OVERFLOW

uxTaskGetStackHighWaterMark

[GaetanGodart]

Hello @justin11 ,

As Ferro said, TouchGFX manages the TouchGFX heap size based on the widgets you add.

Have you encountered the issue again after increasing the FreeRTOS task size?

Regards,

[justin11]

Hi,

Since the changes i made i've not seen the problem every again. the changes I mentioned seemed to have sorted the issue. So it doesn't seem that TouchGFX manages this ?

[ferro]

Maybe your GUI thread stack is being overwriten/corrupted by some part of application (Overlap of linker regions) and with increasing its size that problem is not seens any more.

[justin11]

possibly, but i also did a test where i removed many existing screens and containers (effectivly lowering the overall memory footprint) and the problem still occured.

[GaetanGodart]

Hello @justin11 ,

I am glad to hear that it solved your issue.

TouchGFX allocates heap for every widget, the textArea widget is no exception.
I was just unsure that this was a long term solution but it seems to be.

Regards,

[ferro]

@justin11 

>> "i also did a test where i removed many existing screens and containers (effectivly lowering the overall memory footprint)"

This is the crutial point - Heap of Gfx is sizeof biggest screen/view. By removing screens you are surely lowering ROM footprint, but not necessarily RAM footprint.

To see Gfx Heap size, check sizeof 'MaxViewType' e.g. in FrontendHeap.cpp:

char (*oi)[sizeof (MaxViewType)] = 1;

I hope you find time to determine what was causing the crash. Are you able to run a simulation if it happens there ?