Flash Memory Technology and Techniques
Class 327 Embedded Systems Conference Spring 98
William Grundmann, Intel Corporation
OVERVIEW
Flash memory has emerged as a
mainstream technology for storing firmware
in embedded systems. While flash memory
can be used like an EPROM–installing a
programmed device into a PCB–such an
implementation wastes a great deal of
functionality. The same flash memory that
stores the firmware can store data that is
important to an end user or service technician.
All that is needed to take full advantage of
flash memory?s capabilities is an
understanding of how to use flash, and
perhaps a few suggestions on how flash can
improve a product.
This paper provides an overview of
flash memory technology—how to read,
write, program and erase it. It continues by
taking a brief look at how a flash memory cell
stores data. This is useful, because it explains
some of the unique operating characteristics
of flash.
There are two new developments that
will increase the density of flash memories
and make them easier to use. Multi-Level
Cell technology allows two bits to be stored
in one transistor. The Common Flash
Interface is a new JEDEC standard that
improves forward and backward
compatibility. Both will be covered.
This paper will discuss three
techniques that improve a product or
manufacturing flow without adding
substantial cost: programming the boot code
in-system, logging errors in flash and adding
removable media to an embedded system
INTRODUCTION TO FLASH MEMORY
The type of flash memory used in
most embedded systems has the same kind of
bus interface as EPROMs or SRAMs. Some
of the first applications for flash were to
replace EPROMs for firmware storage, so
good way to introduce flash memory is to
compare it to EPROMs.
PROGRAMMING AND ERASING
When operating in a system,
EPROMs have one kind of bus operation, bus
read, and one operating mode, read array.
EPROMs cannot be written to in-circuit, so
they have no internal state machines that can
be put into special modes. EPROMs do have
other modes of operation though. They can
be programmed in a programmer by applying
elevated voltages--the programmer adds two
modes: program and verify. There is another
mode, erase. In this mode the EPROM is
illuminated by UV light, and all the cells are
erased..
Current flash devices have all this
built in. Consequently, flash devices need
two types of bus operations--read and write.
These two operations are used to put the
memory into a variety of operating modes:
Read Array, Program, Erase, and so on.
BUS OPERATIONS
The bus operations for all flash
memories are static in nature. There is no
maximum time between edges and
operations. Figure 1 shows qualitative timing
diagrams for read and write bus transactions.

CE#
ADDRESS
OE#
DATA OUT
READ WAVEFORMS
CE#
ADDRESS
WE#
DATA IN
WRITE WAVEFORMS
Figure 1
BUS Read
The read interface of a typical flash
memory is identical to a standard EPROM.
The address is applied along with an active
low control signal, CE# . After the tACC, the
data will be available, and the Output Enable
(OE#) input will gate the data onto the bus.
This data will usually be the contents of the
addressed location, but it can also be status
information about a program or erase
operation. The current operating mode
selects what is placed on the bus in response
to a read.
BUS Write
Writing to a flash memory is identical
to writing to an SRAM or peripheral. The
address is applied and CE# is asserted
followed by the WE# signal. Prior to WE#
being de-asserted, the data must be applied to
the bi-directional data I/Os. The data written
can be commands, or the new memory
contents depending on the flash's operating
mode.
OPERATING MODES
Operating modes vary somewhat
between different manufacturers, and a
manufacturer can offer two devices with
different modes and commands to reflect
different architectures. This discussion will
use the modes supported by the 28F400B3, an
Intel Boot Block Flash memory.
These modes make use of the Write
State Machine (WSM). The WSM is a
controller that is built into each device. It
looks at all writes to the flash, decodes them
and implements the commands.
Read Array
The Read Array is the default mode.
The flash memory enters this mode upon
power-up. It stays in this mode until a valid
command is received that puts it in a different
mode. While in this mode, all read operations
return memory contents. This is exactly
what an EPROM does, and unless
commanded otherwise, the flash will act just
like an EPROM. Incidentally, disabling the
WE# input (tying it high) will prevent any
commands from being received, so the flash
will always be in the Read Array mode.
Since Read Array is the default mode,
the rest of the command sequences discussed
will assume that the flash is in Read Array.
Program
Writing the value 0x40 to the
memory will put it in the Program mode.
While in this mode, any bus reads may return
invalid data. The address and data included
in the next write cycle will be used to
program the array.
Figure 2 shows a flow chart of a
typical programming operation. For a typical
location there will be a minimum of 4 bus
transactions: Program Setup Command,
Program Command, Read Array Command
and Read Status Register.

Program
Write 0x40
to Flash
Write Address and
Data of location to
be programmed
Put Flash into
Read Status Mode
Read Status
no
Finished
Programming
? Both program and erase operations
Yes
Return
Figure 2
Upon receiving a valid program
sequence the WSM turns on the charge
pumps and programs the location. It does this
by internally applying program pulses until
the location verifies correctly. Once the
location is verified, it reflects this successful
operation in the status register. Failure of the
programming operation sets one or more error
flags. Once begun, all this happens without
the intervention of the external controller, and
for a typical location in a new device, takes
about 10 microseconds.
Most flash memories can only do one
thing at a time, so while a location is being
programmed or erased, the rest of the device
is unavailable. This means that a CPU cannot
execute code from a flash that is not in the
Read Array mode. Systems with other
execution memory locate the low-level flash
driver there. Those without typically copy a
driver to SRAM and run from it until the
flash is available.
Erase
Writing 0x20 to the flash begins the
Erase mode. If the next write has a data value
of 0xD0, then an erase operation will
commence. Any read operations done when
in the Erase mode may return invalid data or
status.
Once again, the entire erase operation
is automatic, and the result is posted to the
status register. This set of commands erases
an entire block or segment and takes a few
seconds. Clearly, the WSM off-loads a lot of
details from the CPU.
Read Status
post their results in the status register. When
the flash receives the data 0x70, it enters the
Read Status mode. In this mode, any read
operation returns the contents of the status
register.
PROTECTION
Flash devices incorporate some form
of protection. The concern is that if a
processor were operating in some erroneous
way, it could erroneously issue program or
erase commands to the flash memory. To
prevent this, a flash memory will usually
support some combination of two basic types
of protection schemes: hardware and
software.
A hardware scheme requires that
specific voltages be applied to pins on the
device before the device can be altered. The
voltages can be TTL logic levels or some
special voltage like 12v, and the pins can be
dedicated or shared with other functions. An
example of hardware protection is the VPP pin
on a flash memory; if no voltage is applied,
the device will not program or erase.
BYTE
ADDRESS
0x3FFFF
128 K B
M A IN S E G M E N T
C O D E or D A TA
0x20000
0x1FFFF
96 KB
M A IN S E G M E N T
C O D E or D A TA
0x8000
0x7FFF
8 K B D A TA or P A R A M E TE R
SEGM EN T
8 K B D A TA or P A R A M E TE R
0x4000 SEGM EN T
0x3FFF
16 KB BO O T SEG M EN T
0x0000
Figure 3
Software protection mandates that a
code sequence be written in order to initiate
an operation. Consider the erase command
in the preceding discussion. Two codes, 0x20
and 0xD0, were required in order to begin the
erase operation. The first can be considered a
command, but the second is clearly a code.
Some devices require code sequences that are
four or six bytes long.
SEGMENTATION
Current flash devices are blocked or
segmented. All the locations in a block share
common erase circuitry, so while only one
location can be programmed at a time, an
entire block or segment is erased at once. By
definition, a single location in a flash memory
cannot be erased without erasing the rest of
the block.
Normally, the boot code will be
located in one segment, the application code
placed in several other segments and some
non-volatile data stored in another. Figure 3
shows an address map of an Intel 28F200.
Its blocks are sized to fulfill these three
functions.
The boot code is in a separate block
so that data or application code can be erased
and reprogrammed without affecting the boot
program.
SUSPEND FEATURES
As will be seen in the next section,
program and erase operations can take
milliseconds or even seconds. There are
many instances where a system will need to
read data in one block while a different block
is being erased or programmed. Flash
memories implement a suspend command
that permits this.
When the WSM receives a suspend
command during an erase or program
operation, it saves the state of the operation
and enters a mode that allows the array to be
accessed. This is like the Read Array mode,
except that the WSM is running, so the
component may draw more a little more
current.
SUMMARY
Flash memories can be a complete
non-volatile memory subsystem. Current
devices implement all the pumps and control
electronics necessary to program or erase
them.
FLASH CELL TECHNOLOGY
Flash memories can do more than
store the firmware; they can store or log data.
Some understanding of how flash memories
store data will be useful in matching flash’s
programming characteristics to an
application.
Flash, EEPROM and EPROM all
store data the same way. Figure 4 shows a
simplified diagram of one of these cells. It is
a N-channel transistor with a second gate, the
Floating Gate, sandwiched between the
Control Gate, and the channel.

The Control Gate (CG) is connected
to other circuitry and works like a normal
gate would. When sufficient positive voltage
is applied to it, greater than the threshold
voltage, the transistor turns on, and a
conduction path will be established between
the Source and the Drain.
The Floating Gate(FG) modulates the
affect of the CG. If the Floating Gate has a
sufficient negative charge, it will prevent the
transistor from turning on when the normal
threshold voltage is applied to the Control
Gate.
OXIDE
CONTROL GATE
FLOATING GATE
SOURCE DRAIN
CHANNEL
Figure 4
READING A FLASH CELL
An unprogrammed cell has no
additional charge on the FG, and the
transistor turns on at its characteristic
threshold . When the same cell is
programmed, it has enough electrons in the
FG to prevent it from turning on when the
threshold voltage is applied. To read a cell,
the external circuitry applies the threshold
voltage to the CG and observes if the
transistor turns on.
While all architectures use similar
principles to store and read data, they do not
act the same from a system point of view.
NOR permits a single location—word or
byte—to be read in approximately 100ns.
NAND only reads blocks of 512
bytes. There is an initial latency of 10 µs
while the block is transferred out of the
memory array and into an on-chip SRAM
buffer. It can be transferred out of the buffer
at a rate of 20 Mbytes/s.
The type of reading supported by an
architecture determines if the memory can be
executed from. The former example supports
direct execution, or eXecution In Place (XIP),
the latter does not.
PROGRAMMING OR ERASING
These devices store data by injecting
electrons onto the Floating Gate. On today’s
devices, a cell is programmed when
approximately 50,000 excess electrons are in
the FG. They stay in the FG for 10 years or
more, because there is no conduction path to
the FG--the FG is completely isolated from
the rest of the transistor. The only way for
electrons to get into it is for them to be driven
through the oxide that surrounds the FG. The
cell is erased by removing the electrons.
Programming and erasing are
accomplished by applying elevated voltages,
10v to 20v, to the cell to cause electrons to
propagate through the oxide. This has three
consequences.
• It takes time to drive the current
through the oxide barrier, so program
and erase operations take much longer
than in an SRAM.
• The oxide barrier can “wear out” after
repeated program/erase cycles.
• Elevated voltages are required by the
cell
Program and Erase Performance
If the application will store data in a
flash memory, the amount of time it takes to
program or erase the device can be an
important specification. Also, flash
memories typically operate on blocks. To
accurately specify a device, it is necessary to
understand how long it takes for an operation
and how big a block the operation affects. An
operation that takes 1 second may seem slow,
but if it erases 128-Kbytes, the throughput is
128 Kbytes/sec.
Depending on the type of flash, it will
take between 5 µs and 1 second to program or
erase a cell. Cells are usually programmed or
erased in parallel, so that a slow operation is
done on a lot of cells at once. For example, a
NOR architecture device may program a
single byte in 5 µS and erase 64-Kbytes in 1
second
There are three aspects to consider
when choosing a flash memory that will be
used to store data and will be programmed in-
system.
• What rate does the application
require?
• What rate does the device support?
This can be the average time to
program and erase a byte
• How big of a buffer is necessary, if
any, to store in-coming data while the
flash is busy programming or erasing
the previous block.
Oxide Wear-Out
When electrons or holes propagate
through the oxide, some do not make it all the
way--they get trapped. When they do, they
alter behavior of, or wear out, the oxide.
A cell whose oxide has trapped
charge does not program or erase as fast as an
electrically neutral one. The trapped charges
repel the carriers that are trying to propagate
through it. For example, if a programming
mechanism drives electrons through the
oxide, then the oxide regions that sustain the
heaviest program current will gain a negative
charge. That negative charge repels electrons
and reduces the amount of current that flows
into the Floating Gate. The result is a slower
program or erase operation.
The typical times published in
datasheets are for a new cell. Since the
amount of performance degradation will vary
with the technology and vendor, it is
necessary to contact the vendor to estimate
what effect cycling will have on their devices.
In general though, the degradation is
gradual and occurs over tens of thousands of
program erase cycles.
Applying Elevated Voltages
The original flash memories required
that elevated voltages be applied for precise
times. New devices can generate and control
these voltages internally. It is worth
mentioning that the flash transistor requires
these elevated voltages, and if they are not
applied externally, they are generated on-chip
by voltage pumps.
Voltage pumps take up silicon and
add cost to the device. The more current the
pump can supply the more bits that can be
programmed at once. However, that higher
performance pump takes up more space
Typical flash memories strike a balance
between the two.
Several vendors have a separate pin
for a programming voltage, VPP. One benefit
of this is that a device may program quicker
when a higher voltage is applied to the pin.
This is because the device will sense the
higher voltage and modify the internal
algorithm to program more bits at once.
SUMMARY
The flash memory cell intrinsically
take time to program or erase. How much
time depends on the method used to for
carriers through insulating barriers. For a
given method, the rate can be increased by
operating on many bits in parallel. To choose
a flash memory, match the write/erase
characteristics of the memory to the
application.
COMMON FLASH INTERFACE
The Common Flash Interface (CFI) is
a new way to find out what kind of flash
memory is in a socket. It is designed to work
even with flash components that are designed
and produced after the system software has
been written.
JEDEC IDENTIFIERS
In the past, a flash memory or an
EPROM had a mode where a JEDEC
Identifier could be read from the device. This
was originally intended for, and used by,
EPROM programmers. When system
designers decided to make their flash sockets
accept different devices, they used these
identifiers, because they were the only way to
tell what program and erase algorithm to use.
This technique had two flaws: there
was no standard way to read the identifier,
and there was no way to anticipate what the
identifiers would be for future devices.
To read the identifier from an Intel
device, the system must first write 0x90 to it,
then read the identifier from locations
0x00001 and 0x00002. To accomplish the
same thing with a device from another
vendor, the system must write 0x55 to
location 0x0000, followed by 0xAA to
location 0x0000. The identifier can then be
read from locations 0x0000 and 0x0001.
To find out what kind of memory is
in the socket, the program attempts to read an
identifier using one algorithm, and if it fails
to return the expected result, it tries a
different one. This is workable but not
optimal.
The second issue is that the identifier
must, by definition, be unique. When a new
device is introduced, it will have a new,
unique identifier, so all software written prior
to the release will reject the new device. This
is unnecessary, because most manufacturers
make new devices compatible with their
previous ones.
COMMON FLASH INTERFACE
The Common Flash Interface solves
this problem by providing a standard way for
a system to interrogate a flash memory, and it
defines the format for the information. The
information is descriptive. Embedded in the
component is a trimmed-down datasheet that
contains enough information for the system to
program or erase the flash memory, even if
the component was designed after the system
firmware was frozen in ROM.
CFI ACCESS
A flash memory will enter into the
CFI data mode when a value of 0x98 is
written to location 0x00055. From then on,
all read cycles will return data from the CFI
ROM instead of the flash array. Figure 5
shows how this works.
CFI DATA
The ROM is separated into two areas,
data that applies to all devices and data that is
specific to one vendor. The generic area has
a predetermined format. Each location stores
a specific parameter using a standard
encoding.
For example, the minimum VCC is
stored in location 0x1B of the CFI ROM. It is
in BCD with a decimal point between the two
nybbles. Other information like access time,
block architecture, typical program and erase
times and VPP are also stored in this area.
The format and encoding are listed in
the “Common Flash Memory Interface
Specification”. This specification was uses the Intel basic algorithm—algorithm
recently adopted by JEDEC and should number 3.
appear on their website soon. Check
www.eia.org/jedec/. There is also a mechanism to support
minor variations of the same algorithm.
These details are located in the vendor
specific area.
CFI
ROM SUMMARY
FLASH INTERFACE

FLASH
ARRAY
The Common Flash Interface allows
a single software driver to work with a variety
of flash components from different
manufacturers.
CFI COMPLIANT FLASH
MULTI-LEVEL CELL

The CFI data is stored in a separate ROM
located on-chip. The memory locations in the
ROM do not detract from the size of the array.
This illustration shows a 2 Mbit device that
supports CFI. It has a 2 Mbit Flash array and a
ROM with about 50 locations. When 0x98 is
written to 0x0005, the interface is switched
over to the ROM. To access the Flash again,
write 0xFF to location 0x0005.
Multi-Level Cell (MLC) technology
stores two bits in a single flash memory
transistor, twice the density of existing
devices that store one bit. An MLC flash
memory with
Charge on the Floating Gate

00
Figure 5
0
01
PROGRAMMING ALGORITHMS

One location in the generic area 10

contains a number that identifies what 1
programming algorithm the device supports. 11
If two devices have the same algorithm, they
will have the same number in the algorithm Coding for Coding for
location. Existing MLC
Devices Devices
Notice the difference between CFI
data and the JEDEC ID. The JEDEC ID was
Figure 6
unique for each device. Since CFI data is
descriptive, two devices with identical 16 million transistors can store 32
programming algorithms will have the same million bits. This is not a mode that can be
number in the algorithm location. invoked in any device; the flash memory
must have been designed to do this.
The table that lists what numbers go
with what algorithms is in a separate Current devices store data by varying
document, “CFI Publication 100”. Each flash the amount of charge on a Floating Gate. If
vendor will have a few numbers that the gate is neutral, the cell is erased and
correspond to their unique programming contains a 1. If charged, the cell is
algorithms. For example, the boot block programmed and contains a 0. These
device described in the introductory section
components implement two charge levels per
cell.
MLC devices also vary the gate
charge, but more precisely. They use four
levels; each level represents one of four states
or two bits. Figure 6 illustrates the
difference between MLC flash memories and
standard ones.
USING MLC FLASH MEMORIES
MLC devices have the same interface
as regular flash memories. The Write State
Machine does all the work and improved
sense circuitry distinguishes between the four
levels to produce the read data. MLC devices
behave the same as standard devices because
the details are handled on-chip.
SUMMARY
For a given array size and
lithography, MLC technology can double the
amount of data the array can store. MLC
components in chip-sized packages offer
unprecedented capacity in a small area. One
new MLC device can store 64Mbits in a
package that is less than half the size of a
postage stamp.
FLASH TECHNIQUES
This section discusses ways to add
functionality to a product without adding
substantial cost
In most systems, the first job of a
flash memory is to store the firmware, so the
processor boots directly from the flash. The
first technique describes how to program this
boot code in-systems, hence improving the
manufacturing flow. This section also
includes a few pointers on programming the
rest of the code.
This paper began with the idea that
flash could do more than store firmware; it
can also store data. The kind of data, and
hence the specifics of storing it in flash, will
vary between applications. There is one kind
of data that is useful in almost all systems:
data that helps an engineer diagnose field
failures or problems. A brief discussion of
what to save and how to save it is included.
Few systems operate completely
independently. Most exchange code or data
with other computers throughout their
lifetime. One way of doing this is with
removable flash memory cards, and the
industry standard card form factor is
PCMCIA. The final section discusses how to
add a PCMCIA socket to an embedded
system.
PROGRAMMING BOOT CODE IN-
SYSTEM
The boot code resides at the CPU's
reset address and performs critical functions
to start the system. These functions can be as
simple as initializing a few interrupt vectors
prior to branching to resident applications
code, or it can involve something more
complex like loading the application code
from a disk prior to branching. In a system
with flash memory, this boot code may also
contain the necessary code for in-system
application program updates.
A system cannot program its own
boot code, because the boot code is necessary
for the CPU to operate. Therefore, a typical
production flow involves programming the
boot code into the flash memory prior to
soldering it to the PCB. A better way would
be to solder blank components to the PCB
and program the boot code in-system. There
are several advantages to doing this: reduced
component handling, reduced inventory and
improved responsiveness.
There are two mutually exclusive
trends in flash packaging: the size is
decreasing and the lead count is increasing.
The only way to satisfy both is to decrease the
lead pitch. An example of this is the TSOP
(Thin Small Outline Package) package; it has
a 0.5 mm lead pitch. As components shrink,
they become more difficult to handle reliably,
and a programming step introduces
opportunity for lead damage. New chip-sized
packages make a programming operation
even more difficult.
Programming and handling
equipment is expensive, so many companies
elect to have a third party do their flash
programming. This adds lead-time to the
production process, and if different products
have different boot codes, the added lead-
time will mean increased inventory. This
inventory makes it difficult to respond to
unexpected events such as emergency orders
When a flash memory is
programmed, it becomes more application
specific, and therefore, less flexible. The best
approach is to postpone the programming
until it is necessary, and allow the capability
to change the programming. In-system
programming of boot code achieves both of
these goals.
TECHNIQUES
The basic strategy for including this
capability in a system is opportunistic--one
looks at what one has to work with, then
chooses the tactic that minimizes system cost
and manufacturing infrastructure penalties.
Most of these techniques will fall into two
main categories: those that make use of the
CPU or interface logic to operate on the flash,
and those that simply isolate the flash from
everything else, so it can be manipulated.
JTAG BOUNDARY SCAN
If the CPU chip includes a JTAG
interface, that interface can be used to
manipulate the CPU's pins and hence the bus.
JTAG is a standard interface and
protocol consisting of a 4 or 5 signals that can
shift commands and data into a device. The
basic protocol is to shift in a command which
will usually be 4 to 8 bits long, then shift in
the data for the command. The JTAG
interface is static, so there is no maximum
time between bits or edges.
All JTAG implementations will have
the capability to do boundary scan. The
boundary scan register is a shift register that
is connected to all the I/O pins in the device.
The state of all input pins can be latched into
this register then shifted out, or the levels to
be output can be shifted in, then driven onto
the pins. All this can be done with the CPU
in a suspended state.
The result of this is that bus cycles,
albeit slow ones, can be generated by shifting
in the correct levels for address, control and
data pins; driving them onto the bus; latching
any inputs and shifting them out. The entire
boundary scan register must be shifted in or
out to write or read a pin, but more than one
pin can be read or written in a single shift
operation.
For a more complete discussion of
this technique, refer to "Designing for On-
Board Programming Using the IEEE 1149.1
(JTAG) Access Port ", Intel Application Note
AP-630 . It is available from
www.intel.com/design/flcomp/applnots
and includes sources for
commercially available JTAG programmers
CPU DEBUG INTERFACE
Many CPUs have a debug interface.
This usually takes the form of a proprietary
serial interface and protocol that can access
internal CPU registers and the bus. Although
included on the same chip, this capability is
totally separate from the CPU, so the CPU
need not be running in order for this to work.
The commands that are useful for
programming flash are ones that simply read
and write memory; they are used to write
commands to and read status from the flash.
 Contact the CPU vendor for
information on the debug interface and any

'373 LATCHES
tools that support it.

ADDRESS
TAPPING INTO THE INTERFACE LOGIC

FLASH MEMORY
If the CPU does not support a back
door into the bus, perhaps the interface logic

LOGIC / PLD
CE#

CONTROL
will. Figure 7 shows a block diagram of a OE#

CPU
typical system. There are latches and drivers WE#
for the address lines; there is some logic to
generate and drive control signals, and
buffers on the data bus. Some systems

'245 XCEIVERS
DATA BUS
incorporate this into a single PLD, others use
octal devices and no logic.

This technique involves modifying

this interface logic to implement an additional
interface to the flash. This back door allows
address, control and data to be applied to the Figure 7
flash while CPU operation is suspended. The
alternative path can take many forms. The
The easiest system to modify is one
most obvious is to multiplex the
that already has the interface logic in a single
programming inputs with the CPU signals
PLD. All that is necessary is to modify the
and apply the output of the multiplexer to the
logic equations or schematics for the PLD to
flash inputs. However, multiplexing so many
enhance the address latches to allow shifting
signals adds a lot of extra logic and pins to
in addresses. The PLD can then latch address
typical PLD.
from the CPU or shift in an address from an
external pin.
The creation of a serial I/O port,
especially for the wider buses like the address
The control logic could be similarly
bus, saves pins and logic. The data to create
modified, but since there are only three inputs
bus cycles could be shifted in or out serially
(OE#, WE# and CE#), and since they change
as was done with previous examples, but this
more often than the data or address inputs,
time, the designer is creating his own shift
there is a performance benefit to simply
registers that drive the memory. These shift
multiplexing them with the CPUs control
registers can accept parallel data, address and
outputs. Once again, the SHIFT_LATCH#
control from the CPU as before, but in
signal can be used to decide which inputs
addition, this information can be shifted in
drive the flash control inputs.
from a programming connector. The CPU
could be held in reset while the flash is being
The only remaining signal group is
programmed.
the flash/CPU data bus. If it is already latched
and driven in the PLD, then the same shift
register technique can be used as was done
with the address bus.
For the single PLD system, the
impact will be the addition of perhaps 8 I/O
pins to the PLD, some additional product
terms in the logic, and the cost of a
programming connector. It is difficult to
estimate the additional system cost, because it
depends on how fully the PLD is being
utilized. Perhaps this technique could be used
only if the PLD has spare resources. Of
course, if the interface logic is incorporated in
an ASIC, the cost impact will probably be
lower.
ISOLATING THE FLASH
If there is no JTAG or debug
interface on the CPU, and if there is little or
no interface logic to modify, then a third
approach is to get the CPU completely off the
bus so it will not interfere with the
programming operation.
Many CPUs support some
mechanism that relinquishes the bus. This
could be a HOLD/HOLD_ACK protocol, or a
test mode such as ONCE (ON Circuit
Emulation). Either mode could be invoked
by signals that are applied by the
programming connector. When the
programming controller is not connected,
these signals could be weakly deasserted.
Once the CPU is not driving the
memory bus, the programming controller can
take over, and do reads and writes to the
flash. Since it is a parallel interface, it can be
the highest performance method for
programming the boot code. The bus
operations should be slowed down to prevent
noise and ringing, but even so a location
could be programmed in 30 microseconds.
All 8K locations could be programmed in .25
seconds. This is well within the requirements
for high volume manufacturing.
In this technique, all the pins of the
flash must be manipulated by an external
programmer. The best way to do this is as the
last step in testing a board on a bed-of-nails
tester. See AP-629, “Simplify
Manufacturing by Using Automatic-Test-
Equipment for On-Board Programming” at
www.intel.com/design/flcomp/applnots for
more information on this topic.
PROGRAMMING THE APPLICATION
CODE
Once the boot program is installed,
the applications programs can be loaded in.
Some manufacturing flows involve
programming the flash with test and
calibration routines first, then when they are
no longer needed, the application code is
loaded in.
There are two functions that must be
included in a system in order for a CPU to
program its own application code. There
must some means of inputting the new
program: a serial port or a floppy disk are two
good examples. Almost all systems have
some way if inputting data.
Second, there must be some
alternative execution memory that the CPU
can execute from while the flash is being
programmed. Recall that while the WSM is
programming the flash, any reads will return
invalid information, and when it is in the
Read Status Mode, any reads will return
status. Since the flash memory array, and
hence the program, is not available, the CPU
must run out of some other memory. One of
the most common solutions to this is to have
the CPU copy a small routine into SRAM,
then run from it while the flash is
programming.
USING FLASH MEMORY TO
DIAGNOSE SYSTEM BUGS
Regardless how skillfully designed
and implemented a product is, when the first
units leave the factory, they are destined to do
things the designers never anticipated.
Finding and correcting these bugs can take an
inordinate amount of time, because
information about the problem is usually
sketchy and inaccurate.
 An inexpensive way to improve the
de-bug process is to have a product store
information about what it was doing when a
bug occurred. A system that uses flash
memory for program storage has an excellent
media to permanently store information that
will be useful to the engineer diagnosing the
problem.
Much of the information that would
significantly improve the debugging process
was processed by the system’s CPU. If the
CPU saved the complete state of the system
whenever a failure occurred, then anyone
trying to find a bug would have a head start
on finding the cause.
This information will be particularly
useful if the failure is intermittent. Failure
are intermittent normally because they do not
occur unless a number of factors are present.
The factors may not be readily observable, so
two apparently identical sets of inputs or
circumstances have different outcomes.
If a software update is all that is
needed to fix the problem, the new program
can be downloaded into the flash memory.
This whole process--reading then updating
the flash--can be done remotely via MODEM.
HARDWARE IMPLEMENTATION
The first step in implementing this
log is selecting the right type of flash
memory. The right flash has a range of
densities, is segmented and requires minimal
software overhead to write.
One of the more common types of
flash used for embedded control is the Boot
Block architecture. There are currently three
densities available--2, 4 and 8 megabit--from
at least three different manufacturers. If the
existing flash memory has a couple of spare
blocks, then the log will cost nothing to
implement. If the application currently uses
the entire memory to store the control code,
consider upgrading to the next density to
make room for the log.
If the application is cost-sensitive,
incorporate this feature only in the field test
or pre-production units. When the product
has matured and all of the bugs are all out,
eliminate the extra memory and use a smaller,
less expensive density. To allow for this,
pick a flash from a product line that has a
range of densities in the same footprint.
Choose a flash memory that is
blocked allows one area of the flash to be
erased without affecting the rest of the device.
This is important because the processors code
may be in the same device as the log.
Blocked memories also have automated write
and erase capabilities.
Most flash memories cannot do two
things at once. The can be read, but not while
they are being programmed. They can be
programmed, but not while they are being
erased. As a result, the CPU cannot execute
from the flash while it is being programmed,
so there must be some alternate execution
memory, like code RAM or ROM, while the
log is being written into the flash.
USE SPARE INPUTS AND OUTPUTS
Most of the information going into
the log will come from data already available
to the CPU, but there are some useful
measurements that are not normally required
for a system to operate. A few examples are
battery or line voltages, ambient temperature,
operation of peripheral devices and the
presence of cables. The key to capturing
these is to opportunistically use spare inputs
and outputs--especially spare A/D inputs. For
example, a thermistor connected to a spare
A/D input costs a few cents, and measure
internal temperature
Spare digital inputs are also useful. If
the product requires peripheral devices that
provide a hardware status output, use these
inputs to monitor them.
Ideally, when the hardware design is
finished, all spare inputs should be connected
to something that will help the engineer
trying to find a problem.
INCLUDING A COMMUNICATIONS
CAPABILITY
If the product does not have a spare
serial port, make one out of an extra digital
input, output and software driver. When this
software Universal Asynchronous Receiver-
Transmitter (UART) is operating, the rest of
the system can be idle, so the full attention of
the CPU can be given to driving the UART.
This allows the baud rate to be higher and
makes it easier to write the driver. Connect
an external MODEM to remotely access the
log.
This is an important capability,
therefore it is worthwhile to make sure there
is provision for it. If there are no spare I/Os,
consider borrowing them from some other
function. The easiest way to do this is with a
special MODEM cable. One end mates with
a proprietary connector on the system, and
connects to an input and output. These two
signals and the connector would normally be
doing some other function. Because the
system need not operate while the error log is
being sent, the normal function will not be
missed. The other end of the cable mates
with a MODEM. Use software to redefine
the two signals that are being commandeered
for communications.
SOFTWARE IMPLEMENTATION
They most straightforward way to
save the information is using a fixed-length
record big enough to store the state of the
device. Each time an error occurs, the CPU
will accumulate all the data and write it to the
currently available segment in the flash. This
approach saves the same data in the same
format regardless of the source of the error.
Implementation is simple because there can
be a single routine that writes the data. When
it is time to read the data, a single program
can be written to convert the information into
a human-readable form.
There is no significant penalty for
saving data that may not be needed. In fact, it
is a preferred approach because it is difficult
to foresee what the bugs will be. Writing
everything about the system improves the
probability that some key piece of
information will be in the log when it is
needed. For a small system, this record can
be 2K to 4Kbytes. That is a fraction of the
32K to 128KByte flash segment, so data on a
lot of errors can be saved.
This size record can be written
quickly. A useful rule of thumb with flash
memories is that it takes 10 µsec to write one
location. The CPU can write a 4kbyte record
in about 40 msec.
WHAT TO SAVE
When an error is detected either by
the software or the CPU hardware, the
program will invoke an error handler that will
update the log. It will draw upon two main
sources of information: exception
measurements and the current memory
contents.
Exception measure are those made
only because an error occurred. They include
all A/D channels, digital inputs and outputs,
the data and status registers of all peripheral
chips or subassemblies--in short, any and all
information available about the physical
environment. Make sure that this set does not
overwrite any measurement results currently
in memory. If the current set were corrupted
or faulty, a second set will illustrate that.
The memory and CPU contents will
give a good indication of what the CPU was
doing when the error occurred. This
information includes the contents of the stack;
the CPU registers, including all control
registers; all process measurements, set-
points and variables; the presence of cables;
calibration parameters and so forth. Most
embedded control application operate in a
well-defined loop. Every sample-period, the
CPU performs measurements, calculations
and makes decisions. Save one, or maybe
two, sample-period’s worth of this data.
KEEP AN OPERATIONAL LOG
An operational log should be kept in
RAM then transferred to flash when an error
occurs. This is a RAM-based history of
events such as operator keystrokes, time-
stamped indications of when motors, etc.
were turned on or off, hourly ambient
temperature readings, and if space is available
a short, hourly snapshot of the process. Other
items to include in the operational log are the
beginning and results of special modes like
calibrations, receipt of data via a serial port
and charging a battery.
The operational log should answer all
questions about how the product is being used
and whether the problems are caused by the
operator. It should also help diagnosing
interactions between different peripherals.
For example, if turning on a motor causes
erroneous measures due to noise or poor
grounding, then the operational log will help
show that. It will have entries showing that
the motor was turned on just before the error
occurred.
RETRIEVING THE LOG
The retrieval program is fairly basic.
Once invoked, it sets up a MODEM and
sends the contents of the flash out the serial
port. The ideal device to receive this data is a
PC. Once copied into a file, it can be
forwarded to other engineers and recalled for
analysis.
The program to analyze the
information need only scale each data item
into the correct units, degrees Celsius for
example, and convert it to some human
readable form. The C programming language
has excellent support for this.
FIXING THE PROBLEM
Once a problem has been diagnosed,
it is probable that a software revision will be
forthcoming to fix, or at least bandage, the
problem. Send the new program to the
product via the same MODEM and
communications port that was used to retrieve
the error log. The system can re-program the
firmware in the flash.
This does two things: it gets the
customer back on line in the quickest possible
time, but more importantly, it tests the
solution at installations where the problem
has actually occurred.
Finally it may turn out that some key
data items were left out of the error log
routine, or maybe some very specialized tests
need to be performed to further isolate the
problem. In that case, the new program may
be a temporary one that only gathers more
specific information about the failure.
SUMMARY
Creating an error log in flash memory
will substantially improve the debug process,
and if implemented early in the development
of a product will not materially affect cost or
design time.
ADDING REMOVABLE MEDIA TO
EMBEDDED APPLICATIONS
Another common system requirement
is the capability to interchange data or code
with other systems. At a high level, there are
two ways to do this: store the data in internal
memory, and use some means to send it to
another system, or store the data in some
removable media and swap the media
between systems. In either case, flash
memory's low cost per bit and permanent
non-volatile data retention make it a good
choice
BENEFITS
The industry standard for removable
flash is the PC Card form factor; it is widely
supported both in terms of flash cards and
systems that accept PC Cards. There are a
few benefits to using flash memory PC Cards.
By far, the biggest one is flexibility. The
amount of memory available for data
interchange can be changed simply by using a
different card. In fact, if the low-end model
of a product does not support data interchange
at all, then there will be almost no added cost
to that system.
Another way flash memory PC cards
add flexibility is that the system can actually
execute code directly from them. Linear flash
cards operate exactly like components, so not
only can the amount of memory available
change, but the driver that writes the data can
change too.
If only a single type of card is
supported by a PC Card socket, then the
hardware and software for that socket will be
simple and inexpensive—well within the
resource budget of a typical embedded
designer
ADDING A PC CARD SOCKET
The goal of the PC Card specification
is that a PC Card can be inserted into a
system, the correct driver invoked, and the
card will function properly. Designing the
PC Cards and host systems that accomplish
this is not trivial; they must thoroughly and
completely adhere to the PC Card Standard.
The designer of an embedded system
has a much easier job. The embedded system
need only work with a predetermined set of
cards. It may or may not support hot-
swapping, and in general, it will not comply
with all of the PC Card Standard. It need
only comply with those sections—mainly
hardware ones—that ensure the socket will
work reliably with a few, predetermined
cards. Prior to designing the socket, the
system architect should select a few specific
cards, and use those cards' datasheets to
specify the host implementation
The balance of this section will
introduce the main features of PC Cards.
Specific details will be left for the PC Card
Standard or product datasheets
Linear Flash Card Architecture
A linear flash PC Card looks like a
memory component. Each location is
accessed uniquely by the address presented to
the card. Since it looks like memory to the
host CPU, the CPU can execute directly from
it.
Figure 8 shows a block diagram of a
linear flash PC Card. In this card, the
memory is implemented using four flash
memory components. They are accessed in
pairs, one component provides the high byte,
the other the low. This organization is the
same as would be used if the components
were being connected directly to a 16 bit
microprocessor.
Flash Flash
Component Component
Attribute
PC Card Interface Logic Memory
and buffers ROM
PC Card Socket
Figure 8
 The interface logic implements the probably require buffers on either
somewhat complex byte swapping required in end, solid GND and VCC connections.
the PC Card Standard. If byte swapping were
not implemented, the memory components • The socket may need to permit the
could be connected directly to the interface or user’s inserting or removing cards
through simple, octal buffers. while the system in powered up and
running (hot-swapping).
ATTRIBUTE MEMORY
• The user can insert any PC Card into
The PC Card Standard defines two the socket, so the system should be
kinds of memory, common and attribute. able to supply enough current for a
Common memory is available to the host to PC Card that draws the maximum
read and write programs and data. On a flash load, 1 Ampere.
PC Card, the common memory is made up of
flash components. Resolving these issues adds cost and
complexity to a product, so the decision to
Attribute memory is primarily used to permit user access should be given
store information about the card. In a general appropriate consideration.
purpose socket, any kind of card can be
inserted, and the host must be able to link it to
the correct driver. The first accesses a host
makes to a card are to the card’s attribute
memory. That is how it finds out what kind
of card has been inserted. This information,
called the Card Information Structure (CIS)
must be included in every card and must be in
a predetermined format

MECHANICAL OVERVIEW
Figure 9
A Type I PC Card is 3.3 mm thick, 54
Designing a socket with restricted
mm wide and 85.6 mm long. It uses a
access is easier and less expensive. A socket
polarized, 68 pin connector. The host socket
without an eject mechanism, like the one in
has male contacts; the card has female
Figure 9, can be mounted inside the system,
contacts.
and some or all of the electrical issues are
eliminated.
Selecting a PC Card Socket
• No cabling will be necessary because
If inserting and/or removing the card
the socket can be mounted in a
will be part of the system’s normal operation,
location that is convenient for the
then the user must have ready access to the
designer—on the host PCB.
socket. User accessibility raises several
electrical issues.
• Hot-swapping can be implemented
only if the designer chooses.
• Since the socket and hence the
interface will be located near the
products cabinet, cabling may be • Inserting the wrong kind of card is
required to connect the PC Card less likely if a cover or access plate
socket to the host PCB. It will must be removed to get to the socket.
Voltage Keying

PC Card socket are polarized to
prevent a card from being inserted upside-
down. They are also keyed to prevent
mismatch between the card’s VCC requirement
and the host’s capability. There are two keys,
5 volt and low volt; they are illustrated in
Figure 10. Besides keying, there are signals
from the card to tell the host what the VCC
requirements of the PC card are. Today, most
flash PC Cards support 5v operation.
5v Keyed Card
Low volt Keyed
Card
A 5v card will fit in a Low volt socket, but
not vice versa
Figure 10
ELECTRICAL OVERVIEW
It is not surprising that the PC Card
interface looks like the interface of a memory
component; it began as a memory card
interface. The memory access signals are
similar to memory components and will not
be discussed here. Refer to product datasheets
for signal timings and definitions.
There are signals that are unique to
PCMCIA cards and bear mentioning.
CARD SENSING AND CONTROL
The card control signals are usually
read prior to applying power to an unknown
card. The amount of effort required to
correctly implement card control depends on
how many types of cards will be supported by
the socket.
Card Detect
These two card outputs are connected
to ground on the card. They have shorter pins
in the host connector than the other signals,
so they make contact after all the others.
They are located at opposite ends of the
connector. When the socket sees both CD1#
and CD2# asserted, it is safe to assume the
other signals are connected, and the card is
installed.
Voltage Sense
The two voltage sense outputs, VS1#
and VS2#, tell the socket what VCC the card
requires. They are either grounded on the
card or left open. Why have both voltage
keys and voltage sense signals? Because the
multi-voltage capability was introduced in
1995, and there are quite a few older
implementations that do not look at the VS#
outputs. A card with a low volt key will not
fit in an older, 5v socket.
Implementing a 5v-only, 5v-keyed
socket is a viable option for an embedded
design. The designer can select and qualify
only 5v cards, and the power supply need
only support 5v.
Table 1
VS1# VS2# Card VCC
OPEN OPEN 5v
GND OPEN 3.3 v
While a large majority of flash PC
Cards are 5v , and this will probably be the
case for a long time, if a design has an
unusually long expected life, it may be
worthwhile to implement a low volt socket
that can power a card at 3.3v or 5v. Besides
complicating the power supply, this decision
also mandates special interface logic.
If the socket supports low voltage
cards then the VS# input should be
interpreted per Table 1.
 Finally, there is a third, as yet
undefined, voltage that is lower than 3.3v.
The specifications call it “X.Xv”. VS2# is
used to signal a card’s compatibility with
X.Xv.
Write Protect
Some flash PC Cards have a write-
protect switch that protects the contents from
inadvertent modification. The WP signal is
an output of the card and reflects the state of
this switch. Note that the system software
can elect to ignore the state of the WP switch,
because a PC Card may still support write
cycles to the memory.
Reset
The RESET input provides a means
of putting the card into a known state. Some
memory cards use RESET to terminate any
erase or program operations in progress and
return the card to the read mode.
If a system boots directly from the PC
Card memory, then the socket RESET should
be asserted along with the CPU’s reset. This
guarantees that the memory array in the card
will be available when the CPU is accessing
its boot code. It is also important that the
card supports this RESET functionality.
Attribute Memory Read
As was mention previously, all PC
Cards must include information (the CIS)
about the card. If the card does not use non-
volatile memory as part of its intended
function, then enough ROM, EPROM or flash
must be added to store a CIS. If the card
stores the CIS in attribute memory, then
special read cycles are required to access it.
Attribute memory read cycles are the
same as normal reads, except the REG#
signal is asserted along with the CE1#.
SUMMARY
A PC Card memory access is similar
to typical microprocessor memory cycles.
When designing the interface, there are two
sources for exact timing information: the
latest PC Card Standard and vendor
datasheets. The implementation should
conform to both sets of specifications.
INTERFACING THE SOCKET TO THE
HOST BUS
The complexity of the electrical
interface to the socket will be determined by
the usage model
HOT SWAPPING
If a card will be removed or inserted
while the system is operating, then the socket
should be designed to accommodate hot
swapping. There are three main issues with
this. Supplying the correct VCC to the card,
protecting the host CPU from being disturbed
by the sudden changes to the socket, and
making sure the card is properly reset.
If the socket has a 5v key, only 5v
cards will fit in the socket, so there is no
doubt about what will be applied to the card.
Consequently, the socket can be left powered
all the time, and the different lengths of
power and signal pins can be relied on to
apply VCC before any signals are driven.
However, PC cards can have as much as 150
µF of capacitance between VCC and Ground,
so some means of limiting the inrush current
may be necessary. Check with the flash PC
Card vendor about how much decoupling
capacitance is used on their cards; there will
probably be less than 2 µF.
Implementing a low volt socket
requires that the VS# inputs must be sensed
and the correct VCC applied after the card has
been inserted.
 key and is compatible with cards from a
VS#s, CD#s, WP variety of vendors.

To unused PC CARD SOCKET CONTROLLERS

port pins
PC Card Interface Controllers

2 74HCT245
(PCICs) are single-chip controllers that
D0-D15 handle all of the signals in a PC Card socket.
In addition to buffering the address, data and

PC Card Socket
Host CPU Memory Bus

control signals, they also allow complete

addressing flexibility.

They are the standard interface

component in PCs because they allow the PC
3 74HCT573

A0-A24 Card's addresses, I/O or memory, to be

programmed by the driver or OS. They are a
Buffer Control

good choice for systems that will use standard

operating systems, because off-the-shelf PC
Card software assumes that the card is
connected via one of these controllers.
CE#s, OE#
A25+ WE#, REG# The most popular architecture is
PLD

RD# register-compatible with the Intel 82365SL

WR# OC
PC CARD HARDWARE ARCHITECURE
RESET
Figure 8 showed a card that buffered
Figure 11 the memory components, supported byte-
swapping, and stored the attribute memory in
a separate ROM. It conformed completely to
The RESET signal requires special
the PC Card Standard.
attention--it must be in a high-impedance
state while a card is being inserted. The PC
There are linear flash PC Cards that
Card Standard mandates that RESET be
are designed specially for embedded systems.
pulled up to VCC on the card using a 100KW
They eliminate functionality not normally
resistor. During a hot insertion, as soon as
required and as a result, reduce the cost of the
the card makes contact with VCC, the RESET
card.
input will be asserted via the resistor. Later,
when the RESET pin makes contact with the
socket, the hi-Z state of the host contact will
not interfere with the pull-up. FLASH FLASH
MEMORY MEMORY
INTERFACE EXAMPLE COMPONENT COMPONENT

Figure 11 shows one implementation

of a PC Card interface. Both the Data and
PC CARD CONNECTOR
Address signals are buffered, and the Control
signals are generated using a Programmable
Logic Device (PLD). The socket has a 5v Figure 12
 Figure 12 shows the block diagram of
such a card. Notice that both the interface
logic and attribute memory have been
eliminated; this card does not implement
byte-swapping, and it stores the CIS in the
flash components. All of the functionality of
the card is implemented in the flash
components. These simplifications lower the
cost of the card, especially low density ones.
The CIS is stored in the lowest block
at the bottom of the address space. The
system designer has the option of preserving
the CIS or erasing it and freeing up additional
memory. Since the CIS occupies a small
fraction of a block, considerable memory can
be freed up if the CIS is discarded. However,
a PC card without a CIS may not be
recognized in standard systems. Therefore, it
is a good idea to preserve the CIS.
The cost savings of these cards will
become more pronounced as memory
densities increase. As the memory cost
declines, the cost of interface components and
attribute ROM will be a more significant part
of the cost of the card.
TUPLE IDENTIFIER The first byte is the
tuple name. It
identifies the type
of data stored in
the tuple.
LINK BYTE The second byte is
the length. It tells
the system how
many byte to skip
to get to the next
tuple.
BODY The rest of the
tuple is the data.
Figure 13
PC CARD SOFTWARE ARCHITECTURE
The CIS contains information about a
PC Card using structures called tuples.
Figure 13 shows the general format for a
tuple. The size varies with the type of tuple
and the complexity of the card.
The type of information stored is the
card’s VCC requirements, access time,
density, manufacturer name and JEDEC ID.
If an embedded system will support more
than one card, the software has the option to
read the tuples on a card to find out which
card has been inserted in the socket.
Another option is for the system to
read the JEDEC identifiers of the components
on the card. The biggest benefit of this
approach is that there are fewer flash
component manufacturers than there are card
manufacturers. The CIS will be different for
each vendor’s card, so the system software
will be more likely to change when a new
card is qualified.
Relying on component identifiers
means that if two cards use the same flash
components, then the same host software will
work with either card—even if the cards were
made by different vendors.
SOFTWARE OVERVIEW
There are a number of choices for PC
Card software. They can be divided into two
categories: special and general purpose
SPECIAL PURPOSE
Since the flash memory on a linear
flash PC Card interfaces directly to the
embedded system, the system can write
anything it wants to the card in any format.
Will this data be useable by a general purpose
system like a personal computer? The answer
depends on what card and what general
purpose system.
 Several flash PC Card vendors offer
utilities that read and write to their cards
using general purpose systems. One example
is Intel. They offer a utility call FLSH2F
that transfers binary files between a disk and
an Intel PC Card on any standard x86 PC with
a PC Card socket. It bypasses the PC Card
software stack and operates directly on the
card. It does not require a CIS but
interrogates the memory components on the
card to determine the cards size and
architecture.
The reverse is performed by F2FLSH. It
transfers a binary file on a x86 PC to a PC
Card and is especially useful for
programming executable code on the card.
beyond the scope of this document (see
Beatty, Kipisz and Moore).
However, it is possible to write data to a card
in an embedded system in such a way as to be
readable by any application in a general
purpose PC Card socket. This approach
writes the data using the standard format for
flash PC Card, the Flash Translation Layer
(FTL) See AP-619 "FTL Logger -
Exchanging Data with FTL Systems" at
www.intel.com/design/flcard/applnots/, and "
Understanding the Flash Translation Layer
(FTL) Specification" at
www.intel.com/design/flcard/technote/
CONCLUSION

An embedded system can write data to the
card in a way that is convenient for it. The
flash-to-File utility will transfer the contents
of the card verbatim to a file on disk. A
special application on the PC that uses the
data can read it off the disk.
Flash memory, both in card and
component form, add flexibility to the
manufacturing process and benefits to the end
user. All with adding little or no cost.

This solution is not general purpose for two

reasons: the embedded system will only work
with a few linear flash PC Cards, and once
written, the flash PC Card is only readable by
special applications on certain systems.
These restrictions may not present a problem
for embedded systems, but some systems
require a more general purpose
implementation.

GENERAL PURPOSE

There are a couple of ways an implementation

can be general purpose: it can work with any
PC Card that adheres to the PC Card
Standard, or if it only works with certain flash
PC Card, it can write the data in such a way
as to be useable by any application on a PC.

The PC Card socket on a notebook PC is an

example of the former; it works with any PC
Card that complies with the PC Card
standard. A discussion of this architecture is
 REFERENCES AND RESOURCES
The PCMCIA Software Developer's Handbook, Beatty, Dana Steven Kipisz and Brian Moore
available from PCMCIA

The PCMCIA Developer's Guide Second Edition, Mori, Michael and W. Welder
available from PCMCIA

The PC Card Standard, PCMCIA, 2635 N. First St., Suit 209, San Jose, CA 95134 (408) 433 2273

SOFTWARE

F2FLSH AND FLSH2F, File to PC Card transfer utility for PC Cards that use Intel components
http://cove.intel.com/template/design/tpvtool/list.cfm?architecture=7

EMBED, File to PC Card transfer utility for PC Cards that use Advanced Micro Devices* components
http://www.amd.com/products/nvd/tools/embed.html

* Third-party marks and brands are the property of their respective owners