STM32H7S78-DK xspi external RAM corruption when using Template_LRUN example

[rk_iot]

Hello,

we are experiencing RAM corruption when running an application in external RAM when setting a breakpoint while debugging.

The issue can be reproduced using following configuration:

1. Open example STM32Cube_FW_H7RS_V1.1.0\Project\STM32H7S78-DK\Templates\Template_LRUN\STM32CubeIDE\Boot\.cproject in STM32CubeIDE 1.15.0

(import both Boot and Appli when asked)

2. Build the Template_LRUN_Boot-Project and start it to download the bootloader to internal flash

3. Exchange the main.c of the Template_LRUN_Appli with the attached main.c and build the application

4. Use STM32CubeProgrammer to download Appli/Debug/Template_LRUN_Appli.bin to location 0x70000000

(Connect to STM32H7S78-DK board, click '+' , Open File and select Template_LRUN_Appli.bin, Click Download-Arrow-Down and enter 0x70000000 as Address and Enter to download the Applikation)

5. Reset the board - the Led LD1 should be blinking in 1 second interval 

6. Attach the debugger to the running application by right-clicking on Template_LRUN_Appli in STM32CubeIDE and choose Debug As - STM32 C/C++ Application

7. When setting a breakpoint in the while(1) loop and waiting for approx. 30 seconds and then resuming the program, the Led LD1 stops blinking, signalling that the content of the external memory at 0x90000000 has changed (CRC32 is different)

We also used an J-Link to read out the content of the external RAM before and after setting a breakpoint and waiting for 30 seconds and it shows that a lot of values in the external RAM have changed randomly.

We also tested multiple boards all showing the same behavior. 

It seems that the external RAM corruption is triggered by halting the CPU core at a breakpoint and waiting for some time.

Is this a known issue or do you have any idea what could be the cause for the RAM being corrupted?

Thank you and best regards,

rk_iot

[Saket_Om]

Hello @rk_iot 

Thank you for bringing this issue to our attention.

I reported this internally.

Internal ticket number: 204247 (This is an internal tracking number and is not accessible or usable by customers).

[rk_iot]

Hello @Saket_Om 

are there any updates for the internal ticket number 204247 on this issue or will you post in this forum, if there is an update?

Thank you and best regards

rk_iot

[Dor_RH]

Hello @rk_iot,

The project works correctly.

Could you please let us know if the issue happened before or after you modified the main.c file?

Thank you for your collaboration.

Dor_RH

[rk_iot]

Hello @Dor_RH 

the RAM corruption also happens without any modifications in main.c. The modifications in main.c were only made to detect the RAM corruption, by permanently checking the crc32 of the external RAM section.

The external RAM corruption is triggered by setting a break-point while debugging and waiting for approx 30 seconds:

6. Attach the debugger to the running application by right-clicking on Template_LRUN_Appli in STM32CubeIDE and choose Debug As - STM32 C/C++ Application

7. When setting a breakpoint in the while(1) loop and waiting for approx. 30 seconds and then resuming the program, the Led LD1 stops blinking, signalling that the content of the external memory at 0x90000000 has changed (CRC32 is different)

Have you tried attaching the debugger to the application and setting a breakpoint?

We have tried it on multiple boards also with different compilers/IDEs and j-Link debuggers, all combinations show the exact same behavior:

The external RAM is getting corrupted when the program is halted for approx. 30 seconds by setting a breakpoint, so there seems to be an underlying issue.

The longer the program is halted, the more locations in the external RAM are getting corrupted.

You can also do a memory dump before and after setting the breakpoint to see, that the external RAM gets corrupted.

Thank you and best regards

rk_iot

[Dor_RH]

Hello @rk_iot,

We have tested with several boards and the project works correctly.

It is essential to follow the steps outlined in the README file.

N.B: Since it is not possible to load the application from the toolchain, for debugging, you must attach the debugger to the running target.

You could also refer to this post for additional help: Connecting to Running Target.

I hope my answer has helped you. When your question is answered, please select this topic as solution that answered you, it will help others find that answer faster.

Thanks for your contribution.

Dor_RH

[rk_iot]

Hello @Dor_RH ,

we are a team of experienced STM32 software developwers and are really sure that we correctly identified the issue.

To make it more clear, we've included another version of main.c which will turn on the red LED LD2 when an RAM corruption is detected.

In normal behavior the red LED should never be switched on, because the content in external RAM is not changed.

But when you set a breakpoint at the line

crc32_current = crc32calc(0,external_ram_content,1024*1024);

while debugging and wait for 30 seconds before resuming the program, the red LED will be switched on, showing that there was a RAM corruption in external RAM.

It seems that halting the CPU for 30 seconds causes bit flips in the external RAM.

We first experienced the problem with our own project and later on tested it with the standard CubeMX-Examples which showed the same behavior. 

Could you have another try to reproduce the issue? We are really confident that the external RAM showing corruption when halting the CPU for more than 30 seconds in debug mode.

Thank you and best regards

rk_iot

[Dor_RH]

Hello @rk_iot,

The problem is under investigation, we will get back to you as soon as possible.

Thank you for your understanding.

Dor_RH

[rk_iot]

Hello @Dor_RH 

thank you for further investigating the issue, we are sure that this will help many developers suffering from the same problem.

Best regards

rk_iot