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.
