So I know that almost all i2c EEPROM ICs use 0xAh (or 1010) as the top four bits of the slave address. I currently have a 16 kbit EEPROM on my i2c bus that uses the lower 3 bits of the slave address for block addressing. This means that it co-opts all addresses starting with 0xAh.

I need to put a second EEPROM on the same bus, but I am having an extremely difficult time finding one that will not conflict with the existing chip (for design reasons, that chip cannot change). A smaller capacity EEPROM is fine, but I can't use any of the myriad 8 kbit/4 kbit/2 kbit devices out there because their slave addresses all start with 0xAh.

The only thing I was able to find was this chip from NXP, which uses 0x2h as the top four bits of the slave address. But it does not work in fast mode (400 kHz) and only comes in DIP or SO packages, both of which are much too big.

Does anyone know of an i2c chip that operates in fast mode, comes in a reasonable package, and, most importantly, uses a slave address not starting with 1010/0xAh? I would be extremely grateful for any help pointing me in the right direction!

  • \$\begingroup\$ Could you please share a link to the datasheet of the rogue EEPROM? \$\endgroup\$ – Anindo Ghosh Nov 29 '12 at 13:58
  • \$\begingroup\$ @AnindoGhosh Do you mean the one w/ the non-standard slave address? There's a link to that one in there (on "this" in "The only thing I was able to find was this chip from NXP"). \$\endgroup\$ – llakais Nov 29 '12 at 14:17
  • 1
    \$\begingroup\$ See electronics.stackexchange.com/questions/5096/… for some other suggestions. \$\endgroup\$ – Jim Paris Nov 29 '12 at 15:22
  • \$\begingroup\$ What about an i2c mux? \$\endgroup\$ – alex.forencich Nov 6 '16 at 3:40

While not specifically the answer to your question, in a similar situation faced on one of our product upgrades, we used a workaround: An identically addressed I2C device needed to be added to the design, but conveniently the parts had Chip-Enable lines.

So the design simply added a CE off one of the controller GPIOs - actually we added 2, so that we could potentially stick in 2 more of the parts when inevitably the software team outgrows the additional 100% capacity we've just provided them.

  • \$\begingroup\$ Thanks, that is a good idea. This chip has a write protect, but no chip enable unfortunately. So I could make writes work properly with this method, but reads would still be a mess. \$\endgroup\$ – llakais Nov 29 '12 at 14:18
  • \$\begingroup\$ @SeeminglySo +1 for "bypassing the problem". \$\endgroup\$ – Anindo Ghosh Nov 29 '12 at 14:31
  • \$\begingroup\$ @llakais Similar to suggested answer, can gate the SCL (by hardware or in code) so that one chip is clocked at a time only during write? Any other I2C devices on bus other than the EEPROMs? \$\endgroup\$ – ExcitingProjects Nov 29 '12 at 15:14
  • \$\begingroup\$ @ExcitingProjects Unfortunately there are other devices on the bus, but thank you for the idea. \$\endgroup\$ – llakais Nov 29 '12 at 15:40

If you can bit-bang the I2C master, and if none of the devices use SCK-based handshaking, you could swap SDA and SCK on some of the I2C devices. You may need to check your I2C code to make sure it never generates any sequences of events on SCK/SDA which a device with those pins reversed could mistakenly interpret as a start+addressing sequence. Normally that shouldn't be a problem, since every "1" bit clocked out by or to one device will be seen as a stop and restart by the other, and the only time a device will ever see a "0" bit clocked in is if the other does a stop and restart. Still, there is a very remote (theoretical) possibility that both devices might somehow get into a state where they are trying to assert SDA which could lock up the bus. If you're using a processor which can drive pins high with 10mA, that danger might be averted by wiring a 330 ohm resistor in series with the "SDA" connection on at least one side of the bus (thus ensuring that the processor could clock the other side, which would cause any device that was holding SDA low to release it, thus allowing the other side to be clocked).


As the PCF85103 (256*8bit EEPROM with an non-Standard-Address 0010XXX instead of the usual 1010xxx) is excluded due to the speed, the only remaining solution may be to use a multiplexer (PCA9548, PCA9546, PCA9544/45, PCA9540, PCA9542/43).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.