‎2020-04-20 04:29 AM
Hello,
I have a project with custom stm32f769 oard and TouchGFX as GUI. I've done a lot of testing on simpler GUI (showing background and one button).
I've also prepared additional task that will do communication with other boards.
Everything seems to be working normal. I've chosen same Normal prioritiy also for this additional task.
Now I have imported more complex GUI i(approx. 26MB in external flash) nto the project by using TouchGFX Designer (opened existing, imported new one and generated code & recbuilt whole project) and now I get Hard Fault error.
Although not experienced debugger, I've single stepped problematic part and it seems that the first non-GUI task is started and then when it switches to another task, hardfault happens. By using HardFault analyzer in my CubeIDE, PC points to this line in code :
const uint8_t* GeneratedFont::getPixelData(const GlyphNode* glyph) const
{
const uint8_t* const* table = (const uint8_t* const*)glyphData;
return &(table[glyph->unicode / 2048][glyph->dataOffset]);
}
PC in HArdFault points to last line - but it seems weird to me.
But 'd like to learn, how to debug TouchGFX part of the application.
Where is entry point, main loop? Where can I stop safely ?
On the other side, I have a question, how to properly debug, check and supervise the ecxecution of TouchGFX also from other tasks, from FreeRTOS supervising features ?
It somehow seems to be not so easy to debug after startup (at least for me).
Thanks in advance,
regards,
B.
Update: went into disassembly on PC's address and it makes sense :
0800e0d6: ldr r3, [r3, #0]
and Registers view shows value of R3 to be
r3 0x91b8d822 (Hex)
that is not a multiple of 4....
Update2: Breakpoint in that position is reached.
For information, glyph->DataOffset has value of 12522., glyph->unicode 76...
Hmm, it seems that it doesn't hard fault at these values, but it gets into hardfault
next time... I cannot retriev the actual values...
Solved! Go to Solution.
‎2020-04-21 06:54 AM
We do font/language initialization at an early stage where as images are simply referenced as pointers to memory-mapped flash in most cases. Could you double check that you're doing flash configuration as early as possible?
/Martin
‎2020-04-21 07:28 AM
Short question: what is the alignment of the GlyphNode that is incoming pointer in the function ? It seems that reading the Offset is in assembly done by LDR, but the address of the GlyphNode seems to be not aligned (only even aligned, not by 4)-...
Regarding Flash init: it's done before RTOS is started... So I guess it's ok...
‎2020-04-21 07:39 AM
Thanks... I do Flash intialization before RTOS kernel is started... Do you have something earlier to run ?
Short Question: how is GlyphNode aligned when it comes into the function ? I get hardfaults when glyph pointer is not aligned by 4 but only by 2
(and dataOffset is 32 bit and reading it causes problems) - at least how I understand this...
‎2020-04-21 08:13 AM
Where can I find those font initialization routines ?
‎2020-04-21 08:35 AM
hmm, did go through the sequence... "8mm" is first text to be displayed... "8" comes with Unicod 56 and glyph address is aligned, but next "m" comes into with unicode 109 and glph address is only even aligned and reading dataOffset (which is 32bits) causes problems... We're using Verdana.ttf - is this problem maybe related to font we are using or code that extracts from the Font...
And what is more weird, why this works on Discovery board ----
‎2020-04-21 11:36 AM
Hi, have tried some things and also to put fonts into internal Flash (this is the second difference I found in comparison with the similar project running on DISCO board). And it works...
What is the difference between accessing fonts and images in external flash? Maybe there is a problem with memory mapped mode of external flash...
I have the project working, but am interested in the final answer...
‎2020-04-21 12:40 PM
It boils down to the fact that internal flash is always initialized when you need it, but external isn't. You must initialize external flash before touchgfx is initialized, not just before the scheduler is started.
/Martin
‎2020-04-21 12:55 PM
yeap, you're totally right... Now I spotted that there is an early call to MX_TouchGFX_Init(); Will check but it seems logical... Default order should be changed...
Thanks for help...
‎2020-04-21 12:58 PM
And actually, this is probably a problem in CubeMX project generation =) So, glad we had this talk. I'll verify.
/Martin
‎2020-04-21 03:41 PM
I've changed the order (put Flash init before MX_TouchGFX_Init(); ) but didn't help. Maybe did something wrong... Will check later.
For now, I leave fonts in internal Flash and check this later...
Thanks for help---