About FAQ: STM32H7 SRAM/Backup SRAM content is not preserved after reset

[Gpeti]

Hello,

Since several weeks I had program loading issues using Lauterbach Trace32 debugger on a STM32H753.

It came out it is due to the issue described here: https://community.st.com/t5/missing-articles/faq-stm32h7-sram-backup-sram-content-is-not-preserved-after/m-p/49291

Basically one 16 bits instruction of my code does not "fill" a whole SRAM word (as explained in the FAQ) and so it is written in the RAM cache and not in the real RAM.

When the debugger does a reset after the loading, this instruction is lost.

I have several questions:

- I feel that the issue should occur with any debugger and on any software. How are other debugger tackling this specific issue ?

-  The FAQ states that: To flush this cache after "word-unaligned" access, there are two options: perform other "unaligned" access to other SRAM word, perform read and write aligned operation on the same SRAM word as the last access. From my trials I think it should be: perform other write unaligned access. I noticed a read unaligned access is not sufficient. Could you confirm ?

[TDK]

Writing to SRAM, resetting, and then relying on that value is a relatively uncommon thing to do. No unheard of, but not something the typical program will do. During debugging, you're going to encounter this issue very quickly and will have to address it. This makes the issue pretty easy to spot.

The FAQ says to do a read and write, not just a read. Presumably just the write would be enough as that's what it needs to calculate ECC.

[Gpeti]

"Writing to SRAM, resetting, and then relying on that value is a relatively uncommon thing to do". indeed you're right. However load code directly in RAM in debug phase is not so uncommon. I will check with lauterbach why they suggest to work this way (load followed by reset). I might be easier to do first reset, then load the code (the core being kept in halt mode)

[TDK]

You can also use linker directives to ensure the file you're loading is a multiple of 32-bytes and avoid the situation.

[Pavel A.]

"Writing to SRAM, resetting, and then relying on that value is a relatively uncommon thing to do". 

Except this is how a debugger loads a program to the SRAM. And all these tricks where a program writes "magic value" for the bootloader and calls system reset.

This STM32H7 ECC issue is a major gotcha, IMHO should be included in the errata for all affected products.

[Gpeti]

I'm not sure it's so simple.

With GCC even if you add a ". = ALIGN(8)" directive after a section, the size of the section is still not a multiple of 8 bytes. Is there a way to force the size of a section ?

Also a debugger is usually loading a elf file which is a very complicated format (and elf sections are not exactly linker sections) so you have to take care that the size of every elf section that is loaded is a multiple of 8 bytes etc...

[waclawek.jan]

> This STM32H7 ECC issue is a major gotcha, IMHO should be included in the errata for all affected products.

It's in the RM, at least for 'H743 and kin:

--------

> With GCC even if you add a ". = ALIGN(8)" directive after a section, the size of the section is still not a multiple of 8 bytes.

Try adding

. = ALIGN(8);

at the end of given section. 

jw

[Gpeti]

"

Try adding

. = ALIGN(8);

at the end of given section."

That's exactly what I did. Doesn't change the size of the section (in the .map file at least), it only adds some zeros in between sections.

I think it is better to do as suggested in the Ref manual ie. do a dummy write access at another adress.

[waclawek.jan]

Oh.

Using linker based purely on manual is always a pain and one needs to resort to experimentation... Maybe using FILL() before .=ALIGN()?

Or, as a crude workaround, you can add 7 dummy bytes at the end of the section - maybe using BYTE(expression)  ...?

JW