STM32F4 core freeze while using TouchGFX

[YDovg.1]

I have a STM32F446VCT6 MCU running TouchGFX project communicating SPI to a LCD. The images are located in the external QSPI which is in memory mapped mode.

Basically I have a few simple screens. Everything is running fine, except that after some random amount of seconds/minutes the MCU core freezes.

No hard fault or other things is called. The power consumption drops.

I was trying to catch something under debugging, but I cannot stop/pause the debugging. The MCU core is not responsive. Only asserting Reset pin helps.

I have disabled the communication - this does not help. So it must be something in TouchGFX itself that triggers this freeze.

Any ideas how to diagnose this issue?

[MM..1]

Locate whiles code with never exit and place into gpio led toggle with different pauses for diagnose where system stucks.

[YDovg.1]

I suspect that the fatal condition happens in the TouchGFX library, where I do not have sources of.

Secondly, this is definitely not a while loops. I have tried to setup an EXTI interrupt on the MCU pin and trigger it after the MCU is freezed - the interrupt is never triggered. The core is not responsive at all...

[MM..1]

Yes maybe, but place one line to hardfault handler and place on it breakpoint is good point to start.

Other ways will not work on hardfaults, exti or pause debuged process ...

[YDovg.1]

Yes, tried that. Hard Fault (or any other like Bus failure) interrupt not triggered....

Impossible to pause debug process since the core is not responsive - debugger is disconnected after I try to pause the debug process.

[YDovg.1]

I suspect the same behaviour like in this thread https://community.st.com/s/question/0D50X0000BxzTxzSQE/stm32f7-qspi-quadspi-sporadic-failure-with-memorymapped-flash-memory-disabling-timeout-does-not-help

Not sure if that applies to STM32F4

[MM..1]

Then this seems as hardware fail or clock PLL stop fail. Check or swith to HSI

[MM..1]

When you mean this then place test light gpio led before QSPI read and off it after...

[TDK]

I agree that it sounds like a hardware issue. I would monitor power rail and the NRST pin, see if it's generating an internal reset. Otherwise, if it has power and NRST is high, it's likely running code somewhere.

The linked thread is specific to the M7 core, which has a much more complicated pipeline. The M4 is quite different and simpler.

[YDovg.1 · Accepted solution]

Hmmmm.....

I've just disabled TCEN bit in QSPI for memory mapped mode and it seems like it solved the issue. At least the setup is running for 10 minutes without problems while it crashed in 10-20 seconds before.

Will test more tomorrow and conclude.​

UPD: Tested for a few hours and it work without problems. It means that disabling the Timeout Counter for QSPI solves the issue.

The only thing is unclear now is why ST does not include this into STM32F4 errata as they do for STM32F7.

Issue herby closed.