EEPROM Write Cycle Time and Write Cycle Endurance

Question

I have an embedded software application that is copying a buffer from RAM to EEPROM. In this case, the EPROM device is a 28C010 (128K x 8). The copying is done at non-regular intervals, generally in blocks of multiple bytes. I would assume that other (not all) EEPROMs behave like this one, but this is what I have to work with.

The answers to my questions below will help determine the strategy for saving persistent information while doing real time processing.

The EEPROM is accessible just like RAM with some exceptions for writing:

• BYTE WRITE: Individual bytes can be written, and the completion of the write cycle can be determined by polling
• PAGE WRITE: Contiguous blocks of bytes can be written for bytes within the same 128-byte block, and, as long as each byte write is followed by another byte write in the same block within 150 microseconds, then the benefit of PAGE WRITE are obtained. The benefit is that completion of the page write can be done by polling at the end of the writing of the block. (There are no delays between byte writes, and the completion of the page write cycle is internalized to the EEPROM.)
• Write Cycle Endurance: There is a 10,000 write cycle limit. No other details are given.

In both cases, polling is accomplished by reading back the last byte written until the returned value is equal to the value that was written.

There are other ways to determine that a write is complete, including just waiting for the maximum specified Page Write cycle time, which is 10 milliseconds.

I intend to use polling, with the expectation that it will determine completion sooner than the 10 millisecond Page Write cycle time.

I have two questions:

1. Can I expect my polling time in Page Write mode to be proportional to the number of bytes written (or can I see some benefit from writing a few bytes as opposed to a whole page)?
2. How does the Write Cycle Endurance work? Is it applied to each byte alone or two a whole page (or to the entire memory as a whole)? In other words, if I write a partial page in one Page Write and later I write the rest of the page in another Page Write cycle, how does that affect my write cycle endurance? Does it count as two write cycles? Can someone elaborate on this?

Since Page Writes to EEPROM are completed internally by the EEPROM after the last write to a page, I can perform the writes in background in most circumstances.

The size of the blocks that are being copied will vary somewhat each time, and they can't be expected to be in multiples of the page size. They can be made to be as small as just over a page size or several pages+, based on a threshold that will be determined later.

Answer 1

What you describe is typical of EEPROM chips. The minimum number of bytes you have to erase at once, the maximum you can write at once, and the minimum you can write at once can all be different.

The way I usually deal with this is to have a module that virtualizes reads and writes to the EEPROM. This module presents a procedural interface for reading and writing individual bytes.

By the way, it's a good idea to have this module use a wider address than what the EEPROM actually requires. It's not uncommon at all for projects to evolve and replace the EEPROM chip with a bigger one later. If you only used a 16 bit address and went from 64 kB to a larger EEPROM, you have to check and possibly rewrite a bunch of app code that now has to use at least 3 address bytes when it was written for 2. Usually I use 24 bit addresses on a 8 bit machine and 32 bit addresses on a 16 bit machine to start with, unless there is a good project-specific reason not to. That also allows you to create modules for various different EEPROMs that all present the same procedural single-byte read/write interface. Sometimes I have build-time constants that create short-address versions of these routines when the EEPROM size allows it and when taking the risk in the app code is worth it.

Anyway, the EEPROM module maintains a RAM buffer of one erase page (those are usually larger than or the same size as write pages). The module keeps track of which EEPROM block, if any, is currently in the RAM buffer, and whether any changes have been made (dirty flag) that have not yet been written to the physical EEPROM. App reads and writes work on this RAM buffer and don't necessarily cause read/write directly to the EEPROM. A FLUSH routine is provided so that the app can force any cached data to be written to the EEPROM. In a few cases I used a timer to call the flush routine automatically some fixed time after the last write.

When the app accesses a byte not in the RAM buffer, then the block containing the byte is read from the EEPROM first. If the buffer is dirty, then it is always flushed before a different EEPROM block is written to it.

This scheme is generally faster, and also minimizes the actual number of writes to the EEPROM. The dirty flag is only set if the new data is different from the old data. If the app writes the same data multiple times, the EEPROM is written to at most once.

This scheme also uses the EEPROM more efficiently since entire blocks are erased and written at a time. This is done once per block regardless of how much write activity there was within the block before the app addressed a byte in a different block. For most EEPROMs, writing a whole block or writing one byte within a block count the same in terms of lifetime. To maximize EEPROM lifetime, you want to write as infrequently as possible, and erase and write whole blocks when you do.

Answer 2

In some chip designs, the page-write time will be essentially the same as the byte-write time, since a chip that may be organized as 128Kx8 externally may be 1024x1024 internally, and thus have an EEPROM array that can write up to 1024 bits (128 bytes) at a time. In other chip designs, each page write will be performed as a sequence of smaller operations (possibly individual byte writes), but performance may still be faster than writing individual bytes if the chips chips use charge pumps to supply write current; oftentimes such charge pumps need to powers up before each write operation and power down afterward; if a chip takes e.g. 1ms to power up and 1ms to write a byte, writing one byte would take 2ms, and writing 16 bytes as a group would take 17ms--just over eight times as long (writing 16 bytes individually would take 16x as long as writing one).

Generally, I would expect that writing many bytes on a page may take longer than writing one, but will be much faster than writing all those bytes individually. Even on a chip which has a full-width bus between the page buffers and the memory array, the charge pump might not be able to supply enough current to write 1024 bits as quickly as it could write one. Further, some chips might include interlock circuitry to limit the number of simultaneous bit writes; each time a bit write is complete, the chip could move on to process another one which hadn't yet been started.