Emulated EEPROM and STM32Bootloader.

Generic boards that are not Maple or Maple mini clones, and don't contain the additional USB reset hardware
Post Reply
alexandros
Posts: 76
Joined: Mon Oct 02, 2017 6:51 pm

Emulated EEPROM and STM32Bootloader.

Post by alexandros » Fri Feb 02, 2018 2:47 pm

HEllo there..

i am using the Emulated EEPROM of the "128k" STM32F1 MCU , and i loaded also the STM32Bootloader

The bootloader is writen on 0x800000 and the sketch is writen on 0X8002000

i have 2 questions

1)the EEPROM.PageBase0 = have to be start on 0x801F000 ?

2)i am encountering lots of problems like when a number of writes be done , i get errors "EEPROM_OUT_SIZE " and the some values are not be stored.
Is there another library besides the known one?

alexandros
Posts: 76
Joined: Mon Oct 02, 2017 6:51 pm

Re: Emulated EEPROM and STM32Bootloader.

Post by alexandros » Sat Feb 03, 2018 9:01 am

i used this address EEPROM.PageBase0 = 0x08019000;//0x801F000;
wich is the bottom of the memmory , i wont do such a large sketch
and it seems that everything is steady. :?

victor_pv
Posts: 1871
Joined: Mon Apr 27, 2015 12:12 pm

Re: Emulated EEPROM and STM32Bootloader.

Post by victor_pv » Sat Feb 03, 2018 1:21 pm

The eeprom library uses 2 pages. Page 0 is the bottom one.
The page size is a hardware characteristic, so taking that in account, page0 base address needs to be 2x pagesize from the top of flash or lower, so there is enough space to fit page0 and page1 without getting past the top flash memory address.
You can of course set it to a lower address, i.e. 5 pages down from the top of flash.
The stm32duino bootloader only erases the necessary pages to fit the sketch, to the page boundary of course.
In the bluepill the page size is 1KB, the bootloader takes 8KB. If your sketch takes, rounding to the KB, 24KB, then you can place your page0 base anywhere after the bottom 32KB.
It's a good idea to start from the top down just so you can keep your data even if you update your sketch and gets bigger, otherwise you would have to move up the page base after the sketch grows, but is not a requirement. If your code is final, you can start place your page0 base right after the sketch.
There is a forum post with a modification on the library to write 8bit values, rather than the 16bit values it currectly uses. A limitation is that the address field is only 8 bits too, so you can only write 256 virtual addresses. The benefit is that using 8bit for address and 8bit for data, you can fit 512values in 1 1KB page, so double the number of data items per page, so the flash page will take twice the number of writes before it has to be erased.
With 2 pages it would take 1024 writes before each has to be erased once. If you only need up to 256 different positions of 8 bit values, that code will give you twice the endurance.

Note: In the library in the repo, the virtual address field and data items are 16bit in size even if you want to write 8bit values, in that case 8bits of the data fields are empty, but the flash wears out at the same rate as if you wrote 16bits values.

Flash can be rewritten about 1000 times as per the specs (likely much more, but not guaranteed), so calculate how many times you expect to rewrite those pages in the lifetime of your project, to see if it is too many times and you will end up getting errors.
i.e If you write a table of 256 values every 5 minutes, you will be filling up 1 page every 5 minutes. There are 2 pages, so a page is erased every 10 minutes.
That's 6 per hour, 144 per day.
1000/144 = 6.94 days.
So after a week, you have worn down your flash pages and may start getting errors. Since there is no CRC mechanism in the library or the flash, either you implement a CRC mechanism, or you just can't rely on the written data at that point.

So due to the endurance it's good for something that doesn't get updated too often, so your project can run for years to come.
If you need more endurance, use an actual eeprom memory, or modify the library so it can use more than 2 pages of flash.

alexandros
Posts: 76
Joined: Mon Oct 02, 2017 6:51 pm

Re: Emulated EEPROM and STM32Bootloader.

Post by alexandros » Sat Feb 03, 2018 6:11 pm

Thats a fantastic reply, thanks a lot for your time
i want to find out if i am making something wrong from code part , before i add an extrernal eeprom

My code is final only some bug to take care , the page0 base propably will be after the sketch .i just need 200 values to store every "value" will be from 0-254 ~ 8bit, nothing else. my sketch takes 70kB , and only when i do a "clear settings factory reset" will do a EEPROM.format and in every 200 values of memory will write to eeprom the value 0. after that all the default values will be stored , so yea in some seconds wll be written 2 times
in every usage will be 6 values and not every day

i searching that post with the modified library for 8k values, this might save me.

what does it mean ".... number of writes before it has to be erased." something i am missing ?

victor_pv
Posts: 1871
Joined: Mon Apr 27, 2015 12:12 pm

Re: Emulated EEPROM and STM32Bootloader.

Post by victor_pv » Sat Feb 03, 2018 6:21 pm

alexandros wrote:
Sat Feb 03, 2018 6:11 pm

what does it mean ".... number of writes before it has to be erased." something i am missing ?
For every data value you save, the library saves a pair of values. An index, and the data itself.
In this way, it reduces wear out of the flash. So if you are using the one that stores bytes, in 1KB can store 512 pairs. So you could write the same "address" 512 times with different values before you have to erase the page. Or you could write 2 addresses 256 times each.
So if only a few of the addresses are written frequently, it wears the flash down more slowly.

You will understand it better by reading the STM application note that describes it:
http://www.st.com/content/ccc/resource/ ... 165693.pdf

alexandros
Posts: 76
Joined: Mon Oct 02, 2017 6:51 pm

Re: Emulated EEPROM and STM32Bootloader.

Post by alexandros » Sat Feb 03, 2018 7:01 pm

victor_pv wrote:
Sat Feb 03, 2018 6:21 pm
alexandros wrote:
Sat Feb 03, 2018 6:11 pm

what does it mean ".... number of writes before it has to be erased." something i am missing ?
For every data value you save, the library saves a pair of values. An index, and the data itself.
In this way, it reduces wear out of the flash. So if you are using the one that stores bytes, in 1KB can store 512 pairs. So you could write the same "address" 512 times with different values before you have to erase the page. Or you could write 2 addresses 256 times each.
So if only a few of the addresses are written frequently, it wears the flash down more slowly.

You will understand it better by reading the STM application note that describes it:
http://www.st.com/content/ccc/resource/ ... 165693.pdf
So your telling me with the bytes method that this command

deviceaddress=10
data =1
EEPROM.write( deviceaddress,data);

i can execute it 512 times. then it gets full,? that explains the error i get, if it gets full i have to "remember" the last value , and clear this particular address in order to store my current value?

victor_pv
Posts: 1871
Joined: Mon Apr 27, 2015 12:12 pm

Re: Emulated EEPROM and STM32Bootloader.

Post by victor_pv » Sat Feb 03, 2018 7:20 pm

alexandros wrote:
Sat Feb 03, 2018 7:01 pm
victor_pv wrote:
Sat Feb 03, 2018 6:21 pm
alexandros wrote:
Sat Feb 03, 2018 6:11 pm

what does it mean ".... number of writes before it has to be erased." something i am missing ?
For every data value you save, the library saves a pair of values. An index, and the data itself.
In this way, it reduces wear out of the flash. So if you are using the one that stores bytes, in 1KB can store 512 pairs. So you could write the same "address" 512 times with different values before you have to erase the page. Or you could write 2 addresses 256 times each.
So if only a few of the addresses are written frequently, it wears the flash down more slowly.

You will understand it better by reading the STM application note that describes it:
http://www.st.com/content/ccc/resource/ ... 165693.pdf
So your telling me with the bytes method that this command

deviceaddress=10
data =1
EEPROM.write( deviceaddress,data);

i can execute it 512 times. then it gets full,? that explains the error i get, if it gets full i have to "remember" the last value , and clear this particular address in order to store my current value?
You don't have to do anything, the library takes care of house cleaning. But with the 8bit version of the library (the one from the forum post), you can write that 512 times and the flash page is cleared only once.
If you use the 16bit version, when you write it 256 times the page is cleaned once. So the 8bit version reduces the wear by half, as long as you only need to store 8bit values, and only in up 256 addresses, since the address only uses 8bits also.


User avatar
RogerClark
Posts: 7693
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Emulated EEPROM and STM32Bootloader.

Post by RogerClark » Sat Feb 03, 2018 8:42 pm

The library may not be suitable for what you want to do..

There are different strategies for managing the lifetime of flash, and this library uses one of them, but it appears it’s designed to handle individual variables that don’t change too often.

BTW. @victor. Though the number of erase cycles was 10,000 not 1000 ( but I have not checked the spec recently)

Anyway, even 10,000 erase cycles if not much use for data logging, especially using this scheme as it wastes 50 of the space ( 50 of the lifespan) on the Address byte.

For data logging, most people consider using an external SD card, which although it has the same number of erase cycles, the enormous size of it e.g. 16G byte is about the smallest SD card I seem to be able to buy locally... The number of times you would need to erase a page in that flash, would be reduced by a factor of a thousand or a million.

Or. Use a different time of storage that does not have a low erase count lifespan ( various types of this are available, but they are expensive)

Or use a different internal storage strategy, e.g. reserve 1 page for tracking which page is the currently active page, and use a rolling buffer across all other available pages
E.g. remember, you can clear individual bits in a freshly erased page of flash. So a lot of the flash management algorithms, use a system where they clear individual bits, one by one, to indicate the address of the last byte written.

Also, if you know your data can never contain a value like 0xffff, then you can easily find the last address written, by searching backwards from the end of the flash until you find a value that’s not 0xffff

Post Reply