HardFault with TouchGFX ?

[bully]

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...

[Juan Delgado]

I have similiar Undefined behavior.

I was able to fix it but it was inexplicably damaged again.

Please read and see if you can fix your problem:

https://community.st.com/s/question/0D53W000004nXcYSAU/hard-fault

[Juan Delgado]

Undefined behavior. But I did app runs

1.- Open designer

2.- Config tab ==> checklist binary font

3.- Generate Code

4.- Close designer

5.- Open keil, compile and flash your app

6.- Your app will runs perfectly but without texts

7.- Close keil.

8.- Open designer

9.- Config tab ==> UNchecklist binary font

10.- Texts tab ==> Typographies tab ==> Write wildcard character. eg. 123456789. or 0x00-0xFF for all your fonts

11.- Generate code

12.- Close designer.

13.- Open keil, compile and flash your app

14.- Now my app runs perfectly with texts and all that I want

I don't know how this works but these steps work for me

[bully]

Thanks will try this one...

[Martin KJELDSEN]

I don't think this is the issue. Seems like the application is trying to reference some bogus memory address. Does that make sense that you're on the limit of your external flash?

[bully]

Hmm, interesting idea... Let me update info:

• I think the space is not a problem (have the same Flash as in 769 Discovery board - 64MB - the build analyzer shows 28MB)
• I guess this happens on the first or second call to this function (so basically at the start) - so maybe I can find the sequence, but would need to read some more docs about how text is displayed under TouchGFX
• I have this GUI running on 769 Discovery board ok, so I've imported TouchGFX part into my custom board with same MCU and same external Flash. Maybe something will need to be changed in addition to just import that GUI part ?
• if I check Binary fonts, regenerate and recompile GUI works ok, just without any texts...
• I've also unchecked Remap just to narrow down the problem...
• the only difference that we know off is that display on DISCO is DSI, and out is RGB888 - is this a problem ?

What do you think will be the easiest way to find out what is wrong. It seems that something obvious is not set up properly...

I've not designed the GUI part, so it's hard to know internals, but can learn if you can point me in the right direction...

Thanks in advance,

regards.

[Martin KJELDSEN]

out = ours? If by RGB888 you mean parallel RGB then yes, it's completely different in the way that pixels are transferred to the display.

I think we need to take a step back to figure out what's wrong. Are you able to get back to something that works?

Re: debugging, some IDES like IAR have a FreeRTOS plugin so you can monitor the status of tasks, semaphores and queues. You can't debug into the closed source, of course.

[bully]

ok, thanks... We're narrowing down the problem... eap, I meant ours...

I can debug, I use FreeRTOS plugin, it happens on the first draw.

But transfer to Display works (I have running GUI with images only currently, get hardfaults on first text), if included in project).

If I tick Binary fonts, GUI works without texts and Hardfaults...

But also have gone throught your guide for custom boards.. Display is working, I have working example of drawing pixels, lines and rectangles

(latter also via DMA2D). So Display transfer s working....

IIt seems that my problem is only in displaying texts...

Is there any general guidance what to change related to texts if your display transfer is parallel RGB888?

AFAIK. display framebuffer on Disco is also RGB888 format, just transfer is done via serial DSI connection...

If we can sort this out on some faster channel , I'd bee happy to share contact (Skype or something)...

Thanks and regards...

[Martin KJELDSEN]

Texts are agnostic to display interfaces. It's all just a matter of retrieving the data and rendering it to the framebuffer and then transferring the pixels.

Is your external flash properly initialized when you start rendering? One possibility is that you're trying to access the text-assets in flash before its initialized. Maybe you can break inside setupScreen() and check that you can actually read from flash in a memory window?

[bully]

Thanks, will try this. But I wonder why are images properly drawn... GUI works normally without texts...

I'll check the whole sequence that happens...

I'm also looking at the last line code... Even i the address is not right, the calculation should go through smootly... I somehow suspect that pointer arithmetic assumes 32bit access, but something is on not aligned address (but it seems that depends on real data - because hardfault happens after 2-3 accesses - and debugger always shows that the R3 at that moment has unaligned address)...

Have no clue what is calculated in that function? Can read more somewhere else ?