STM32H7S / H7RS: XSPI Deadlock During NOEKEON BLOCK Encrypted PSRAM Access

[Huell]

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:

1. 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.
   
   
2. 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.
   
   
3. 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
   
   
4. 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.
   
   
5. 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:

1. Disabling MCE2 or switching to NOEKEON-FAST-BLOCK mode significantly reduces the AXI bus transaction overhead, which prevents it from entering into deadlocked state.
   
   
2. 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 

[Fatih_Yildirim]

I have observed the same problem, it wouldn't surprise me if we have just found yet another erratum in H7RS family, we need official confirmation from the ST.

 

[Huell]

 

Regarding Errata 2.4.2: It appears this does not apply to our case, as we are using the XSPIs in Swapped mode.

To clarify for anyone unfamiliar, according to the Reference Manual, the XSPIM supports three configurations Direct, Swapped and Multiplexed. Errata 2.4.2 explicitly targets Multiplexed mode, where both XSPI1 and XSPI2 share the same bus.

You have helped us previously with the GFXMMU Errata, so I’m mentioning you in case you can provide any insights or advice regarding our current situation?

@lobna @mƎALLEm @AME MCU SM 

 

[lobna]

dear @Huell 

Could you please share a minimal project that reproduces the issue?

BR

Lobna

 

[Huell]

 

Dear @lobna, thank you very much for your quick response

 

We will prepare a minimal reproducible project as you requested. However, due to confidentiality constraints within our company, we are unable to share our current project directly. We will need to implement a clean, isolated project that reproduces the issue, which will take some time.

 

In the meantime, we have a couple of questions we would like to ask:

 

1. A complete core freeze — with no debugger connectivity and no HardFault or any other fault triggered — feels like a very unusual failure mode for a software bug. Can we say that a complete core freeze is characteristic of a hardware-level issue, potentially an erratum?

2. Are there any unannounced or undocumented erratum known to ST that are related to the issue we are experiencing?

 

[lobna]

Dear @Huell 

At this stage, our best understanding is that the CM7 freeze is caused by a pending or incomplete transaction on the AXI bus, which leads the core to a lockup state.
However, we cannot yet conclude that this is a hardware bug. Further investigation and correlation with the detailed bus and peripheral behavior are required. Once this analysis is completed, we will be in a position to determine whether the root cause is hardware‑related (e.g. an erratum) or due to a specific configuration / usage pattern.

 I am currently waiting for your project to start my investigation.
As soon as I receive it, I will begin the analysis and work on identifying the root cause of the issue.

Best regards

[lobna]

Dear @Huell 

Have you deployed the errata 2.2.15 I"/O compensation could alter duty-cycle of high-frequency output signal" 

Thanks

Lobna

 

[Huell]

Dear @lobna ,

Thank you for pointing out Errata 2.2.15. We did not have the I/O compensation workaround implemented previously, but we have now implemented it. Unfortunately, the XSPI deadlock still persists exactly as before.

In parallel, we are still working on our minimal reproducible project. We have not been able to reproduce the deadlock in this minimal environment yet, but we are currently investigating the differences between the two codebases to find the exact missing variable.

However, during this process, we did notice a critical behavior related to the MPU configuration:

In our main project, the PSRAM is configured as Shareable: TEX=1, C=1, B=1, XN=1, S=1. Once we flip the Shareable bit to 0 (Non-Shareable), any access to PSRAM triggers a deadlock, if the MCE is turned on.
(I can easily reproduce and share this version, if you would like)

We noticed that in ST's official examples (such as Template_XIP), the PSRAM address range is configured as Non-Shareable (S=0). Based on our testing, we suspect that once the MCE is enabled, the MPU region must be explicitly configured as Shareable to prevent these deadlocks.

Could you confirm if S=1 is a strict hardware requirement when the MCE is enabled for PSRAM in memory mapped mode?

Thank you again for your support.

[lobna]

Dear@Huell

In the meantime, while the project is being prepared, could you please reduce the CPU frequency while keeping the same prescaler values, and let us know whether the hang still occurs? In addition, could you kindly provide the MCE configuration, as well as the configurations for XSPI1 and XSPI2, and share the state of the relevant registers after these configurations have been applied?

Best regards,

Lobna

[Huell]

Hi @lobna,

Yes, we have already tried reducing the CPU frequency while keeping the same prescaler values, but the issue still occurs as before. We also reduced both the CPU speed and the XSPI speeds, but so far this has not helped.

We can share the initialization code for XSPI1, XSPI2, and MCE2, as well as the relevant clock configuration and MPU configuration details.

The current configuration is as follows:

• CPU frequency: 600 MHz
• XSPI1 and XSPI2 frequency: 150 MHz, sourced from PLL2S
• MCE configuration: Only MCE2 is enabled in BLOCK CIPHER mode (In our first message, we mentioned that MCE1 was also enabled, but that was incorrect.)
• MPU configuration:
  • Region 0 (Background region): TEX=0, C=1, B=1, XN=1, S=1
  • Region 1 (External flash): TEX=1, C=1, B=1, XN=0, S=0
  • Region 2 (DMA RAM): TEX=1, C=0, B=0, XN=1, S=0
  • Region 3 (External PSRAM): TEX=1, C=1, B=1, XN=1, S=1
  • Region 4 (GFXMMU): TEX=0, C=0, B=0, XN=1, S=0

The relevant initialization code for XSPI1, XSPI2, XSPIM, and MCE2 is provided in the xspi-mce-config.c file. We have also included the register dumps for each peripheral after configuration.

Also, I should note again that changing from BLOCK CIPHER to FAST BLOCK CIPHER resolved the hanging issue. In addition, configuring the external PSRAM as non-shareable in the MPU causes a hanging issue on any access to the PSRAM.