Flash memories are useful--but they're not magic
Scott Rosenthal
July, 1991
When flash memories burst on the scene about three years ago, industry pundits
proclaimed them to be as revolutionary as UV EPROMs (ultraviolet-erasable programmable
read-only memories) were almost two decades before. Proponents assert that those devices
make suitable replacements for battery-backed RAMs and floppy disks, can obsolete field
ROM replacements and might even supplant hard disks in some applications. But are these
extraordinary devices really the sure-all cure for embedded systems' ills or just another
useful tool? To answer that question, let's discuss how to design flash memories into an
embedded system and how an application might use them.
What's flash memory?
First, though, some background is appropriate. In this world of acronyms it's hard to
believe but the word "flash" refers to how fast you erase and reprogram these
devices, not some esoteric combinations of words. Flash memories are similar to UV EPROMs
in that you erase and reprogram them many times. In addition, they offer comparable data
retention times, their die's cell structure are approximately the same size and
complexity, and their manufacturing costs are roughly equal. The devices are also similar
in that you can perform random-access writes but must erase the entire device at once, and
that a blank device holds all Ones, and you program it by writing Zeros.
Despite these similarities, major difference exist between these two types of memories.
First concerns erasures. To erase a UV EPROM you either provide a high-intensity
ultraviolet light source in the design or replace the chips. In contrast, flash memories
only require a suitable voltage source making in situ reprogramming a snap. In fact, the
critical requirement for programming or erasing these chips is time---and plenty of it.
For example, before you can program a flash memory you must first set all memory locations
to 00H and then erase. If working with a 1M-bit device, you must program 131,072 bytes to
erase it completely. Under worst-case conditions this process can take almost 1.5 min!
In addition, each manufacturer has its own programming algorithm you must follow
explicitly to realize device longevity and data retention capabilities. As shown in the
programming flowchart for a typical device (Fig 1), some timing requirements are extremely
short and difficult to implement using hardware timers. Although some older flash memories
required careful coding to protect them from damage resulting from excessive programming
times, the current crop of devices incorporates on-chip timers to prevent such
destruction.
Writing to flash memories
The second major difference is tat a state machine controls a flash memory's internal
operation. Hence, prior to programming or erasing a flash device you must write a series
of commands to the chip to place it in the proper mode. For instance, the programming
algorithm specifies a pulsed technique similar to UV EPROMS, but you apply the programming
pulse to a memory location by writing commands instead of applying physical pulses to one
of the chip's pins. After pulsing the location, you use more commands to read the location
back and verify its contents. If the two values match, the byte is programmed correctly;
if not, you continue applying pulses to a vendor-defined maximum. New devices typically
program with only one pulse, but as devices age they need more pulses.
The programming algorithm also includes two delays that, taken together, produce a
minimum programming time of 2.1 sec for a typical 1M-bit device---and without any software
overhead! In addition, the datasheet for this device (Intel 28F010) states that if the
chip requires all 25 loops specified in Fig 1, programming the device can take as long as
52 sec. In come applications this time differential is insignificant, but in others the
difference between 2 sec and 52 seconds can mean the difference between market acceptance
and rejection.
Command execution times also vary significantly during erase cycles. To erase cycles.
To erase flash memories you must first program all locations to 00H, which can take as
much as 52 sec. Afterwards the erasing algorithm in Fig 2 sets the memory to all Ones. As
with programming, erasure is a pulsed algorithm that executes repeatedly until the entire
device compares to 0FFH. In my experience it takes roughly 50 erase pulses before any byte
appears erased and at least 200 pulses to erase an entire 1M-bit device. According to Fig
2, you can issue as many as 3000 erase pulses before the algorithm fails the device. On
older devices this limit was only 1000, so I assume Intel bumped it up because some parts
actually took more pulses. However, when using 200 pulses to erase a device, a rate of 10
msec/pulse yields an erase time of 2 sec, whereas the 3000-pulse maximum takes 30 sec.
Adding this worst-case erase time to the worst-case programming time for a complete erase
cycle of 82 sec.
Note that program and erase cycles both require a programming voltage(Vpp). Most flash
memories use 12V +5% with maximum power-on overshoot of 5%. International Power Sources
Inc. (Ashland, MA (508) 881-7434) sells a Vpp generator that runs from 5V and costs
approximately $20 (qty 100). If your system has access to a higher-level source, a
switchable regulator such as the LM2931CT from National Semiconductor (Santa Clara, CA
(408) 721-5000) works nicely and costs about $2 (qty 100). Remember, because you must
switch Vpp On for programming/erasing and Off again for normal operation, you must leave
enough delay in program code for the voltage's rise and fall times. The delay is typically
a few milliseconds but might be as much as 50 msec, so use a scope to check the times.
Good for storing code...
From the foregoing discussion of the methods required to read/write a flash memory it's
obvious that they aren't suited for all applications. For example, speed limitations
eliminate them from time-critical applications such as replacing floppies disks. Further,
because you can't erase single bytes, flash memories aren't suitable for holding values
that the target software must update frequently.
A good application for these devices, on the other hand, is as UV EPROM replacements
for program storage. The only trick is determining how the program gets into flash memory
in the first place. One way is to program the flash memories using a ROM programmer before
you solder them into the board. Loading devices in this manner, though, makes them no
different that UV EPROMs because you can't reprogram them in the board. About now you
might ask yourself, "Why can't I reprogram a flash device while it's soldered on a
board?" The answer is the chicken-and-egg paradox: How can the target system store
program code in flash memory if the code to control the device's programming isn't already
in the chip? Luckily, some tricks allow you to put the initial program into flash
memories. For example, a target system based on the 68HC16 can take advantage of a CPU
mode whereby the processor can automatically download a program through its serial port
and store the code in RAM. Hence you first download the flash programming code and the
target's operational program. Next, run the program in RAM, which writes the operational
program to the flash memories.
A less elegant technique for solving the chicken-and-egg problem involves building into
the target system a boot ROM containing a simple monitor program that allows you to either
download new code for flash memories or execute a program in flash memory. Done properly,
this technique uses a small, inexpensive UV EPROM for the bootstrap code while the main
program resides in the larger flash array. Remember, however, to keep the bootstrap code
short and simple. You should never need to change a good boot ROM---no matter how many
changes you make to the actual program code.
. . . or holding parameters
Another good application for flash memories is storing operational parameters. Although
a serial EEPROM is more economical for designs requiring less that 512 bytes of storage, a
target system that needs several kilobytes of parameters is an ideal candidate for flash
memories. In one design I needed to save and modify 20k bytes of information. Because a
flash memory can't erase and reprogram single bytes I simulated the operation of a normal
RAM by appending the updated information to the end of the flash's current contents. The
problem is that after a while the flash memory filled with updated data. What could I do?
If the program temporarily stored the newest information for the flash memory in RAM while
it erased the chip, an inopportune power outage would destroy the data and force the
operator to re-enter as many as 5000 numbers. To solve the problem, I designed in two
flash memories such that when Memory A is full, the program copies up-to-date information
to Memory B and then performs an erase cycle on Memory A. Likewise, when Memory B fills
up, the program performs the same process in reverse. To make this operation invisible to
the instrument operator, the program does all erasing and reprogramming in the background.
To prevent a program's data storage from occupying all the microprocessor's address
space, use a windowing or paging scheme to access the entire flash device. The technique
in Fig 3 uses two latched output ports from the microprocessor to hold address bits A8-17
for the 1M-bit flash memories while A0-7 go directly to the flash memory. To access the
flash memory, you simply write to the latches the correct bit combination for selecting
any 256-byte page or window in memory. This method requires only 256 bytes of the
microprocessor's address space yet still gives full access to whatever size flash memory
you install. You adjust page size up or down by varying the number of address bits held in
latches. For example, on 8-bit latch holding address bits A10-17 results in a 1024-byte
page size.
This paging technique also makes it easy to simulate flash memory on a host without the
target hardware. You merely create N files on the disk (where N equals the number of pages
of flash memory available in the target) and store them in separate subdirectories for
each flash chip in the system. Instead of your program selecting the proper page through
latches, it selects the page by choosing which file to access. In addition, the files are
small enough to allow you to easily analyze their contents for program verification and
yet are close enough to the operation of the flash memory to serve as a suitable model. PE&IN
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|
