cancel
Showing results for 
Search instead for 
Did you mean: 

Hard Fault when performing a screen transition

TDele.1
Associate III

Hello everyone,

I'm currently developing a project using Touchgfx on a custom board with a STM32F469II and a 1024x600 screen on RGB565 format. I'm also using both an external SDRAM and Flash and the DMA2D is activated.

Recently, I've been having an issue where a Hard Fault occurs when performing some screen transitions. The error always happens, as an example, when performing 2 up sliding transition followed by a left of right slide transition. It can also happens randomly when performing any screen transition (including "none" transition) at any time during the process. Disabling DMA2D does not fix the issue.

When entering the Hard Fault handler, the fault analyzer gives us the following flags:

0693W00000Ho0wwQAB.pngSo, by looking at the flags, I believe that this was a Bus Fault which transformed into a Hard Fault although it does not mention if the data access is precise or not. The address stored in BFAR seems to not have been updated and does not help to locate the fault's origin.

The SP register points to the address 0x2002ae48 which is within the scope of the stack of the TouchGFX stack which, along with all the other tasks I've set up, does not seem to have otherflown (lots of 0xA5A5A5A5 default values still present in all stacks). I can also add, by looking at the value of "pxCurrentTCB", that the Hard Fault seems to have occurred while the TouchGFX task was on.

The PC register is pointing to the address 0x26262030 which is outside the scope of the internal RAM which stops at 0x20050000.

Finally, the LR register points to a Flash address at 0x809bbf9. Going into the disassembly, we can see the following instructions around that address :

0693W00000Ho17uQAB.pngThe Hard Fault thus seems to be triggered by the function "touchgfx::Drawable::invalidate()" called before the screen transition. However, for me, the trail stops there since putting any breakpoint into the source/assembler code within the invalidate() function stops the process of the code and is thus never reached.

I've also tried to increase/decrease the stack available to the touchGFX task (as low as 1024 words and as high as 10240 words) but to no avail.

I'm very new to that kind of Hard Fault debugging so I would very much appreciate if somebody can help me solve this error.

Thanks in advance,

Tristan

1 ACCEPTED SOLUTION

Accepted Solutions
Michael K
Senior III

Good debugging effort so far.

Does the problem always occur on the same screen? Can you reproduce the issue on a clean, minimal project? If so, does it also occur with a similar minimal project on an ST dev board? Unfortunately the further away from known hardware, the harder it is to remotely answer without deeper knowledge of your project.

It's important to note that just because the hardfault occurred during the TouchGFX process, doesn't mean the source of the problem causing the hardfault was TouchGFX. I recommend isolating the TouchGFX task and gradually re-enabling other tasks until the issue begins presenting.

The only times I've had hard faults when changing screens specifically the issue was related to an improperly flashed QSPI holding the graphics assets. But it wasn't sporadic, like your issue seems to be.

Good luck.

View solution in original post

1 REPLY 1
Michael K
Senior III

Good debugging effort so far.

Does the problem always occur on the same screen? Can you reproduce the issue on a clean, minimal project? If so, does it also occur with a similar minimal project on an ST dev board? Unfortunately the further away from known hardware, the harder it is to remotely answer without deeper knowledge of your project.

It's important to note that just because the hardfault occurred during the TouchGFX process, doesn't mean the source of the problem causing the hardfault was TouchGFX. I recommend isolating the TouchGFX task and gradually re-enabling other tasks until the issue begins presenting.

The only times I've had hard faults when changing screens specifically the issue was related to an improperly flashed QSPI holding the graphics assets. But it wasn't sporadic, like your issue seems to be.

Good luck.