Electronic – Flash and EEPROM

The technique I normally use is to prefix the data with a 4-byte rolling sequence number where the largest number represents the lastest / current value. In the case of storing 2 bytes of actual data that would give 6 bytes total and then I form into a circular queue arrangement so for 128 bytes of EEPROM it would contain 21 entries and increase endurance 21 times.

Then when booting the largest sequence number can be used to determine both the next sequence number to be used and the current tail of the queue. The following C pseudo-code demonstrates, this assumes that upon initial programming the EEPROM area has been erased to values of 0xFF so I ignore a sequence number of 0xFFFF:

struct
{
  uint32_t sequence_no;
  uint16_t my_data;
} QUEUE_ENTRY;

#define EEPROM_SIZE 128
#define QUEUE_ENTRIES (EEPROM_SIZE / sizeof(QUEUE_ENTRY))

uint32_t last_sequence_no;
uint8_t queue_tail;
uint16_t current_value;

// Called at startup
void load_queue()
{
  int i;

  last_sequence_no = 0;
  queue_tail = 0;
  current_value = 0;
  for (i=0; i < QUEUE_ENTRIES; i++)
  {
    // Following assumes you've written a function where the parameters
    // are address, pointer to data, bytes to read
    read_EEPROM(i * sizeof(QUEUE_ENTRY), &QUEUE_ENTRY, sizeof(QUEUE_ENTRY));
    if ((QUEUE_ENTRY.sequence_no > last_sequence_no) && (QUEUE_ENTRY.sequence_no != 0xFFFF))
    {
      queue_tail = i;
      last_sequence_no = QUEUE_ENTRY.sequence_no;
      current_value = QUEUE_ENTRY.my_data;
    }
  }
}

void write_value(uint16_t v)
{
  queue_tail++;
  if (queue_tail >= QUEUE_ENTRIES)
    queue_tail = 0;
  last_sequence_no++;
  QUEUE_ENTRY.sequence_no = last_sequence_no;
  QUEUE_ENTRY.my_data = v;
  // Following assumes you've written a function where the parameters
  // are address, pointer to data, bytes to write
  write_EEPROM(queue_tail * sizeof(QUEUE_ENTRY), &QUEUE_ENTRY, sizeof(QUEUE_ENTRY));
  current_value = v;
}

For a smaller EEPROM a 3-byte sequence would be more efficient, although would require a bit of bit slicing instead of using standard data types.

If you speak in general terms the primary difference between flash and EE prom is simply architectural with respect to the data access, the actual write/erase mechanism is identical at the cell level. What circuits wrap around those cells for moving the bits to and from the cell, how parallel the operation is and how many happen at the same time is where the real differences lie. So an accurate statement would be , if you've implemented a FAMOS or FGMOS cell can you make a flash or an EEPROM chip from that, and the answer would be yes.

But be aware it will be hard to compare various EEPROMS to Flash devices simply because of the differences in the process technology, the process capabilities and it's wear resiliency.

EEPROMS tend to be small and so tend to be more robust and designed for longer term storage which affects the process design. On the other end you can see that there is multilevel Flash with is optimized for bit density. this is yet another optimization.

All floating gate cells are characterized by their usage of Fowler-Nordheim (F-N) Tunnelling for the injection of the charge into the floating gate through the Gate oxide. F-N tunnelling in turn is characterized by Quantum Mechanical tunnelling through a triangular potential well under high electric fields. The point here is that tunnelling is inherently damaging to the gate oxide and leaves residual evidence. The solution recommended above is to ensure that each cell is worn out the same amount so you can't go back read the evidence of what was there - when put that way it does really seem like such a good idea.

Very few people/labs have the ability to strip apart a die and read the residual damage in the floating gate device that has been erased. It is possible, certainly, but it won't be through probing the device and it would be very difficult. It would be best to capture the device with charge still in the gate (but this poses different problems in itself).