Flash memory for Data storage?

I mostly write to it with factory configuration data (ie. serial number of board, date of manufacter, etc.) Don't think there's a limit to the number of times you can read it.

That sounds like a pretty typical use to me. Code updates, configuration parameter storage. As erik noted, flash doesn't have the lifespan to be used as main memory for a running application. But for data that changes less often, it can be useful.

Just to expand on some of erik's points:

1) flash can not be simply written, it must be erased before write

See the data sheet for your part for details. There's typically a state machine inside the flash looking for a particular sequence of bus cycles to appear before it accepts a value to be programmed. There are two main algorithms, which I think of as "Intel" and "AMD", but there are little variations and extensions from every manufacturer. This is one reason some parts give you routines built into their boot ROM to do the programming for you. It's essentially some BIOS routines to deal with the flash.


2) flash can not be written at the speed SRAM can

Quite a bit of understatement here. Even the read access time for typical flash is slower than SRAM (say 80-120ns instead of 10-20ns). But the time to write a value is much longer, say on the order of 10-100 us. And before you can write a value, you generally need to erase the sector containing it, which takes even longer (perhaps hundreds of ms per sector for a large flash device). Check your data sheets.

3) Flash can only be written a limited number of times before it fails

It's a bit more accurate to say it can only be "erased" a limited number of times, but that's tantamount to the same thing if you're talking about storing arbitary values.

The limits in question are fairly large for the uses I think of as typical. To give an idea of the range, most parts are generally around 100,000 erase cycles. Good parts often guarantee a million erase cycles. Cheap ones are sometimes only 10,000.

So if you're talking about code upgrades or configuration updates, there's no worry in practice. If you're talking about a non-volatile file system updated by the code, you have to be a little more careful. And there's no way flash could support general variables in your code, like loop counters or your serial data ring buffer or whatever. Even if the write performance weren't a limitation, the flash would wear out far too quickly.

Just for the sake of completeness, note that all these comments apply to "NOR" flash. There's another kind of flash technology, "NAND" flash, which usually has a longer lifespan, erases more quickly, is higher density (for the same price). NAND flash has a number of other limitations, though -- it's accessed sequentially instead of randomly, with a programmed I/O interface instead of appearing as a normal memory device, and NAND parts ship with bad blocks and blocks can fail during use, which means your software has to do some sort of bad block detection and list management to deal with it. NAND flash is usually used for file system type applications, where you've got a layer of file system software to deal with the bad blocks, and the increased capacity and lifespan are important. For direct execution of code, you need the random access properties of NOR flash.

I mostly write to it with factory configuration data (ie. serial number of board, date of manufacter, etc.) Don't think there's a limit to the number of times you can read it.

That sounds like a pretty typical use to me. Code updates, configuration parameter storage. As erik noted, flash doesn't have the lifespan to be used as main memory for a running application. But for data that changes less often, it can be useful.

Just to expand on some of erik's points:

1) flash can not be simply written, it must be erased before write

See the data sheet for your part for details. There's typically a state machine inside the flash looking for a particular sequence of bus cycles to appear before it accepts a value to be programmed. There are two main algorithms, which I think of as "Intel" and "AMD", but there are little variations and extensions from every manufacturer. This is one reason some parts give you routines built into their boot ROM to do the programming for you. It's essentially some BIOS routines to deal with the flash.


2) flash can not be written at the speed SRAM can

Quite a bit of understatement here. Even the read access time for typical flash is slower than SRAM (say 80-120ns instead of 10-20ns). But the time to write a value is much longer, say on the order of 10-100 us. And before you can write a value, you generally need to erase the sector containing it, which takes even longer (perhaps hundreds of ms per sector for a large flash device). Check your data sheets.

3) Flash can only be written a limited number of times before it fails

It's a bit more accurate to say it can only be "erased" a limited number of times, but that's tantamount to the same thing if you're talking about storing arbitary values.

The limits in question are fairly large for the uses I think of as typical. To give an idea of the range, most parts are generally around 100,000 erase cycles. Good parts often guarantee a million erase cycles. Cheap ones are sometimes only 10,000.

So if you're talking about code upgrades or configuration updates, there's no worry in practice. If you're talking about a non-volatile file system updated by the code, you have to be a little more careful. And there's no way flash could support general variables in your code, like loop counters or your serial data ring buffer or whatever. Even if the write performance weren't a limitation, the flash would wear out far too quickly.

Just for the sake of completeness, note that all these comments apply to "NOR" flash. There's another kind of flash technology, "NAND" flash, which usually has a longer lifespan, erases more quickly, is higher density (for the same price). NAND flash has a number of other limitations, though -- it's accessed sequentially instead of randomly, with a programmed I/O interface instead of appearing as a normal memory device, and NAND parts ship with bad blocks and blocks can fail during use, which means your software has to do some sort of bad block detection and list management to deal with it. NAND flash is usually used for file system type applications, where you've got a layer of file system software to deal with the bad blocks, and the increased capacity and lifespan are important. For direct execution of code, you need the random access properties of NOR flash.