STM32H7RS | H7S3L8 Core Freeze XSPI + DCACHE in Bootloader

[Fatih_Yildirim]

Hi,

I am experiencing a core freeze issue on STM32H7S3L8 MCU, as described below.

UPDATE 1: Most probably Data Cache is the main culprit, closing Data Cache in bootloader solves the problem. Application code Enables Data Cache and we have never observed any freeze errors in application code. Relocating the HASH code changes the behaviour but same error observed for both HW and SW Hash functions so Hash is probably irrelevant! (see the comment section.)

In the bootloader, I compute a HASH over the application image stored in external XSPI flash (memory-mapped XIP). After this process, "we believe", the core occasionally freezes and becomes inaccessible through the debug probe.

In the first scenario bootloader firmware remains unchanged; only the application binary varies. The freeze depends on the application binary. Some application images consistently trigger the issue on every power cycle, while others run without problems.

In the second scenario when using an application image that triggers the freeze and modifying the bootloader, disabling Data Cache or either by relocating the HASH processing block (see. “HASH HW START” and “HASH HW END”) or by commenting out a single line such as // HAL_HASH_DeInit(&hash); or // __HAL_RCC_HASH_CLK_DISABLE(); prevents the freeze and allows a normal jump to the application.

My observations:
1. Error doesn't happen when Data Cache is disabled.

2. Relocating the HASH HW code changes the behaviour

3. Changing the input clock source has no effect on the behaviour (HSE <-> HSI), core freezes with the exact same app binary.

4. I could not trigger the problem using a software HASH implementation.

Given the nondeterministic behavior, I was unable to reach a solution.
I welcome any advice or questions. Thanks in advance.

Pseudo-code which exhibits the exact flow of my bootloader. (I can't share the bootloader itself, unfortunately)

Systick_Init();
// Region 0: Start Addr: 0,         SIZE_4GB,  NO_ACCESS,   SubRegDisable: 0x87
// Region 1: Start Addr: 0x9000000, SIZE_32MB, FULL_ACCESS, SubRegDisable: 0x00, NOT_SHAREABLE, INSTRUCTION_ACCESS_ENABLE
MPU_Init();
SCB_EnableICache();
SCB_EnableDCache();

NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);
Clock_Init();	// Error occurs working with HSE and also with HSI mode.

CRC_Init();

LL_PWR_ConfigSupply(LL_PWR_DIRECT_SMPS_SUPPLY);

OptionBytes_Program();	// XSPI works in HSLV Mode

// XSPI1 and XSPI2 uses corresponding MCEs
XSPI1_Init();	// Uses ST EXTMEM Library for External FLash
MCE1_Init();

XSPI2_Init();	// Used for external PSRAM
MCE2_Init();

// HASH HW Start
// Core freezes somewhere after this point, beware that XSPI1 is in memory mapped mode // and we pass external flash address directly to the HAL_HASH_Start();
HASH_Init();	// Poll mode, SHA256 algo, HASH_BYTE_SWAP
// XSPI_APP_FLASH_BASE = 0x90000512, XSPI_APP_FLASH_SIZE = 512kB-512byte
uint8_t digest[32];
HAL_HASH_Start(&hash, XSPI_APP_FLASH_BASE, XSPI_APP_FLASH_SIZE, digest, 2000);
HAL_HASH_DeInit(&hash);
__HAL_RCC_HASH_CLK_DISABLE();
// HASH HW END

signature_success = uECC_verify(public_key, digest, signature);

[Fatih_Yildirim]

Update 1:

1. The same error occured on DISCOVERY_H7S7 board with the same bootloader. (Our bootloader supports NUCLEO_H7S3, DISCOVERY_H7S7 and our custom board.)
2. We have observed the problem with software hash implementation as well. So one can deduce that HASH was not relevant for this problem.
3. We think main culprit is the D-Cache. STM32H7S3L8 core is r1p2 and I couldn't find data cache errata related to our problem but we have had similar issues with STM32F765 in the past and disabled the data cache according to the errata.

@KDJEM.1, I’ve read your replies on XSPI in the forum, so I’m mentioning you in case you can provide any insights on this issue. Thanks for your help.

[AME MCU SM]

Hello @Fatih_Yildirim , 

Are you able to send me the project that replicates it on the DK board and tell me how to trigger it? 

Some additional questions for you:

1) What toolchain are you using and have you updated it to latest revision?

2) What is the CubeFW HAL version you are working with? Please make sure you have updated to the latest version. 

3) Are you doing cache maintenance (clean/invalidate) before/after reads/writes?  Or perhaps you can setup MPU to make regions accessed by your DMA non-cacheable? You can also give your external memory device memory attribute as shown in Table 91. TEX, C, B, and S encoding (see PM: STM32F7 Series and STM32H7 Series Cortex®-M7 processor programming manual). 

4) Can you do a register dump using the STM32CubeProgammer, using hot-plug mode after the lock up?

Thanks,

MCU Support