Gem of the Week - EEPROM I2C Memory

Of course I am designing a Rocketometer around the Propeller. How could it be otherwise?

In doing so, I have to get my own parts. The Sparkfun breakout is an interesting jumping-off point, but they don't even use bypass caps, so I added a set of those. Also one thing which concerns me about this whole endeavor is that all the memory is limited. Each cog gets 2kiB, for a total of 16kiB, but the images for each cog must be stored in main memory, which has 32kiB of RAM and 32kiB of ROM. There is no way that I am going to be able to get the program source code embedded with that little amount of memory.

This brings us back to the EEPROM on the breakout board. The bootloader burned into the Propeller knows how to bit-bang an I2C interface and read a memory on the bus. It treats the memory as a 32kiB byte-addressable memory with auto-increment, so it can set an address once, then read and read and read and fill main RAM. The Propeller documents say to use a 24LC256 or similar, so I got to looking at Digikey to see if they had that chip, and perhaps more interestingly, if there was a bigger chip which would still work. It turns out that the design of the EEPROM is the gem of the week.

First, the hardware. The 24LC256 is a 256kib memory organized as a 32ki x 8 (byte-addressable) memory. It is in a kind of large package, a whopping 5mm wide, with 8 pins. This is a lot for a device which is I2C and could in principle work with only 4 pins. But here is the cleverness. The device has three address pins, allowing the 7-bit I2C address to be anything in the range 0x50-0x57. So, you could just stack up to 8 devices on the bus, with only the address pins different, and get 32x8=256kiB of memory, at the cost of using 8 devices.

The 32kiB space is addressable with 15 bits, but the I2C protocol is byte-oriented, so you have to send 16 bits, of which only A0-A14 are considered, and A15 is ignored.

These facts work together to allow the address space to be easily extended. First, a 64kiB part is doable just by considering A15 in the address. Next, a device can internally answer more than one address, for instance by ignoring the A0 hardware pin and answering both 0x50 and 0x51. This of course means that you have to readdress the device when you cross from the address space covered by 0x50 and the one covered by 0x51. You would have to do that anyway if there were multiple real devices.

This all adds up to the STMicro M24M02, which appears to be compatible with the 24LC256, in that if you talk to an 'M02 like a '256, it will answer like a '256. So, you can use the larger device and the bootloader should happily just work. However, it is a 2Mib memory organized as 256ki x 8 (256kiB), eight times as much memory as the reference design, and approaching comparability with the LPC2148 and its 512kiB of Flash. Then when your application takes over, you can use your own bit-bang to access the full chip.

The 'M02 still has one address pin, so in principle you could make a 512kiB memory in 1 chip without changing anything. Going beyond this will break the nice de-facto protocol going on here.