Issue using STM32H7S7xx with external RAM/FLASH over XSPI1

[ken5]

We are developing a STiROT/OEMuROT bootloader for a customer using the above chip. This is based on the STM32H7S78-DK sample. The customer has developed the main application and have added support to download a new firmware image over Ethernet. This image is stored in external RAM and once downloaded an md5 checksum of the image is stored and a flag is set to indicate that new firmware is available. At this point the device is restarted to switch to the bootloader.

We've added code to the bootloader that checks if a new firmware image is available in external RAM. If a new image is available the bootloader validates that the image is OK by recalculating the md5 checksum. The validation passes and at this point a section in external FLASH is erased. After the erase completes, the image in external RAM is copied into the external FLASH and the copied image is validated via md5 checksum - which fails.

On further investigation it is the data being read from external RAM that is incorrect (we downloaded an image with known data to test this). So it appears that erasing external FLASH causes some corruption of either the data in external RAM or reading the data. This error is repeatable: the error occurs at the same address in external RAM, and reads the same (incorrect) value. We have a number of devices available to us and all exhibit this behaviour, though while the errors are repeatable for each devices they can differ between devices in terms of location and values. We've also tried with the STM32H7S78-DK development board and have the same behaviour.

Other information: XSPI1 and 2 are swapped, MCE is disabled.
We've also applied the latest changes to Src/stm32h7rsxx_hal_xspi.c, commit 0838ced without success.

Has anyone encountered anything similar to this?

Any suggestions on likely causes or configuration changes that we could try will be greatly appreciated!

[KDJEM.1]

Hello @ken5 and welcome to the community;

 

For this application, I recommend you to configure your project step by step (without Ethernet, then add ethernet) 

Also, I advise you to look at Security:How to start with STiRoT OEMuRoT on STM32H7S - stm32mcu wiki.

Through this practical example you will learn:

• What is STiRoT and OEMuRoT for STM32H7S and how to use the STM32CubeFW example which is provided.
• How to configure the STiRoT and the debug authentication.

 

I hope this help you.

Thank you.

Kaouthar

[ken5]

Hello @KDJEM.1 

Thank you for your response!

We worked with the  document that you linked early in the project. It's very useful and clearly written and has helped us a lot with the project.

I've managed to build the customer application without ethernet configured. The application then writes dummy data to external flash, and reboots to start the bootloader. Unfortunately this hasn't solved our issue - we are still errors in the data when the bootloader reads from external RAM after erasing external FLASH.

Kind regards

Ken

 

[CMYL]

Hello @ken5 

There is a documented erratum for STM32H7S and STM32H7R devices related to XSPI I/O compensation. The issue is that enabling I/O compensation can alter the duty-cycle of high-frequency output signals. This is particularly relevant when the XSPI interface is used at high frequency in DTR mode. The clock output signal may fall outside the recommended duty cycle range (e.g., 45%-55%) due to the interaction between the compensation cell, PCB, memory, and load conditions.
To be sure you are not hitting the XSPI + compensation cell errata : 

- Can you implement the recommended workaround in the errata sheet and check again ? (ES0596 - Rev 9 2.2.15 I/O compensation could alter duty-cycle of high-frequency output signal)
- Or just run the same setup at a lower CPU frequency (for example, 400–480 MHz)  and check again ?

Best Regards

Younes
 

[Andrew Neil]

@Steve Melnikoff also has a thread on the same topic: STM32H7Sx: unknown setting causing data corruption.

[Steve Melnikoff]

We've found a possible fix for this issue; see this post.