I2C EEPROM is very popular to store configuration data. Number of rewrites usually is over 100k cycles.
The memory is split in PAGES which grows with the total memory size... from 8 bytes to 256 bytes pages typically.
The benefit of serial EEPROM is that with the same PCB footprint the memory size can be adjusted. This is hardly true for parallel memories.
When programming EEPROM data, the EEPROM will be busy for up to 10msec (no acknowledge while busy programming). If this time must be minimized, polling every msec for ACK on EEPROM slave address is one method.
If the EEPROM is not written it's probably because the Write protect pin is at the wrong voltage level.
Here is an example of code used to manage EEPROM over the years...
It also manages MCU internal EEPROM from the same functions. Ignore this if your MCU does not have internal EEPROM.
This code can connect to the Single Master I2C by GPIO example Debugging I2C Quick Checklist
A bit more details for people struggling with EEPROM accessing:
I2C EEPROM are handy as the memory size can change by swapping a device by another with same package.
The salestype usually shows the kilobits in the EEPROM
24C02 would mean 2 kilobit = 2048/8 = 256 bytes ==> Addressable with 8 bit index (we say sub address)
==> Using a byte addressing as a sub address is enough.
In pseudo code, the I2C transaction to write 0x55 @ 0x1F with read back post writing would be:
(assuming slave address is 0xA0 for write, 0xA1 for read)
<EEPROM will start the erase and write cycle: EEPROM will be busy>
<wait 10msec or until reading is all ACKed>
Remember : EEPROM works in pages (groups of bytes). Sure write multiple bytes in one shot to speed up things, BEWARE the block of bytes MUST reside in the SAME page...
Example: If the EEPROM is made of 8 byte page, if you try to write in one shot:
@0x06 = 0x66
@0x07 = 0x77
@0x08 = 0x88
@0x09 = 0x99
Only the bytes in bold will be written in the eeprom because they are the last accessed page (0x08..0x0F).
The first two bytes belong to a different page.
In above case, 2 write operations are needed. On the SW side, create a function to write a contiguous block of data by providing a start sub-adress. The SW mecanics below shall take care of the slicing to make life easier for the user.
EEPROM size grew up (Moore's law: Same package area, more bits as process improves and shrinks transistors...) breaking the 256 bytes range... people wanted to keep I2C transaction as short as possible, so the resistance to migrate to 16 bit sub address: The extra sub address MSB bits were invading the slave address LSBs... (for 512 bytes, slave address 0xA0 would mean address [0_00..0_FF], slave address 0xA2 would mean [1_00..1_FF] range.
Eventually, EEPROM grew more and the 16 bit then 24 bit barrier were broken... (LSB first? MSB fist?)
If the EEPROM is not responding, communication is erratic...:
- Is the supply voltage of the slave EEPROM really there?
- Any missing pull-ups on SDA/SCL? (10kOhm at 100kbps?)
- rise and fall time is wrong because of pull-ups being too small or too big
- wrong soldering, swapped SCL/SDA?
- The fastest I2C speed is defined by the slowest slave.
Remember that EEPROMs don't have reset pin. If the MCU is reset/restart while reading data (says 0x00 data), the MCU will restart with SDA tied low by the EEPROM. Run 9 stop bits to clear the bus... Be careful when debugging...
Tip: Please note that some EEPROM also have an extra page which can be OTP (one time programmable). This can be used to store IDs or strings in the EEPROM with the guarantee that it won't be corrupted by the application code.
Tip2: I2C EEPROM are also used for "plug and play", for example in Computer Monitor Displays:
An I2C EEPROM is placed in the monitor. The I2C bus are running through the VGA (or HDMI) cable. The Graphics card will be the I2C Master and regularly poll for EEPROM to acknowledge its address (plug unplug detection by polling). When detected, read the EEPROM for the GFX card to know the display resolution and limits...