STM32F7508 MCU freeze

[VVasi.1]

Hello all,

I have an STM32F7508-Discovery board (STM32F750N8H6 MCU) with a custom UI application on top, using LTDC and DMA2D in interrupt mode, and continuously filling the full display with red/blue. The Stm32CubeF7 v1.16.0 is used as an SDK.

With this application, I have the following behavior:

• With IAR toolchain, no issues observed, application works smoothly with good performances
• With GCC toolchain (Stm32CubeIde 1.40.0), the application freezes at random points during execution

The worst part is that this is not an application freeze, but an MCU freeze, because:

• The debugger loses connectivity, trying to halt the CPU doesn't work during the freeze, neither does attaching the debugger without a system reset
• The SysTickHandler is no longer executed, meaning the IRQs stop firing
• The RTOS idle task is not entered anymore
• The WDT is the only thing that can reboot the MCU, with the WDT disabled, there's no other solution other than pressing the RST button
• After the WDT reset, I see all the CPU registers being reset, which is not normal and provides no debug purpose

Since I can't debug as the debugger stops during the freeze, I suspect an issue at hw level (AHB bus deadlock, power issue).

Did anyone encountered similar freezes on this MCU?

How can I get some traces out to help me with the investigation (ETM traces, SystemView traces)?

[Tesla DeLorean]

>>How can I get some traces out to help me with the investigation (ETM traces, SystemView traces)?

If the debug interface is powering down, then thats not going to work.

I don't think the STM32F7508-DK provides access to the trace pins.

The SWO/SWV should work, and the UART to the VCP should be viable, at least until it locks.

Back off the flash wait-states, perhaps try turning off the ART cache/prefetch.

If dropping the debugger, most likely hitting a WFI and powering down debug. For debug builds avoid WFI/SLEEP modes.

Have Hard Fault and Error Handlers output actionable data. Use diagnostic/telemetry output to understand flow and paths to failure.

[VVasi.1]

Thanks for your answer.

There is no WFI/SLEEP in my code, so that is not an issue. Also, I have loggers through the fault handlers and they also do not hit.

I found out today that disabling the data cache globally fixes the issue, but since I cannot use such a workaround as it impacts performance, the next thing was to create an MPU region as stongly ordered (cache disabled) which contains both the source and the destination buffers of the DMA2D, still this is not enough.

I suspect an AHB bus freeze (both CPU and DMA2D are AHB bus masters) correlated with a cache issue, but I can't put my finger on it yet, so any suggestions in this direction is greatly appreciated.

[VVasi.1]

So, here is an update.

1. I created an MPU region for the display buffers (source and destination for the DMA2D transfers) and disabled the cache on it, hoping this will fix the issue. Unfortunately it did not.
2. Looking in the example, more precisely in (STM32Cube_FW_F7_V1.16.0\Projects\STM32F769I-Discovery\Demonstrations\STemWin\Core\Src\main.c) I noticed "extra" MPU regions compared with what I have. In my project, I have MPU regions for all memories (except TCM), configured as cacheable with write-through cache policy. However, this example has an extra MPU region for the complete QSPI address space(from 0x90000000, 256MB in size), where the cache is disabled. A higher priority MPU region then spans the 16MB of physical flash, with cache enabled, same as in my project

If I add this extra MPU region (for the 256MB of QSPI address space), the freeze is gone.

I do not understand why! From my point of view, this region is useless, as it is override with the 16MB MPU region, but then how can it fix the freeze?

Does STM has some explanation? If not about fixing the freeze, then about the presence of this MPU region in the SDK examples?

[Tesla DeLorean]

I know the H7 had some issues in the tail end of the QSPI space (as set in the peripherals 'flash size'), last 32-bytes as I recall.

Could be a speculative read or prefetch at the peripheral level.

Check the errata, talk to the local FAE supporting your account.

[VVasi.1]

You are right, I finally found an application note from STM where this is explained. See https://www.st.com/content/ccc/resource/technical/document/application_note/group0/25/ca/f9/b4/ae/fc/4e/1e/DM00287603/files/DM00287603.pdf/jcr:content/translations/en.DM00287603.pdf, Chapter 4.6 Special recommendations for Cortex-M7 (STM32F7/H7). Many thanks for your help, this issue is closed~

[waclawek.jan]

Not directly related to your particular problem, , but once talking about MPU, you may want to consider also the "CortexM7 data corruption when using data cache configured in write-through" ARM erratum (which made it even to ST errata).

JW