Conflict with two EEPROM

[jonathannakache9]

Posted on July 06, 2012 at 10:02

Hi,

With a STM32, I have a problem

to select

either

EEPROM

(

M24LR64-R and M24M02-DR)

on the same bus

I2C

.

Here are the

''device

select

code

'':

For

M24LR64

-R:  1 0 1 0     X 1  1 X

In the order

:  1 0 1 0 = Device type identifier   X = E2   1 1 = E1 E0 ( chip enable)   X = RW

For

M24M02

-DR:

1 0 1

0   1

X

X

X

In the order

: 1 0 1 0 = Device type identifier   1 = E2 ( chip enable)   X X = A17 A16 (MSB address bits )    X = RW

The two

address bits

A17

and

A16

for

M24M02

-DR

can not be

used

because they would

pose

a conflict with the

R

-

M24LR64

there is

there a way

around the problem

?

Thank you for your

response

, #pounds-head-on-desk

[Tesla DeLorean]

Posted on July 06, 2012 at 11:19

there is

there a way

around the problem

? Due to the lack of forethought by ST the only way around it would be to use two I2C buses, or gate the clock between the two devices.

[emalund]

Posted on July 09, 2012 at 14:32

there is

there a way

around the problem

? yes, there is a plethora of I²C EEPROMS with 'pinnable' addresses (i.e. you change the address by grounding certain pins) change one or both to such. Erik

[frankmeyer9]

Posted on July 09, 2012 at 15:32

For my understanding, the E0,E1 pins of the

M24LR64-R

serve as address selection pins, thus allowing for 4 devices on one I2C bus. To cite the datasheet (CD00217247.pdf): 2.3 Chip Enable (E0, E1) These input signals are used to set the value that is to be looked for on the two least significant bits (b2, b1) of the 7-bit device select code. These inputs must be tied to VCC or VSS, to establish the device select code as shown in Figure 3. When not connected (left floating), these inputs are read as low (0,0). ... 5.5 Memory addressing To start communication between the bus master and the slave device, the bus master must initiate a Start condition. Following this, the bus master sends the device select code, shown in Table 2 (on Serial Data (SDA), most significant bit first). The device select code consists of a 4-bit device type identifier, and a 3-bit Chip Enable “Address�? (E2, E1, E0). To address the memory array, the 4-bit device type identifier is 1010b. Up to four memory devices can be connected on a single I2C bus. Each one is given a unique 2-bit code on the Chip Enable (E0, E1) inputs. When the device select code is received, the device only responds

[Tesla DeLorean]

Posted on July 09, 2012 at 15:45

I'm going with Jonathan's analysis that these babies clash. I looked at the datasheets, he's probably wired them up.

Whoever thought putting high order address bits for the memory array into the I2C's device address needs to be tarred and feathered.

[emalund]

Posted on July 09, 2012 at 16:17

Whoever thought putting high order address bits for the memory array into the I2C's device address needs to be tarred and feathered.

correction Whoever designs without reading datasheets fully needs to be tarred and feathered. The specific reason for the chips with the high order byte address in the I²C address is that these chips solely are intended as one chip replacements for 4 chips that have 1/4 the capacity and are address tied as the replacement chip reads them. For new development there are chips available with single I²C address and two byte byte address. Erik

[Tesla DeLorean]

Posted on July 09, 2012 at 16:54

For new development there are chips available with single I²C address and two byte byte address.

Or three byte addresses hopefully.

[emalund]

Posted on July 09, 2012 at 18:11

Or three byte addresses hopefully.

really ''enough bytes to cover the capacity, hopefully'' two byte address will cover most (<65k bytes) Erik

[jonathannakache9]

Posted on July 10, 2012 at 12:19

ok,

thank you

for

your answers

but

we need

an

EEPROM

of 2Mb

 

and

a

radio EEPROM

We have not

found other

EEPROM

..

.

an idea?

[John F.]

Posted on July 10, 2012 at 12:52

ST's implementation of the I2C controller is so awkward that you may end up ''bit-bashing'' the I2C on GPIO pins anyway. Do you have one (use as alternate I2C clock) or two (new I2C bus) spare pins? If not, you must multiplex the I2C bus you have. There are various buffer ICs etc. that might help.