Can I write single bit to EEPROM and count it as 1/8 of write cycle of 100k EEPROM write cycles in case of internal stm32l073 EEPROM?

[MŁask.1]

Hello,

When I clear eeprom byte to 0xff I count it as single clear. Now when I write value to this byte I count it as single write. So according to RM I have 100k of safe read write operations like that.

Can I assume that writting single bit to this byte is one eighth of this write operation?

so:

1. Perform clear = byte is equal to 0xff
2. Write 0x7F = clear MSb
3. Write 0x3F = clear nex bit
4. and so on
5. write 0x01 = only one bit left
6. write 0x00 = whole byte is cleared.

Can I assume above procedure as single clear/write cycle? And safely execute 100k times?

I need to count and store 100000000 events in system (number of them). By using 8 bits for 100k cycles I only need 125 bytes to track those events. If I use uint32_t to store that I would have to use 4MB to safely store that event counter.

I cant find in documentation if when I write byte, internal controller always clears this byte and writes new one, or just writes new value.

Unfortunately I think, that always clear option is used becouse this looks like internal controller just clears cell and enters new value without explicit clear/write:

HAL_FLASHEx_DATAEEPROM_Unlock();
FLASH_WaitForLastOperation(FLASH_TIMEOUT_VALUE);
 
*(__IO uint32_t *)Address = Data;
 
FLASH_WaitForLastOperation(FLASH_TIMEOUT_VALUE);
HAL_FLASHEx_DATAEEPROM_Lock();

Thanks

Maciek

[S.Ma]

Contacting ST officd maybr keeded to get an official statement.

Long time ago, when erase and write were 2 separate APIs, the cycling counts were erase related. So my guess would be that you are correct. Remains to know if this is on a 8-bit byte basis or wider.

[MŁask.1]

Remains to know if this is on a 8-bit byte basis or wider.

Haven't thought about that!!!! But I think that it shouldn't internally erase something that shouldnt be erasing. So if I request byte update, only this byte is erased/cleared. Otherwise if something goes wrong between erase and write more bytes would be broken... not just only the one I'm updating.

[S.Ma]

Acutally, if you check I2C standlone eeproms, they have a page of 8 bytes or higher. When you write a page, original data is put in registers, then modified some by you, then erase write cycle is kicked in....

[KiptonM]

You used to be able to do this. But I think some of the more modern chips make it easier for you to write, and they handle the erase for you.

I would guess the way to see is to time it.

Erase the smallest size, and that would make the byte of interest 0xFF

Time how long it takes to write 0xFE.

If it takes the same time to then write 0xFC then it is not automatically erasing. If it takes longer, then it is probably seeing the byte is not 0xFF and "helping you" by erasing it first, then rewriting the byte.

The other thing to try is Write 0xFE, then Write 0xFD. If the answer is 0xFD it erased. If the result is 0xFC then it did not erase. Because write only changes 1 to 0 but not 0 to 1. (At least it used to do that. Note, I have been programming since 1974).

I am guessing this is very manufacturer dependent, and you would have a better chance with an EEPROM that has been on the market longer.

The other option is to use a FRAM instead of an EEPROM. That is what I would do when I am worried about number of writes.

I do not mess with this kind of trick anymore and would only try it if it was a very very cost sensitive application where we were building over 10K a month for a consumer application.

[Tesla DeLorean]

FLASH/EPROM we certainty were able to knock down individual bits in older design generations..

FLASH lines in these devices are significantly wider, so the 35 ns (or whatever) fetch time is amortized over a number of bytes (8 or 16). Additional bits also present to do ECC or hamming code type checking, so as to avoid the whole device failing if one or two bits in the entire array are defective.