0

How many times can I write to the flash storage?
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

How many times can I write to the flash storage?

by OutstandingBill on Tue May 18, 2021 8:16 am

How many seas must a white dove sail?

For my project, I need the Itsy M4 to remember changes the user makes to settings. I've assumed that the best way is to write the settings to the board's flash storage as soon as the user changes the setting value. For background, the project is a guitar effects pedal, and the settings that need to be saved are values selected using rotary encoders. Guitar pedals can see a lot of knob twiddling. Incidentally, I don't think using an SD card is viable because the user needs to be able to update the settings files via a USB port on the guitar pedal enclosure, and I don't think an SD card would be accessible from there.

I'd been blithely writing new code to my board over and over, refining it and testing it, twiddling knobs and writing settings to the storage. Then suddenly my board became read-only. This post https://askubuntu.com/a/1006840/1146212 suggests the flash memory may be worn-out. This makes me wonder if my project will have a limited lifetime because of the flash lifetime. If this is a likely cause of the problem, one mitigating approach would be to modify the software to reduce the number of times the storage is written to.

So my questions are these:
1. Is there a way to diagnose flash health?
2. Can I safely format and manipulate the partitions of the flash storage as if it were a USB drive, and then use .UF2 it to bring it back to life as a sentient IsyBitsy being?
3. What does the flash memory degrading process look like on an ItsyBitsy? And if one part of its memory becomes worn out, will it automatically choose a different piece of storage to write to?
4. Am I just on the wrong track altogether?

OutstandingBill
 
Posts: 33
Joined: Fri Nov 29, 2019 3:22 pm

Re: How many times can I write to the flash storage?

by blnkjns on Tue May 18, 2021 8:44 am

Can't find any info on the actual flash type in the M4, but if it is SLC* it would mean 100.000 erase/write cycles, which is at 1 write per 5 min, and 1 hour per day use, 24 years of life expectancy.
* Single level cells would make most sense as all is pretty basic in a microcontroller, and flash size is not very big compared to say SD cards.

blnkjns
 
Posts: 663
Joined: Fri Oct 02, 2020 3:33 am

Re: How many times can I write to the flash storage?

by OutstandingBill on Tue May 18, 2021 9:42 am

Thanks blnkjns. If you're right about the life expectancy, that would mean I am probably on the wrong track. I have been busy developing my project, but I'd estimate I've done a couple of thousand writes at most.

Any help with my other questions about formatting and reviving would be much appreciated then.

OutstandingBill
 
Posts: 33
Joined: Fri Nov 29, 2019 3:22 pm

Re: How many times can I write to the flash storage?

by adafruit_support_mike on Tue May 18, 2021 10:03 pm

Flash memory uses 'floating gate' mosfets: ones with two gates, one of which is completely surrounded by insulator. The floating gate is controlled by another pad a short distance away.

Connecting high or low voltage to the control pad for a certain amount of time makes it possible for electrons to jump the gap through quantum tunneling. Then the charge on the floating gate remains trapped when the control pad is disconnected. That trapped charge makes it easier or harder to turn the mosfet on with the regular gate. The array controller probes the mosfets by giving the regular gates a voltage that's a little too low to turn the mosfet on by itself.

The trapped charge trick isn't guaranteed to work every time, so the data is stored redundantly using an error-correcting algorithm. Instead of storing a single bit, values are stored in chunks (usually 64 bits) with enough redundant storage to recover all 64 bits with high confidence (statistically about 1 error per century). The chunks are called 'pages' of memory, and every bit of physical storage has an influence on the 64 logical bits in the page. Therefore pages are written all 64 logical bits at a time.

The trapped charge trick also relies on the physical bits being set to 1 and 0 with equal probability. A bit that gets too many 1s in a row won't be able to lose enough charge to make it a 0 during a normal write. Flash arrays deal with that problem a couple of ways: first, they do an erase cycle that sets every logical bit to 0, then they run the pattern of physical bits through a 'data whitening' algorithm that gives each bit a 50% chance of being high or low.

Together, that accounts for Flash arrays requiring an erase-write cycle before every write, and requiring full page writes.

The tricks that make Flash work are statistically reliable, but real data has an inescapable amount of structure. Over time, there's a nonzero chance that physical bits will get stuck. At that point, the array has to rely on error recovery to get the correct logical values for the 64 bits in that page. The error correcting codes can handle up to N stuck bits correctly, but eventually a page of physical storage will have more than N stuck bits. At that point, all 64 logical bits of the page are unreliable.

The degradation process is gradual, but its effects are invisible until the N+1th physical bit gets stuck. Then it's a statistical matter before enough of the N+1 bits have the wrong value to create an error in one of the logical bits. At that point you have to consider the page dead.

There's no way to detect stuck bits from outside the chip, and there's no way to recover dead bits without a better chance of creating new ones.

Physical pages are independent of each other, so the death of one has no effect on any other.

The rate of physical bit failure is a function of the entire history of data stored in the page and the statistical probability of quantum tunneling. A page's ability to survive bit failure depends on the amount of redundancy built into the error-correcting code. Most vendors design for 100,000 read-erase cycles.

Microcontrollers don't audit their Flash storage automatically, but you can write code that checks the stored value after each erase-write cycle. Reading a page has no effect on physical bit failure. If the code that checks stored data sees an error, it can move to a new location.

As an alternative, you can cycle through the Flash array storing values to a new location every time. That way you'll cycle through the whole array before writing any page a second time. The expected lifespan will be 100,000 times the number of pages in the array, divided by the number of pages you use for each block of storage.

adafruit_support_mike
 
Posts: 63059
Joined: Thu Feb 11, 2010 2:51 pm

Re: How many times can I write to the flash storage?

by OutstandingBill on Wed May 19, 2021 12:53 am

Thanks Mike, that's really interesting. Is there any way I can influence it to
cycle through the Flash array storing values to a new location every time
using CircuitPython, or when updating the code via USB? Perhaps I'd need to be writing to selected memory locations using C?

Currently, my code looks like this.

Code: Select all | TOGGLE FULL SIZE
with open(self.fileName, "w") as f:
    f.write(configLine)


Thanks again for the super informative post.

OutstandingBill
 
Posts: 33
Joined: Fri Nov 29, 2019 3:22 pm

Re: How many times can I write to the flash storage?

by adafruit_support_mike on Sat May 22, 2021 7:54 pm

CircuitPython's 'microcontroller' module has a function named 'nvm' which treats the nonvolatile RAM as a byte array:

https://circuitpython.readthedocs.io/en ... roller.nvm

I don't think you can control the byte position with the 'storage' module though.

adafruit_support_mike
 
Posts: 63059
Joined: Thu Feb 11, 2010 2:51 pm

Re: How many times can I write to the flash storage?

by OutstandingBill on Tue May 25, 2021 8:42 am

I can write to my M4 board again - hurrah! Thanks to munocat for figuring out what was needed viewtopic.php?f=19&t=160710

OutstandingBill
 
Posts: 33
Joined: Fri Nov 29, 2019 3:22 pm

Re: How many times can I write to the flash storage?

by moonie223 on Thu May 27, 2021 7:29 pm

In case you haven't heard of it, the M4 devices have an internal SmartEEPROM peripheral built into the NVM controller. It uses a looot of flash to emulate a little bit of eeprom, and the cool bit is you don't need to really do much of anything on your end, it's all handled automatically. You get a pointer to the start of the emulated array and can access it byte by byte individually.

It uses all that extra flash and some of the flash properties already mentioned to increase the number of writes that can be made without writing entire pages, or erasing entire blocks. Basically stretching the number of changes that can be made without harming flash. The big bummer is how much flash it wastes, and how slow it can get if you need more than ~4k of storage.

Really basic library, but it seems to be working!
https://github.com/deezums/SmartEEPROM

moonie223
 
Posts: 40
Joined: Sun Feb 05, 2017 2:44 pm

Re: How many times can I write to the flash storage?

by adafruit_support_mike on Fri May 28, 2021 5:07 pm

Hmm.. interesting. Thanks for posting the info!

adafruit_support_mike
 
Posts: 63059
Joined: Thu Feb 11, 2010 2:51 pm

Re: How many times can I write to the flash storage?

by OutstandingBill on Sat Jul 17, 2021 9:35 am

moonie223 wrote:In case you haven't heard of it, the M4 devices have an internal SmartEEPROM peripheral built into the NVM controller. It uses a looot of flash to emulate a little bit of eeprom, and the cool bit is you don't need to really do much of anything on your end, it's all handled automatically. You get a pointer to the start of the emulated array and can access it byte by byte individually.

It uses all that extra flash and some of the flash properties already mentioned to increase the number of writes that can be made without writing entire pages, or erasing entire blocks. Basically stretching the number of changes that can be made without harming flash. The big bummer is how much flash it wastes, and how slow it can get if you need more than ~4k of storage.

Really basic library, but it seems to be working!
https://github.com/deezums/SmartEEPROM


Thanks moonie223 - that could be really useful. If I understand correctly, nvm can be used instead of regular storage, providing (a) I work with a byte array instead of text files, and (b) I don't use more than 4k for performance (I read elsewhere that 8k is the absolute maximum). I typically need around 3k of storage, and it should be fairly straightforward to adapt to using a byte array, so I think nvm would be fine.

Do you know how much longer this lasts than the regular storage on the Itsy?

OutstandingBill
 
Posts: 33
Joined: Fri Nov 29, 2019 3:22 pm

Please be positive and constructive with your questions and comments.