chipKIT Emulated EEPROM Improvement

Created Mon, 24 Oct 2016 12:38:24 +0000 by Jacob Christ

Jacob Christ

Mon, 24 Oct 2016 12:38:24 +0000

As you may or may not know, chipKIT-core uses part of the FLASH program space of the PIC32 to emulate EEPROM. The "emulation" refers to an EEPROM's ability to erase any byte of its memory where as FLASH memory can only be erase a large block at a time. The way this is accomplished is through the use of a table stored in the EEPROM emulation FLASH that keeps track of the "programmed" bytes. Each entry in the table consists of bits:

1 bit to indicated this entry in the table is taken, the "taken" bit. 1 bit to invalidate a taken location, the "valid" bit. 22 address bits to store the emulated EEPROM address. 8 data bits to store the data written to the emulated address.

This makes a total of 32 bits. A blank, un-programmed, FLASH, or EEPROM, location typically reads as a logic 1 and thus a blank EEPROM byte reads as 0xFF. Currently the way this table is implemented is that when you try to read from a blank table that has no entries it in, irregardless of the address selected the library returns 0xFF, thus emulating a blank EEPROM. When a value is written to this blank table the the first entry in the table is written with a 0 in the "taken" bit location, the address wishing to be programmed and the data to be stored at this address. (NOTE that the invalid bit has not been cleared yet).

This instruction will generate this entry in the table:

EERPOM.write(0x100, 0x55);

Taken Valid Address Data 0b0 0b1 0x100 0x55

If the address 0x100 is written to again, the firs entry is invalidated and a new entry is created:

EERPOM.write(0x100, 0xAA);

Taken Valid Address Data 0b0 0b0 0x100 0x55 <- Original entry with second bit set to zero to invalidate. 0b0 0b1 0x100 0xAA

Further if the EEPROM location is written back to 0xFF (blank) a third entry will be made in the table:

Taken Valid Address Data 0b0 0b0 0x100 0x55 <- Original entry with second bit set to zero to invalidate. 0b0 0b0 0x100 0xAA <- Second entry with second bit set to ze to invalidate. 0b0 0b1 0x100 0xFF

This table is larger than the emulated EEPROM but it can still fill up. When it fills up all the "valid" locations are loaded into RAM, the FLASH page is erased and only the valid entries are rewritten to memory.

I have implemented a change to the operation that will prevent 0xFF being written into the table and instead invalidate any existing value found for an address written, since the library will already return 0xFF if a valid entry does not exist the usefulness of the library should be unaltered. The purpose of this change is to reduce FLASH wear by lowering the number of erase cycles if they locations of the EEPROM are often written back to a blank state. I have tested these changes and think they are sound, but I would like someone else to verify that I haven't broken the library. My pull request is located here:

https://github.com/chipKIT32/chipKIT-core/pull/274

And a built version of the core with these changes can be found here:

http://chipkitjenkins.wayneandlayne.com/job/chipKIT-core%20PR%20Builder/165/

Please let me know if you have any questions, comment here or PM me.

Jacob