M24C04 acknowledges 0x50 to 0x57 instead of just 0x50/0x51

[Frederic Chasse]

Posted on June 29, 2018 at 17:06

Hi,

I'm using the M24C04 EEPROM with the 5-UFDFPN package.

I can read/write to it without problems, but I just found out that the EEPROM acknowledges not only 0x50 and 0x51, but actually acknowledges 0x50 to 0x57. According to the datasheet, the address of the 5-UFDFPN package should be:

1 0 1 0 0 0 A8

Where A8 is the page number. For the other packages, it's:

1 0 1 0 E2 E1 A8

Where E2 and E1 are pins on the IC. The datasheet says that E1 and E2 are read as 0 in the DFN5 package. But from what I see, it seems that the chip accepts any value of E1 and E2, thus acknowledging 0x50 to 0x57.

I tested that it is indeed this IC that causes the 'fake acknowledgements' because the I2C lines of that EEPROM are on a multiplexer, and when the mux disconnects the EEPROM from the uC, I don't get the acknowledgements anymore.

Have you seen this problem before?

Thank you,

Fred

[Pierre P.]

Posted on July 06, 2018 at 11:33

Hi Fred,

Never seen this problem before.

The device select code for DFN5 must be 1010 00A8 R/W and the device should deselect itself from the bus if (E2,E1)=(1,1)  is sent. In any case the device will not answer ACK to 1010 11A8.

Let me know.

BR

ST EEPROM Support Team

[Frederic Chasse]

Posted on July 09, 2018 at 23:12

Hi Pierre,

I know that's the supposed behavior, but what happens right now is as if (E2, E1) are treated as don't cares.

[Pierre P.]

Posted on July 12, 2018 at 10:10

Hi Fred,

Next week I will test in ST labs a DFN5 device with your config. In the same time,did you cross check with a different virgin part ?

BR

[Frederic Chasse]

Posted on July 12, 2018 at 16:13

Hi Pierre,

Thank you for that. That's a good idea, I haven't tried it yet. I'll order the part and keep you updated.

[Frederic Chasse]

Hi Pierre,

I have some trouble soldering a new part, have you had the chance to try it on your side?

[Pierre P.]

Hi Fred,

Sorry for the delay (Coming back from annual leave).

I understand now the concern: The reason comes from the fact that the 4Kb DFN5 share the same core die than the 8Kb and 16Kb. Thus must also responds "ACK" to other device select code 1010 xxx used for 8 & 16 Kb.

Best Regards