Hi everyone,
We are encountering a XSPI Deadlock on our STM32H7S7-Discovery board (STM32H7S78-DK).
To provide some context, our system is configured as follows:
External FLASH: Connected to XSPI1. Swapped through XSPIM to port 2 and operates in memory mapped mode. MCE1 is activated across the entire address range using the AES-STREAM Cipher.
External PSRAM: Connected to XSPI2. Swapped through XSPIM to port 1 and operates in memory mapped mode. MCE2 is activated across the entire address range using the NOEKEON-BLOCK Cipher.
The issue occurs when running an LZO decompression algorithm. The algorithm reads compressed data from the PSRAM and writes the decompressed output back to the PSRAM, while the code is being executed on External FLASH.
At some point during decompression, the core completely freezes, no HardFault or BusFault is triggered, and the debugger permanently loses its connection to the core.
We have tried multiple approaches to resolve, including the official errata workarounds. Yet, none of them helped so far. Here is what we have tried:
- Errata : 2.4.2 Deadlock can occur under certain conditions:
We implemented the recommended workarounds for the XSPI deadlock condition, including all combinations, without success.
- Errata : 2.4.5 XSPI deadlock or RAM content corrupted on CSBOUND split during prefetch, when DQS is disabled:
Since DQS is physically connected and enabled in our system, we assume this is not the root cause.
- The MPU is configured for External FLASH and PSRAM with the following attributes:
External Flash: TEX=1, C=1, B=1, XN=0, S=0
PSRAM: TEX=1, C=1, B=1, XN=1, S=1
- Errata : 2.2.17 System hang on GFXMMU memory access when not in use:
Although this erratum produces very similar symptoms (which we have experienced previously and shared a post about it STM32H7RS | H7S3L8 Core Freeze XSPI + DCACHE in Bootloader ), its workaround is already applied and active in our system.
- Disabled I-Cache & D-Cache during the LZO decompression. The issue still persisted.
After further investigation, we resolved the issue by modifying the MCE2 configuration for the PSRAM.
Specifically, turning off MCE2 or switching it to the NOEKEON-FAST-BLOCK cipher eliminates the core freeze.
The issue only occurs when the MCE2 - NOEKEON-BLOCK Cipher mode is actively used.
At this point, we suspect there are two possible explanations for this behavior:
- Disabling MCE2 or switching to NOEKEON-FAST-BLOCK mode significantly reduces the AXI bus transaction overhead, which prevents it from entering into deadlocked state.
- Alternatively, there might be an underlying issue tied to the NOEKEON-BLOCK mode.
We appreciate any advices or insights regarding this behaviour. Thank you in advance.
@Fatih_Yildirim @macosali @SSone.1 @yildirimalper
