STM32H7 noinit RAM Section Woes

[thestumbler]

I've been fighting a SRAM memory problem for days now. I've carved out a 32-byte hole in memory to hold messages between the boot loader and main application that will persist across MCU reset cycles.

I already had this working in my F4 implementation and didn't consider it to be a big deal. I was wrong.

For this H7 version, I chose the 4 KB battery backed SRAM block at 0x3880,0000. Even though I don't need battery backup, this seemed like a good fit for the purpose. And it gave me the option of battery backup in the future, and allows growth of the shared memory block without any impact to the main memory layout of the application.

But things didn't work well at all. I'm seeing all kind of weirdness. Some things I'm seeing suggest I'm still not handling the write cache and/or other setups properly. But another bug makes me additionally suspect the linker or the startup code. I will often, but not always, observe the last two bytes of the buffer get corrupted.

It occurs to me that the logical meaning of a NOINIT section doesn't explicitly mean "don't touch this section, even at startup before the program begins"

Has anyone conquered the successful use of this SRAM region?

[salkinium]

I've not used the backup SRAM before. I believe it is powered by its own power and clock domain, so maybe check that those are really correctly enabled in the RCC (the early __modm_initialize_platform() should enable it).

If you want to be sure that it's not the startup script writing there, you can remove the __{bss,data}_backup_{load,start,end} entries from the table at the end of the (generated) linkerscript. Alternatively you can use a debugger to enable a hardware watchpoint on the memory and check what really writes there (while keeping in mind that H7 only has imprecise watchpoints, thus the PC will already have progressed passed the write).

[thestumbler]

Yeah. I think I nearly have it fixed. I learned that some of these issues can be avoided by waiting for the power enable but to be true after you turn it on. I also found some questionable things in my code that might not be playing well with a cached memory, and got most of that cleaned up. I've got one more thing to sort out today but I think it will be easy.

That imprecise breakpoint "feature" may be causing some of my confusion, thanks for reminding me.

[thestumbler]

I can see the correct address in the map file.