For these two microcontrollers, ST has prepared appropriate EEPROM emulation documentation:<\/p>\n\n\n\n
- \n
AN2594 – EEPROM emulation in STM32F10X microcontrollers<\/a><\/li>\n\n\n\n
AN3969 – EEPROM emulation in STM32F40x STM32F41x microcontrollers<\/a><\/li>\n<\/ul>\n\n\n\nThe principle is the same for both families. I will briefly discuss how the emulation works.<\/p>\n\n\n\n
Data representation<\/h3>\n\n\n\n
Data in FLASH is stored in 32-bit cells. These cells are divided into two parts. One is a 16-bit virtual address of the EEPROM variable. The other part is the value of that variable. Why so? Because each variable update writes its new value to the next free FLASH cell. We do not overwrite the old value.<\/p>\n\n\n\n
Why do we need two memory pages?<\/h3>\n\n\n\n
If each new value of a variable is written to a new cell, eventually those cells will run out. When that happens, the old page is designated for data transfer to a new page. We do not transfer all data. We are not interested in historical data of variables, so we scan the full page from the end and transfer the newest values of variables to the new page. After moving to the new page, it is marked as active, and the old one will be erased entirely (erasing the whole FLASH page).<\/p>\n\n\n\n
Reading from the emulated EEPROM<\/h3>\n\n\n\n
To read a variable at the appropriate virtual address, you need to scan the entire page written so far. Each time a variable with the virtual address we require is encountered, its value is remembered. The next encounter of the same variable updates the remembered temporary value. The search continues until we encounter an erased cell, i.e., one with a virtual address of 0xFFFF. Hence the use of this virtual address is forbidden. The last remembered value is returned as the one currently stored in our EEPROM.<\/p>\n\n\n\n
Writing to the emulated EEPROM<\/h3>\n\n\n\n
Writing searches for the first free cell on the memory page. If it finds one, it writes the given virtual address and the value we provide. If there are no free cells on the page, the procedure of transferring the newest copies of variables with unique virtual addresses begins. Only after that will our variable be written to the first free cell on the new page. The old one will be erased. The pages are used alternately in this way.<\/p>\n\n\n\n
Data update flow<\/h3>\n\n\n\n
You will find the entire process of writing sample data and transferring it to a new page illustrated in the documentation for F1 (p. 8) and F4 (p. 11).<\/p>\n\n\n\n
EEPROM emulation library<\/h2>\n\n\n\n
Reading the documentation and devising a library for correct EEPROM emulation behavior can make your head spin a bit. Fortunately, ST has prepared an appropriate library. In addition, it works out of the box with our favorite HAL. The entire library boils down to only three functions<\/strong>, which makes it incredibly simple to use. You can, however, stretch your brain a bit with its configuration in the eeprom.h file. That\u2019s where the complete configuration of the EEPROM emulator is located. Let me first discuss this configuration. The definitions we are interested in are:<\/p>\n\n\n\n
- \n
- #define PAGE_SIZE<\/strong> \u2013 defines the size of the pages to be used. You can find this information in the microcontroller\u2019s Reference Manual or in the HAL libraries.<\/li>\n\n\n\n
- #define EEPROM_START_ADDRESS<\/strong> \u2013 from which address in memory the EEPROM emulation will be located. I recommend using the end of FLASH so as not to collide with the main program. This address will be the address of the first FLASH page used.<\/li>\n\n\n\n
- #define PAGE0_BASE_ADDRESS\u00a0<\/strong>
#define PAGE0_END_ADDRESS\u00a0<\/strong>
#define PAGE0_ID\u00a0<\/strong> \u2013 the start and end addresses of the zeroth emulation page and the ID of the first page in FLASH. The same exists for PAGE1 of the EEPROM.<\/li>\n\n\n\n- #define PAGE0<\/strong>
#define PAGE1<\/strong> \u2013 the description in the header is misleading and talks about how many FLASH pages are used for EEPROM pages. In fact, the important definition is PAGE1, which says how many pages away it is relative to the start of PAGE0. If you want to use 2 FLASH pages per one EEPROM page, you will enter the number 0x2 in PAGE1.<\/li>\n\n\n\n- #define NB_OF_VAR\u00a0<\/strong> \u2013 the number of unique variables we want to store in the emulated EEPROM. This is important because the library needs a table of virtual addresses and you have to create it earlier in the program.<\/li>\n<\/ul>\n\n\n\n
Library functions<\/h3>\n\n\n\n
As I mentioned, the user has 3 simple functions at their disposal. Here they are:<\/p>\n\n\n\n
- \n
- uint16_t EE_Init(void)<\/strong> \u2013 initializes the EEPROM emulator. It checks whether pages were previously written (by the header) and whether they need to be erased. Restores usability after power loss.<\/li>\n\n\n\n
- uint16_t EE_ReadVariable(uint16_t VirtAddress, uint16_t* Data)<\/strong> \u2013 Reads a variable from EEPROM. The variable at the virtual address VirtAddress will be placed in the memory pointed to by Data.<\/li>\n\n\n\n
- uint16_t EE_WriteVariable(uint16_t VirtAddress, uint16_t Data)<\/strong> \u2013 Writes to EEPROM. The variable at the virtual address VirtAddress will be written with the value Data.<\/li>\n<\/ul>\n\n\n\n
All these functions return status codes compatible with HAL.<\/p>\n\n\n\n
Simple to use, right? Time to work with real devices.<\/p>\n\n\n\n
EEPROM emulation on STM32F103C8T6<\/h2>\n\n\n
\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/09\/BluePill_baner.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n<\/p>\n\n\n\n
First, I took the popular BluePill<\/a>. Allow me to skip the Cube configuration and the schematic this time. They\u2019re not important in this exercise. I only configured the built-in LED and UART2 to send the contents of the emulated EEPROM to the terminal.<\/p>\n\n\n\n
Configuration<\/h3>\n\n\n\n
For proper configuration I will need the Reference Manual with the FLASH memory map of the microcontroller.<\/p>\n\n\n
\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/07\/eeprom_emulation_f103c8_memorymap-300x262.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nWe are interested in Main memory. We have 128 pages of 1 kB each. For tests I can use the last two. In general, I would recommend using the ending pages. <\/p>\n\n\n\n
In the eeprom.h header file you can notice that the addresses of each page are already predefined. You could even skip looking at the documentation to configure it correctly, but it\u2019s better to make sure no one made a mistake in the code.<\/p>\n\n\n\n
The page size is already defined in the HAL library. You can just make sure it is about 1 kB, i.e., 0x400.<\/p>\n\n\n\n
We want to use the last two pages, so I set EEPROM_START_ADDRESS<\/strong> to the penultimate page, which is ADDR_FLASH_PAGE_126.<\/strong><\/p>\n\n\n\n
Now the addresses of the two EEPROM emulation pages and the number of pages used. You can use the previously predefined addresses or play with offsets.<\/p>\n\n\n\n
#define PAGE0_BASE_ADDRESS ((uint32_t)(EEPROM_START_ADDRESS + 0x0000))\n#define PAGE0_END_ADDRESS ((uint32_t)(EEPROM_START_ADDRESS + (PAGE_SIZE - 1)))\n#define PAGE0_ID ADDR_FLASH_PAGE_126\n\n#define PAGE1_BASE_ADDRESS ((uint32_t)(EEPROM_START_ADDRESS + 0x400))\n#define PAGE1_END_ADDRESS ((uint32_t)(EEPROM_START_ADDRESS + 0x400 + PAGE_SIZE - 1))\n#define PAGE1_ID ADDR_FLASH_PAGE_127\n\n\/* Used Flash pages for EEPROM emulation *\/\n#define PAGE0 ((uint16_t)0x0000)\n#define PAGE1 ((uint16_t)0x0001)\n<\/pre>\n\n\n\n
And the number of stored variables.<\/p>\n\n\n\n
#define NB_OF_VAR ((uint8_t)27)<\/pre>\n\n\n\n
Program code<\/h3>\n\n\n\n
For the library to work, you need to create an array of virtual addresses.<\/p>\n\n\n\n
uint16_t VirtAddVarTab[NB_OF_VAR];<\/pre>\n\n\n\n
Later I fill this array with consecutive values.<\/p>\n\n\n\n
\/\/ Fill EEPROM variables addresses\nfor(VarIndex = 1; VarIndex <= NB_OF_VAR; VarIndex++)\n{\n VirtAddVarTab[VarIndex-1] = VarIndex;\n}\n<\/pre>\n\n\n\nIt is very important to unlock FLASH from the program level before using the function that initializes the library.<\/p>\n\n\n\n
HAL_FLASH_Unlock();<\/pre>\n\n\n\n
Now you can initialize the EEPROM. <\/p>\n\n\n\n
if( EE_Init() != HAL_OK)\n{\n Error_Handler();\n}<\/pre>\n\n\n\nFrom now on, you can use the EEPROM. In the program I created an array with sample data that I will write to EEPROM. It contains the string \u201cMateusz Salamon msalamon.pl\u201d. It consists of 27 characters, which I previously took into account in the configuration.<\/p>\n\n\n\n
In the program I write and read this data from the EEPROM according to the scheme:<\/p>\n\n\n\n
- \n
- Write the data to EEPROM. Each character at its unique virtual address.<\/li>\n\n\n\n
- Read and print to the terminal<\/li>\n\n\n\n
- Write the data to EEPROM in reverse order.<\/li>\n\n\n\n
- Read and print to the terminal. The text should be reversed.<\/li>\n\n\n\n
- Write the data to EEPROM.\u00a0<\/li>\n\n\n\n
- Read and print to the terminal. The effect is the same as in pt. 2<\/li>\n<\/ol>\n\n\n\n
You can see the effects from the terminal in the screenshot.<\/p>\n\n\n
\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/07\/eeprom_emulation_write_read-300x192.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n<\/p>\n\n\n\n
And what happens to FLASH memory? What do I expect? According to the EEPROM emulation documentation, the text should land under variables with virtual addresses 1\u201327 first in normal order, then reversed, and finally normal again. The result is below.<\/p>\n\n\n
\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/07\/eeprom_emulation_flash_content_f103c8-300x164.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nData marked 1 are from the first write. 2 is the reversed write. 3 is a subsequent write in normal order. Please analyze this data. The first cell at the top left is the page header. It is in the ERASED state, so you can write to this page.<\/p>\n\n\n\n
Then there is the data. The first 16 bits (4 digits) are the virtual address of each variable. The second 16 bits are the value, i.e., the characters from the string.<\/p>\n\n\n\n
EEPROM emulation on STM32F401RE<\/h2>\n\n\n
\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2020\/07\/Nucleo-64-baner.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n<\/p>\n\n\n\n
The organization of memory in microcontrollers can vary. For this reason, you should always check the documentation. In the F4 series we can be slightly surprised because the FLASH memory looks like this:<\/p>\n\n\n
\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/07\/eeprom_emulation_f401re_memorymap-300x173.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n<\/p>\n\n\n\n
We have only 8 sectors and they are not equal in size. Remember that FLASH erasing is done per entire sector<\/strong>. It would be sad to use 256 kB of FLASH for a few EEPROM variables. That\u2019s why I will use sectors 2 and 3. Configuration:<\/p>\n\n\n\n
\/* Define the size of the sectors to be used *\/\n#define PAGE_SIZE (uint32_t)0x4000 \/* Page size = 16KByte *\/\n\n\/* Device voltage range supposed to be [2.7V to 3.6V], the operation will\nbe done by word *\/\n#define VOLTAGE_RANGE (uint8_t)VOLTAGE_RANGE_3\n\n\/* EEPROM start address in Flash *\/\n#define EEPROM_START_ADDRESS ((uint32_t)0x08008000) \/* EEPROM emulation start address:\nfrom sector2 : after 16KByte of used\nFlash memory *\/\n\n\/* Pages 0 and 1 base and end addresses *\/\n#define PAGE0_BASE_ADDRESS ((uint32_t)(EEPROM_START_ADDRESS + 0x0000))\n#define PAGE0_END_ADDRESS ((uint32_t)(EEPROM_START_ADDRESS + (PAGE_SIZE - 1)))\n#define PAGE0_ID FLASH_SECTOR_2\n\n#define PAGE1_BASE_ADDRESS ((uint32_t)(EEPROM_START_ADDRESS + 0x4000))\n#define PAGE1_END_ADDRESS ((uint32_t)(EEPROM_START_ADDRESS + (2 * PAGE_SIZE - 1)))\n#define PAGE1_ID FLASH_SECTOR_3\n\n\/* Used Flash pages for EEPROM emulation *\/\n#define PAGE0 ((uint16_t)0x0000)\n#define PAGE1 ((uint16_t)0x0001) \/* Page nb between PAGE0_BASE_ADDRESS & PAGE1_BASE_ADDRESS*\/<\/pre>\n\n\n\n
The number of variables I set the same as for F1<\/p>\n\n\n\n
\/* Variables' number *\/\n\n#define NB_OF_VAR ((uint8_t)27)<\/pre>\n\n\n\n
The code in main.c is the same. The result on the terminal is identical to F1, and in FLASH memory it looks similar, except at a different address.<\/p>\n\n\n
\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/07\/eeprom_emulation_flash_content_f401re-300x164.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nI also checked how long it takes to write and read my character array.<\/p>\n\n\n\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/07\/eeprom_emulation_timings_erased_flash-1024x157.jpg\")
<\/a><\/figure>\n\n\n\n<\/p>\n\n\n\n
173 ms for write and 3.24 ms for read. Interestingly, these values do not change significantly with increasing FLASH occupancy. There is one moment when this time will be very large. This is the transfer of data to a new EEPROM page and the erasing of FLASH sectors.<\/p>\n\n\n\n
EEPROM emulation before the main program<\/h3>\n\n\n\n
As you probably noticed, I defined EEPROM emulation in the middle of the F401RE FLASH. I would be reluctant to use half of the available memory for EEPROM if I defined it on the last two sectors.<\/p>\n\n\n\n
For this reason, I came up with the idea to put the EEPROM on the first two sectors and move the main program to sector 2. Unfortunately, performing this operation causes some error in the program\u2019s operation and the microcontroller crashes… I dug into the code a bit and found a problem in the function that verifies whether the page is erased. It is used in the initialization where the program crashes. There is even a thread on ST\u2019s forum regarding this bug<\/a>.<\/p>\n\n\n\n
Unfortunately, my attempts to fix this snippet did not help. Perhaps the problem is still somewhere else, or it is simply not possible to swap EEPROM with the main program.<\/p>\n\n\n\n
The only thing that comes to my mind while writing this article is to split the project into a bootloader and a main program. The bootloader would be run from the starting address and would jump to the main application, which is located after the next two empty sectors. Then the piece of FLASH between the bootloader and the main program could be used for EEPROM emulation \ud83d\ude42<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
Is it worth using EEPROM emulation? Judging by the fact that the code has had easy-to-find bugs for many years, I suspect few people use it. The operation of EEPROM emulation is also not ideal. It takes at least two sectors (pages) of FLASH memory.<\/p>\n\n\n\n
As you saw, in F4 series microcontrollers, EEPROM emulation can be very troublesome due to the different sizes of memory sectors.<\/p>\n\n\n\n
There is one more issue I did not address. The lifetime of this solution. FLASH memory is not a longevity champion. A single memory cell can withstand only about 10 thousand<\/strong> write cycles. This is not a large number, especially compared to the lifetime of EEPROM at around one million cycles<\/strong> (AT24C32 memories from Atmel).<\/p>\n\n\n\n
So the question arises \u2014 is it worth emulating EEPROM? Sometimes yes, sometimes no \ud83d\ude42 You need to answer this individually. It depends on the project. You can use an STM32 that already has EEPROM in its structure. You can use an external chip. There are at least several solutions. <\/p>\n\n\n\n
However, it is worth knowing that in extreme situations you can use FLASH memory as an emulated EEPROM. It works correctly, so for rarely changed data it can be quite a good way.<\/p>\n\n\n\n
You can find the test codes along with libraries on my GitHub: F103C8<\/a>, F401RE<\/a><\/p>\n\n\n\n
Do you think I made a mistake somewhere? Do you have an interesting idea for what could be improved? Share it in the comments! Remember that the discussion should be polite and in accordance with the rules of the Polish language.<\/p>\n\n\n\n
- uint16_t EE_ReadVariable(uint16_t VirtAddress, uint16_t* Data)<\/strong> \u2013 Reads a variable from EEPROM. The variable at the virtual address VirtAddress will be placed in the memory pointed to by Data.<\/li>\n\n\n\n
- #define EEPROM_START_ADDRESS<\/strong> \u2013 from which address in memory the EEPROM emulation will be located. I recommend using the end of FLASH so as not to collide with the main program. This address will be the address of the first FLASH page used.<\/li>\n\n\n\n
![\"kurs](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2019\/06\/Kurs-STM32-zapisy.png\")
<\/a> \u2014 content is in Polish.<\/p>\n\n\n\n![\"?\"](\"https:\/\/s.w.org\/images\/core\/emoji\/12.0.0-1\/svg\/1f609.svg\")
<\/figure>\u00a0Btw, I\u2019ve been following your blog for a long time, and I have to say that it maintains a high level. Nicely written, to the point and interesting. Regards\u00a0![\"?\"](\"https:\/\/s.w.org\/images\/core\/emoji\/12.0.0-1\/svg\/1f642.svg\")
<\/figure>\u00a0I am delighted that the blog already has topics that interested me, including displays and the accelerometer. But I would be more interested in using both the FPU and the ADC options in \u2018more advanced\u2019 signal processing. The topic could also include simple processing procedures such as FFT to change from the time domain to the frequency domain, as well as simple\/more complex signal conditioning systems into ones friendly for the processor, measurement relative to a virtual ground, etc. I think that despite the omnipresent digitization, such a topic could be useful\u00a0