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.