eeprom emulation reliability - STM32H743I

[TMA1of3]

dear ST and/or Users,

we’re using STM32H743I with a requirement now to store several bytes of data in non-volatile memory.  We have known-working code for the existing application, and need to be assured it is not affected when eeprom emulation code is added.

There are (many) other posts in relation to eeprom emulation but we require further clarification in relation to some points, please.

We refer to ST’s code from this folder:

\Projects\STM32H743I-EVAL\Applications\EEPROM\EEPROM_Emulation\SW4STM32\STM32H743I-EVAL

We initially assumed this is properly working code – is that correct ?

The documentation mentions “At the beginning of the main program the HAL_Init() function is called …” – we already call this function in main, so assume no change here.

Apart from that we understand it is a matter of adding the initialisation routine EE_Init() as well as HAL_FLASH_Unlock() to main then using EE_WriteVariable() and EE_ReadVariable() whenever there is a need to access ‘eeprom’ – if that is not correct or if there’s more to do please advise.

The documentation mentions “The sectors used are as follows: -Flash Bank 2: Sector6, Sector7.”  The reason for using two (or multiple) sectors are explained in various ST application notes including AN3969.  All good - and we note these sectors are defined in the ST provided header files.  However, we’re unsure how it is specifying Bank 2 – do you know ?

Also, where/how is the code ensuring that flash memory used for normal program code is separated from the two sectors reserved for eeprom emulation, please ?  The eeprom emulation code will occupy two sectors, two lots of 128kB, meaning there is 2Mb minus 256kB still available for our program which is ample.  In another post we see a recommendation to change “START_PAGE_ADDRESS”, but that doesn’t appear to be used in this ST code ?

Of concern are the posts mentioning a problem with eeprom emulation in relation to an ECC error.  We note a great amount of work done by others in relation to this matter, and thank those individuals for sharing their findings (including @jaakjensen).  We would prefer not to replicate those investigations (especially as it seems it has taken significant time and effort in the past) - and I’m unsure after reading the posts whether there is a proven fix approved by ST ?

Do you know what if any version of the ST code referenced above resolves this problem, please, thereby providing a useable code ?  If not then what is the solution ?  It sounds like there’s a need to check and clear the RDS and RDP bits before erase/write operations ?  Is this the final answer ?  If the updated code has been published then apologies, but I have not found it.

In another spot we note a problem relating to a line of code that should be changed to “Address = Address - 64;” – this is already updated in the ST code we see.  But this is unrelated to the ECC error I believe.

Those other posts are now closed, so your assistance here would be greatly appreciated.

Have I missed anything else, please ?

Thanking you in advance for your assistance.

[waclawek.jan]

I don't know that library nor am I using 'H7 or Cube/HAL, but generally, any code you incorporate into your program is your responsibility, so it's mostly up to you to review that code; or, sometimes better, write your own, fitting your particular requirements.

JW

[Grant Bt]

How often are the "EE" variables updated? You should compare the number of potential updates versus the Flash Endurance of the part you are using. If the EE variable changes approach the Flash Endurance, then you need to make sure that the algorithm has wear leveling.

For instance, I made a product with a backlight intensity that may be changed often by the user, and always remembered. In that case I added wear leveling. It is generally not required for me though, since primarily I download settings from a PC application and that is a rare event.

[Tesla DeLorean]

>>We initially assumed this is properly working code – is that correct ?

Adequate to demonstrate functionality. You need to test it to your own standards of completeness. ST takes no responsibility, basically a you-use-it you-own-it type license.

You can exclude areas of FLASH in the Linker Script so a) they are not used and b) you get errors/warnings if you exceed or get close too.

The large size and long erase time can be problematic if it blocks real-time execution of code and interrupt.

Depending on the size/frequency of the data being updated, you might want just implement a simpler journalling method. The EE library uses two sectors to this and ping-pongs between the two for basic wear-leveling.

If you have external FLASH or SD CARD / eMMC consider that.

[TMA1of3]

Thanks @Tesla DeLorean .

Your second paragraph – are you able to provide an example in relation to exclusion of flash through the linker script, please ?

The 743xI User main memory is between low address 0x0800 0000 and high address 0x081F FFFF (corresponding to 2MB of memory). 

This is split between two banks.

Bank 1 = 0x0800 0000 to 0x080F FFFF.

Bank 2 = 0x0810 0000 to 0x08FF FFFF.

Sectors 6 and 7 of Bank 2 are - 0x081C 0000 to 0x081F FFFF corresponding to two lots of 128kB, and these sectors are at the end of the memory space (if we take 0x0800 0000 as being the start).

I still don’t know how the ST code is choosing Bank 2 – do you know, please ?

In this project we see system file “STM32H743VI_MemoryMap.xml” which includes the line:

<MemorySegment start="0x08000000" name="FLASH" size="0x200000" access="ReadOnly" />

0x08000000 is the start of User main memory, as we saw above, and 0x200000 corresponds to the overall 2MB size of Flash memory in this micro.

Would it help to modify this file ?

If we change the above line to:

<MemorySegment start="0x08000000" name="FLASH" size="0x1C0000" access="ReadOnly" />

will it provide our desired outcome ?  Meaning the overall length is reduced from 0x200000 to 0x1C0000 with the part being removed corresponding to the Sectors 6 and 7 which is then free from interference when used with the eeprom emulation implementation.

I suppose this helps explain why ST chose Sectors 6 and 7 – they are at the very end of Flash memory making it easier to separate from the rest ?

And … external memory is not an option here due to the need to work with an existing hardware.

[TMA1of3]

Thanks @Grant Bt .

We’re not really/yet concerned at this stage about the endurance of the Flash.  These calibration values will be written once (or twice) in the factory then later read once per power-up.  So, very few reads and writes.

The other points, and resulting questions, are where some concerns do lie.

Hoping to hear further in relation to those.