28F004S3/28F008S3/28F016S3 SPECIFICATION UPDATE
297799-009
February, 1999
11 of 14
After valid data is read, the device must receive another series of CE# glitches (typically
over one hundred) to induce an invalid read.
IMPLICATION:
This erratum may affect read operations in systems that have a lot of
noise on the flash memory’s CE# input. If CE# is generated asynchronously from the
upper address lines, noise on CE# can sometimes occur when upper address lines
transition from one state to another. However, applications that access flash memory
sequentially will have stable upper address lines and will therefore produce fewer CE#
glitches. Systems that execute code from flash memory or download code from flash
memory into DRAM will usually access the device sequentially; therefore, they will be
less susceptible to this erratum.
Carefully analyze the flash memory CE# input. If glitches are detected, more in-depth
system characterization is need to identify susceptibility to this erratum.
It is important to understand how these glitches manifest themselves in order to
determine whether or not they will cause a problem.
1. In systems that flow unlatched addresses to CE# control logic, the decode logic may
generate CE# glitches when the address bus transitions from one state to another.
However, the processor’s address switching frequency is usually very fast
(somewhere in the order of 1/2 the processor’s operating frequency) which will
cause the glitches high time to be less than 145 ns. If the CE#-high time is less than
145 ns, the glitch has no effect on the component.
Note: Most processor’s with integrated chip select logic use latched outputs and
therefore may not have CE# glitches.
2. If the address bus is not pulled up or pulled down during idle bus cycles, the address
bus may be left in an undetermined state. This condition may cause CE# glitches.
WORKAROUND:
If it is determined that the CE# causes a problem, possible solutions to
help workaround this erratum are suggested as follows.
Hardware solution:
Add system logic to prevent CE# glitches such as latched CE# control logic or
pullup/pulldown resistors to the address bus.
Software solution for data storage applications:
If the device receives over one hundred consecutive CE# glitches, issue a Byte
Write command and program FFh to any location before executing a read operation.
Programming FFh will not alter stored data, but it will give the component sufficient
time to prepare for the read operation.