Skip to main content
YDovg.1
YDovg.1
Associate II
November 3, 2021
Solved

STM32F4 core freeze while using TouchGFX

  • November 3, 2021
  • 9 replies
  • 1965 views

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?

This topic has been closed for replies.
Best answer by YDovg.1

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.

9 replies

MM..1
MM..1
Super User
November 3, 2021

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

YDovg.1
YDovg.1Author
Associate II
November 3, 2021

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
MM..1
Super User
November 3, 2021

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
YDovg.1Author
Associate II
November 3, 2021

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
MM..1
Super User
November 3, 2021

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

TDK
TDK
November 3, 2021

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.

"If you feel a post has answered your question, please click ""Accept as Solution""."
YDovg.1
YDovg.1AuthorBest answer
Associate II
November 3, 2021

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.

Terms & ConditionsAccessibility statement