Using chip Flash memories

Flash memories are pretty interesting chips. Note that here I mean actual, small flash chips placed on board, like this Micron chip. SD cards, SSD drives and such are very different beasts with their internal load balancing management modules. I mostly use chips with serial interfaces and have really no practical experience with parallel ones but many of the same rules should apply there too. There is also the reliability; for some reason I trust those small SOIC8 chips to retain my data way more than some random SD card.

Smaller flash memories cost almost nothing (one linked above being about 2€ in one-off quantities), come in nice, small 8-pin packages and are very easy to use over SPI bus, so it's very easy to throw one on your PCB for some extra storage as long as you have a few unused GPIO lines on the MCU.

There is some cost however. They are not the easiest memory chips to work with. You can't just freely change single byte or two within the memory; to do that you'll need to erase (wipe) one full sector (typical size being about 4 kilobytes), then write contents of entire block there again.

While that might not be too difficult, there is only limited number of erases you can do to a sector before it becomes defective - 10000 erases is fairly typical today, but it can be as low as 1000 in some cases. So by rewriting one sector continuously you'll wear out the memory very quickly. Unlike mentioned SD cards or SSDs there is no wear balancing - unless you do it by yourself.

So if you have some data that changes very often, you might want to pick some other memory type. But flash is very nice for data that isn't changing often - static binaries, configuration data, logs and such that needs only to be accessed and erased every now and then.

Similar intelligent load balancing as used by mentioned SDs/SSDs isn't exactly easy to do, as those is built to support random writes, transparent sector remapping and whatnot. However by designing your data usage pattern with minimal erase cycles in mind the implementation can actually be quite easy.

Note that above I said that you can't freely re-write any byte but must do that per sector basis. This, while true, isn't complete truth. When Flash sector is erased, bits within it are erased to all ones. All bytes to 0xFF. The nice thing is that any bit within a sector can be written to zero, at any time, without having to touch anything else. This small detail is often overlooked (and may not even work with all flash chips - test yours first), but it makes flash chips way more usable for many things.

So one way to implement incremental writes might be this:

You allocate, say, ten sectors for your data and start writing to first sector byte by byte, always to next untouched 0xFF. When you cross to a new sector, you first erase it (checking first if it needs to be erased is a bonus) and start writing there. When the last allocated sector is full, switch back to first one, erase it and so on.

There's of course a bit more to that, like reading entries in incremental order, resuming writes from correct position after power failure, allocating enough sectors so that erase count will not reach maximum specified on datasheet (or preferably, 80% of specified maximum over lifetime of your device) and so on, but they shouldn't offer too much trouble for clever hacker so I just mention those here in passing.

Many flash chips also offer additional features, like memory protection (both full chip protection as well sector bank protections), chip identifiers and such, so make sure to read the entire datasheet. There's nothing more frustrating than some write protection bit somewhere when you're trying to communicate with the chip, and typically chip-level write protects defaults on on when powered up.

The type identifier bytes also make very good test bytes; both when trying to get your code to work, and later when system is doing self-test. Can't read those constant bytes? Something's obviously wrong.

And now the flash chips should be way less scary beasts. Get a few and play around with them - low cost storage is always a nice thing to have. Happy hacking!