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]

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

[taste]

@STOne-32  since this topic is over 8 month old is there already a clear article in the knowledgebase who to handle this? We wan in the exact same issue just running a memory test through XSPI and the proposal seems to work. However clear instructions from the manufacturer are always preferred in these cases.

[STOne-32]

Dear @taste ,

Thank you for the follow-up, the Article is under analysis now and will be published soon by September as we wanted to carry more testings and have full corners cases to provide solid workaround.

Can you please let us know your exact XSPI Frequency selected ?  and if running with 200MHz , can you let us know the exact code your found (X,Y) for ANSCR = X,  APSCR = Y  ?

Thanks for your understanding.

Regards,

STOne-32.

 

[rk_iot]

Dear @STOne-32 

We are also waiting for a more detailed solution to this issue as we have build a board based on the STM32H7S78 and need to ensure that the XSPI RAM integration is working perfectly stable.

You said that:

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 . 

Was this hypothesis confirmed in the meantime and what code changes need to be applied to the examples of the STM32H7S78-DK board to avoid memory corruption when the environment temperature changes?

 

We are running our board with a XSPI frequency of 200 MHz. We could not find the values for ANSCR and APSCR in the source code or datasheet for the STM32H7S78 can you tell us where to find this values?

 

If you could provide more details on the proposed solution we would be happy to try your solution on our board and report if this could solve the XSPI RAM instability.

 

Thank you and best regards

rk_iot 

 

[STOne-32]

Dear @taste ,

On top of the Article, which is cooking, we planned an official Product Errata-sheet as well for STM32H7RS and planned to be public on web in next couple of weeks, then to trig the Article.

 

Thank you for the patience.

Regards,

STOne-32.

[STOne-32]

Dear all,

We just released the New Errata sheet here : STM32H7Rxx/7Sxx device errata - Errata sheet

 

Next step is the Knowledge Article, thank you for the patience.

Regards,

STOne-32.

[taste]

Thank you for releasing this information, it is good to have more details. It also raises questions of course, what to do when not booting at 25-30 degrees Celsius but at a much higher temperature. This can easily happen when rebooting after running at full load in higher ambient temperatures. I hope the knowledge article addresses this.
Are you planning a new silicon revision to fix this bug? 

[austinb]

I just wanted to ping here again and see if we have any updates on the knowledge article. I share the same concern as @taste here, knowing that it is very likely a system boots at temperatures other than 25-30 degrees.

[STOne-32]

Dear @austinb @taste ,

I would propose you to contact your local FAE or official ST office & support to discuss your application use case and understand the constraints.  

The Main purpose of the Errata is to do this operation only on-time at manufacturing production of the boards and then save the values to be used during the whole application life, in general at Manufacturing assembly of the MCUs the temperature is controlled, and we stay in Ambient Values not exceeding 30°C or let's say from  10 to 30°C.  

Hope it helps you

STOne-32.

[taste]

@STOne-32  This helps for sure, indeed during manufacturing we do have control over the temperature. If calibrating just once to adjust to the board specific characteristics is sufficient this is a workable procedure. We will also test if this works over th efull temperature range of our product.

[Schwarzbach]

@taste have you been able to test if a one-time determination of compensation values during production and setting these values after each reset led to a stable operation in your full temperature range? What is that range?

@STOne-32 is there an official confirmation that with this procedure (one-time determination of compendation values, using these values after each reset) ensures a stable operation?

 

Thank you and best regards

[Hamady]

Hello everyone 

Two question : @Schwarzbach Can you kindly share the code that fix the issue. I plan to realese a product with thip chip and it is not clear to understand how the workaroud "works".

 

@STOne-32 Do you plan to realese a knowledge base / exemple for this feature and the errata since it can be a big issue for the H7S7L8.

 

Thanks everyone 

[Schwarzbach]

@Hamady I also do not have a final solution for this. I think we are waiting for am waiting for @STOne-32 to provide an official statement like a knowledge base / example how to treat the issue.

Up to now, we achieve quite good results by disabling the SBS HSLV code generation in CubeMX and adding the following  user code:

 /* Configure the compensation cell */
 HAL_SBS_ConfigCompensationCell(SBS_IO_XSPI1_CELL, SBS_IO_CELL_CODE, 0U, 0U);
 HAL_SBS_ConfigCompensationCell(SBS_IO_XSPI2_CELL, SBS_IO_CELL_CODE, 0U, 0U);
 
 /* Enable compensation cell */
 HAL_SBS_EnableCompensationCell(SBS_IO_XSPI1_CELL);
 HAL_SBS_EnableCompensationCell(SBS_IO_XSPI2_CELL);
 
 /* wait ready before enabled IO */
 while(HAL_SBS_GetCompensationCellReadyStatus(SBS_IO_XSPI1_CELL_READY) != 1U);
 while(HAL_SBS_GetCompensationCellReadyStatus(SBS_IO_XSPI2_CELL_READY) != 1U);
 
 uint32_t code1, code2, nmos1, nmos2, pmos1, pmos2;
 
 HAL_SBS_GetCompensationCell(SBS_IO_XSPI1_CELL, &code1, &nmos1, &pmos1);
 HAL_SBS_GetCompensationCell(SBS_IO_XSPI2_CELL, &code2, &nmos2, &pmos2);
 
 HAL_SBS_ConfigCompensationCell(SBS_IO_XSPI1_CELL, SBS_IO_REGISTER_CODE, nmos1, pmos1);
 HAL_SBS_ConfigCompensationCell(SBS_IO_XSPI2_CELL, SBS_IO_REGISTER_CODE, nmos2, pmos2);
 
 HAL_SBS_DisableCompensationCell(SBS_IO_XSPI1_CELL);
 HAL_SBS_DisableCompensationCell(SBS_IO_XSPI2_CELL);
 
 /* high speed low voltage config */
 HAL_SBS_EnableIOSpeedOptimize(SBS_IO_XSPI1_HSLV);
 HAL_SBS_EnableIOSpeedOptimize(SBS_IO_XSPI2_HSLV);

 

@taste We did not increase/decrease the values by 2 yet, as also described in the errata - STM32H7Rxx/7Sxx device errata - Errata sheet.
That would be the next step to test.

[Hamady]

Hi @Schwarzbach 

I Had good result with the code below.

If i disable the compensation cell I have random hardfault but now everything run perfectly 

#define NMOS_ADJ +2
#define PMOS_ADJ -2

// Macro générique pour ajuster une valeur et la clamp sur une plage [0, 15]
#define ADJUST_AND_CLAMP(val, adj) ( ((int32_t)(val) + (adj) < 0) ? 0 : \
 (((int32_t)(val) + (adj) > 15) ? 15 : ((int32_t)(val) + (adj))) )

void configure_XPSI(){
	RCC_OscInitTypeDef RCC_OscInitStruct = {0};

	 __HAL_RCC_SBS_CLK_ENABLE();

	 /* System interrupt init*/

	 /* Enable the XSPIM_P1 interface */
	 HAL_PWREx_EnableXSPIM1();

	 /* Enable the XSPIM_P2 interface */
	 HAL_PWREx_EnableXSPIM2();

	 /* The CSI is used by the compensation cells and must be enabled before enabling the
	 compensation cells.
	 For more details refer to RM0477 [SBS I/O compensation cell management] chapter.
	 */
	 RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_CSI;
	 RCC_OscInitStruct.CSIState = RCC_CSI_ON;
	 if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
	 {
	 Error_Handler();
	 }


	 /* Configure the compensation cell */
	 HAL_SBS_ConfigCompensationCell(SBS_IO_XSPI1_CELL, SBS_IO_CELL_CODE, 0U, 0U);
	 HAL_SBS_ConfigCompensationCell(SBS_IO_XSPI2_CELL, SBS_IO_CELL_CODE, 0U, 0U);

	 /* Enable compensation cell */
	 HAL_SBS_EnableCompensationCell(SBS_IO_XSPI1_CELL);
	 HAL_SBS_EnableCompensationCell(SBS_IO_XSPI2_CELL);

	 /* wait ready before enabled IO */
	 while(HAL_SBS_GetCompensationCellReadyStatus(SBS_IO_XSPI1_CELL_READY) != 1U);
	 while(HAL_SBS_GetCompensationCellReadyStatus(SBS_IO_XSPI2_CELL_READY) != 1U);

	 uint32_t code1, code2, nmos1, nmos2, pmos1, pmos2;

	 HAL_SBS_GetCompensationCell(SBS_IO_XSPI1_CELL, &code1, &nmos1, &pmos1);
	 HAL_SBS_GetCompensationCell(SBS_IO_XSPI2_CELL, &code2, &nmos2, &pmos2);

	 // Appliquer ajustement + clamp
	 nmos1 = ADJUST_AND_CLAMP(nmos1, NMOS_ADJ);
	 nmos2 = ADJUST_AND_CLAMP(nmos2, NMOS_ADJ);
	 pmos1 = ADJUST_AND_CLAMP(pmos1, PMOS_ADJ);
	 pmos2 = ADJUST_AND_CLAMP(pmos2, PMOS_ADJ);

	 HAL_SBS_ConfigCompensationCell(SBS_IO_XSPI1_CELL, SBS_IO_REGISTER_CODE, nmos1, pmos1);
	 HAL_SBS_ConfigCompensationCell(SBS_IO_XSPI2_CELL, SBS_IO_REGISTER_CODE, nmos2, pmos2);

	 /* high speed low voltage config */
	 HAL_SBS_EnableIOSpeedOptimize(SBS_IO_XSPI1_HSLV);
	 HAL_SBS_EnableIOSpeedOptimize(SBS_IO_XSPI2_HSLV);

}