H7xx H743 EEPROM Emulation and load to SRAM on boot by linker

[MEdgerton]

Is there example code for EEPROM Emulation of the H7 series? I can only find it for older STM32 devices and it states that other devices should use different code.

If not can anyone confirm the smallest sector of the internal Flash that can be used? Is it 128K, so if I adapt the old examples I would need 256K as it uses 2 sectors/pages.

Any pointers welcome!

Also is there a way in the linker to have this loaded into RAM at boot, as some things like this can be if setup correctly. Thanks!

[Pavel A.]

> smallest sector of the internal Flash that can be used? Is it 128K

Yes, 128 K. And granularity of writes is 32 bytes.

> Also is there a way in the linker to have this loaded into RAM at boot

To have loaded what? code or data?

Note that H7 series has 4K of battery backed RAM which can store stuff if you have a battery. And the RTC user registers (32*4 bytes).

-- pa

[MEdgerton]

@Pavel A.​ Thank you for that info. I assume then the minimum being 32bytes means the examples by ST for the F series wont work?

The SRAM is useful but I need FLASH as its more permament.

Do you know of any example code?

[Pavel A.]

>  I assume then the minimum being 32bytes means the examples by ST for the F series wont work?

Correct. F series examples need adjustment.

> Do you know of any example code?

I did something of this sort but updating the whole blob of my data, not by separate variables, as in their "eeprom" examples.

It's better to get a real EEPROM or EERAM chip. Less PITA, less software complexity, more focus on your own product.

--pa

[MEdgerton]

@Pavel A.​  Thanks. I think writing as a whole blob at the end will be the best solution.

The problem was storing information such as checksums about the program for a bootloader to check. I want it permantently stored at a set place when it is written so it can be checked at startup.

Perhaps thats where I should have started as a question, but if there was a ready to go library or easily changed one that would have been the already tested and best route.

As you said the SRAM has an area which is backed up - I intend to use this to move some settings to and from the bootloader and main app but only at startup.

I noticed this battery backed up SRAM 4K does not show by default in the linker of STM32CubeIDE generated code for the H743 - or have I missed something?

Off topic to my original question but maybe relivant as it is semi-non-volatile, or at least persistant memory.

Other than that the RAM mapping of the H743 is somewhat fragmented so allocating another area for this other requirement needs careful checking whcih I may have to use if the 4K is not enough - the main app also needs a lot of it. If there is a recommended area to share that is best or you have found to be prefered it would help save time, and be greatly appriciated.

Otherwise I will configure the ethernet, MPU ICache, DCache and see the best area left - it has to work for both the main app and bootloader so a lot of cross-checking.

And thank you for making this a very useful community. I do try and search posts first, but sometimes it is a matter of finding the right keywords.

[Pavel A.]

For this purpose maybe just find a free space in the flash sector and write your info there after update.

> I noticed this battery backed up SRAM 4K does not show by default in the linker of STM32CubeIDE generated code for the H743

Correct. It is not a general purpose RAM. It can be accessed via a pointer, like any other device.

It survives reset, even without a battery. I use it to pass various parameters to/from the bootloader, why not. I've paid for it...

--pa

[MEdgerton]

When you say via a pointer is that the only way or can I add it to the linker and specify what goes into it?

[Tesla DeLorean]

Pointers and structures outside of the purview of the linker is one approach. This is generally how I deal with configuration spaces. Also have code to check/validate content as they copy to RAM structures, and initialize to workable defaults in the absence of those things.

You can make memory sections describing it, have those as NOLOAD or NOINIT so they don't get cleared via startup code, and direct variables in there via __attribute__ (section()) type constructs.

[Pavel A.]

> When you say via a pointer is that the only way or can I add it to the linker and specify what goes into it?

IMHO not worth tinkering with linker scripts when you can just write:

char *p = (char*)0x38800000;

Consider that contents of the backup RAM will be created by your code, it should not be loaded by the debugger every time when you debug the program.

[Piranha]

> It survives reset, even without a battery.

That is true for all SRAM memories - they don't change the state during the reset. :)