Take the 2-minute tour ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.

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!

share|improve this question
    
Could you please share a link to the datasheet of the rogue EEPROM? –  Anindo Ghosh Nov 29 '12 at 13:58
    
@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"). –  llakais Nov 29 '12 at 14:17
    
Thanks. Got it. –  Anindo Ghosh Nov 29 '12 at 14:30
1  
See electronics.stackexchange.com/questions/5096/… for some other suggestions. –  Jim Paris Nov 29 '12 at 15:22

2 Answers 2

up vote 8 down vote accepted

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.

share|improve this answer
    
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. –  llakais Nov 29 '12 at 14:18
    
@SeeminglySo +1 for "bypassing the problem". –  Anindo Ghosh Nov 29 '12 at 14:31
    
@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? –  ExcitingProjects Nov 29 '12 at 15:14
    
@ExcitingProjects Unfortunately there are other devices on the bus, but thank you for the idea. –  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).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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