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.

[Huell]

Hi @lobna,

Did you have a chance to check our source code and register dumps?

 

BR

[Gasper Korinsek]

Hi,

We see what looks like the same deadlock, with MCE1 (AES) instead of MCE2. On our side it's deterministic: with the PSRAM region cacheable, the very first access through a block-cipher region freezes the core, and SWD can no longer read the core ID. In case it helps the investigation, here is a minimal setup that triggers it on a stock DK.

Setup

• STM32H7S78-DK (MB1736), STM32H7S7L8, STM32CubeH7RS 1.3.0, HAL 1.2.1, GCC.
• XSPIM in direct mode (no swap, no multiplexing): XSPI1 → port 1 → APS256XX PSRAM, XSPI2 → port 2 → MX66UW1G45G NOR.
• Clocks: SYSCLK 600 MHz, HCLK 300 MHz, XSPI1 kernel clock 200 MHz (PLL2S), prescaler 0. HSLV on both XSPI rails, I/O compensation cells off.
• The code runs from NOR (XIP). The PSRAM is used only as data at 0x91000000–0x91FFFFFF.
• XSPI1 register state before the MCE is enabled: CR 0x30000101, DCR1 0x06180400 (APMEM 16-bit, 32 MB, CSHT 5), DCR2 0x00000000 (no wrap), DCR3 0x000A0000 (CSBOUND 1 KB), DCR4 0x0000018C (REFRESH ≈ 2 µs), CCR 0x2D003C04 (16-line DTR, DQSE = 1), TCR 0x0000000D, IR 0x00000020, WCCR 0x2D003C04 (DQSE = 1), WTCR 0x00000006, WIR 0x000000A0.
• MPU for the PSRAM data region: Normal, TEX = 1, C = 1, B = 1, XN = 1, S = 0. I- and D-cache on.

MCE setup (done before any write to the region):

 

hmce1.Instance = MCE1;
HAL_MCE_Init(&hmce1);
ctx.Nonce[0] = 0xA5A5A5A5; ctx.Nonce[1] = 0xC3C3C3C3; ctx.Version = 1; ctx.pKey = key;
HAL_MCE_ConfigAESContext(&hmce1, &ctx, MCE_CONTEXT1);
HAL_MCE_EnableAESContext(&hmce1, MCE_CONTEXT1);
cfg.Mode = MCE_FASTBLOCK_CIPHER;           /* same result with MCE_BLOCK_CIPHER */
cfg.StartAddress = 0x91000000; cfg.EndAddress = 0x91FFFFFF;
cfg.AccessMode = MCE_REGION_READWRITE; cfg.PrivilegedAccess = MCE_REGION_NPRIV;
HAL_MCE_ConfigRegion(&hmce1, MCE_REGION2, &cfg);
HAL_MCE_SetRegionAESContext(&hmce1, MCE_CONTEXT1, MCE_REGION2);
HAL_MCE_LockGlobalConfig(&hmce1);
/* Afterwards: MCE_REGCR2 = 0x0000C201 */

Then a plain word write/read pattern over 4 MB of the region, using cached accesses and SCB_CleanInvalidateDCache().

Results

Configuration	Result
no MCE, S = 0	works
MCE1 stream (context key), S = 0	works: pattern check, a JS interpreter (Duktape) with its heap in the region, and HPDMA reads at the same throughput as without MCE
MCE1 fast block, context key, S = 0	freezes on the first access; the core is unreachable over SWD
MCE1 fast block, master keys (HAL_MCE_ConfigNoekeon + MKLOCK, CTXID = 0), S = 0	same freeze
MCE1 fast block, context key, S = 1	the word pattern check passes, then freezes once the JS interpreter starts using the heap
no MCE, S = 1	works, but 6–10× slower: with S = 1 the region is effectively not cached by the M7

Already ruled out or applied

• 2.2.17 (GFXMMU): MPU no-access region at 0x25000000/16 MB.
• 2.4.2: not applicable (direct mode, no multiplexing).
• 2.4.5: not applicable (DQS on for reads and writes).
• 2.2.15: compensation cells off; automatic compensation caused separate data errors for us earlier.

Observations that might help:

• With the cache on, block mode never survives a single access.
• Uncached, it survives simple 32-bit accesses but not a mixed workload, which has byte and halfword writes, so sub-block read-modify-writes, mixed with reads.
• That fits the other report here, where LZO decompression triggers it.
• It also fits RM0477 §39.4.7, which says a write is stalled while both cipher cores serve reads, which might be where it locks up. That last point is only our guess.

We can share the complete project (a single Makefile, flashes with STM32CubeProgrammer) if that helps.

[Huell]

​Hi ​@Gasper Korinsek,

Thank you for sharing these detailed results. It seems that we are observing the same issue.

As an important update to our earlier findings, we have also encountered freezes with FAST BLOCK cipher mode. Therefore, switching from BLOCK to FAST BLOCK cannot be considered a reliable solution.

Until ST confirms the root cause and provides an official workaround or erratum, I think it is best to use the PSRAM with MCE disabled.

Also, could you share the complete project with us as well? Having a deterministic reproduction case could be very useful and might help us narrow down the issue.