STM32H7S7L8H6H XSPI instability

[Ondrej Meca]

Issue
Higher ambient temperatures cause communication malfunctions with XSPI memories.

Details
Our design is heavily adopted from STM32H7S78-DK which also has the same issue described below.

The application uses memory-mapped mode for both Flash and RAM as the main operational units. These memories are configured in the bootloader and everything generated using CubeMX. According to the datasheets, all three components (CPU, Flash, and RAM) are specified to operate reliably under the given conditions, and they do function correctly under normal temperatures.
The problem arises when the ambient temperature increases from 25°C to 60°C. These temperatures are within the acceptable operating range for all components, as stated in their specifications. Upon reaching higher temperatures, the memories start to exhibit failures. However, further investigation revealed that the issue is not with the memories themselves. When the memories alone are heated, they continue to operate reliably, even at elevated temperatures.
The issue was traced to the CPU. When the CPU is heated, the failures begin around 55°C. At this point, the CPU starts to malfunction in its communication with the memories. This leads to the CPU entering an undefined state, with fault reports showing inconsistent and varying results.
Lowering the temperature restores normal operation.

Investigations

• All supply voltages (VCAP, 3.3V, and 1.8V) remain stable during the issue.
• Heating only the memories while keeping the CPU cooled does not cause the problem; the memories operate reliably under these conditions.
• When heating only the CPU, the problem appears immediately, confirming the issue originates from the CPU.
• Same issue happens on STM32H7S78-DK

Specifications

CPU - STM32H7S7L8H6H
XSPI1 - APS256XXN-OBR-BG
XSPI2 - MX25UW6345GXDI00

STM32CubeMX ver 6.13.0
STM32CubeMX package STM32H7RS v 1.1.0

VCC 3.3V
XSPI1 & XSPI2 1.8V

CPUCPLK 600MHz
HCLK 300MHz
XSPI1 & XSPI2 176MHz with no prescaler

ZIP

schematics, layouts, scatter file, mxcube configs & clocks, option bytes

[STOne-32]

Dear @Ondrej Meca ,

First, Thank you very much for the detailed reporting case which seems very clear .

I give you one hint if you can check it and change your code accordingly :

• Disable the GPIOs I/O compensation cell or
• Enable it the first time in automatic mode , read back the values of the PMOS and NMOS calibration data , then disable the automatic mode and activate the software mode while writing the values already read at the start .

One hypothesis is that when automatic mode is activated and for each CSI clock cycle , the code may change in run time when temperature is reaching a certain point and if this happens during a transmission or reception the data be corrupt or wrongly decoded by the CPU / System . Please let me know if you need further assistance for your code change .

Hope it helps ,

STOne-32

[Ondrej Meca]

Hi STOne-32,

Thank you for your quick response. After investigating your suggestion, I can confirm that the issue was related to automatic compensation.

I programmed the calculated compensation value from SBS_CCVALR to SBS_CCSWVALR and adjusted XSPI1_COMP_CODESEL and XSPI2_COMP_CODESEL in SBS_CCCSR. After making these changes, the issue was resolved immediately.

However, I have a question: is there any application note that describes this behavior? Should I repeat these steps after every restart, especially if the CPU restarts at higher temperatures (which might result in different compensation values being written at higher temperatures)?

Is this the intended behavior, or did I overlook something?

[STOne-32 · Accepted solution]

Dear @Ondrej Meca ,

Thank you got confirming it . We will release soon a Knowledge Article on the Topic, on How to use this feature in real time application for such High end MCU running from XSPI memories . 

Ciao,

STOne-32