I2C eeprom issue

[GeoSaffer]

I have a project that I am playing with.
I am using an Arduino Nano connecting to an eeprom using I2C.
The eeproms are 24LC256 and 24AA00.
The datasheet: https://ww1.microchip.com/downloads/aemDocuments/documents/MPD/ProductDocuments/DataSheets/24AA00-24LC00-24C00-Data-Sheet-20001178J.pdf

I can read from both 24LC256 and 24AA00

I can write to the 24LC256 with out any problem

When I try to write to the 24AA00 it will either write 01 to the first byte or mostly overwrite the 1st byte with whatever was suppose to go to other addresses/positions. it will only write to byte address 0 no matter what I try and set it to. If I send multiple bytes to it it will keep overwriting each byte to the first address.

I thought it might be the eeprom, so I stuck it in a t48 programmer and the t48 has no problem writing to it or reading from it.

I have considered the following:

1. it could be a coding issue, but then why does the same exact code work on the 24LC256.
2. it could be the circuit

• its in a breadboard, I have tried others, and the 24LC256 works fine
• maybe the pullup resistors are wrong, I have tried from 10k down to 680ohm
• bus capacitance, its suppose to be less than 400pF, I have no idea how or where to measure that, amd would it even help on a breadboard, investigating this currently......

I will include the measurement images from the scope for these two eeproms, as you will see there is a clear issue on the right hand image.

Both of these eeproms were sent 2 bytes to address 0, 0x1F and 0x2F. exact same code was used to send it to both.

I have considered sticking the scope on the t48 to compare, but as soon as i connect the probes it says the pins are not available

If anyone have any ideas it would be much appreciated.

[woofy]

Are you sending two address bytes to the 24AA00?
It only uses one.

[GeoSaffer]

The I2C address is the same address for both (0x50) as the 24AA00 only uses one(0x50).

The 2 bytes is sent to dataAddress 0

ill include the code for clarity

if I am using the wrong terminology, please accept my appology for the confusion.

[newbrain]

The I2C address is the same address for both (0x50) as the 24AA00 only uses one(0x50).

What woofy meant is that you must only send one address byte to the 24xx00, not two as in you code, after the 0x50 I²C peripheral address is sent.
The 24LC256 needs two bytes to address all of its 32768 cells (32k × 8 bits = 256 kbits), but given that 24xx00 only contains 16 8-bit cells (16 × 8 = 128 bits), only one byte of addressing is enough.

[GeoSaffer]

Thanks for that.

Are you saying that only the least significant byte should be sent ? instead of MSB and the LSB

if so I have the same result though.

I am not so sure if that would cause the result I see on the scope though.

if you have a look at the image provided above, the righthand side has a voltage drop and it seems to effect the data sent.

[newbrain]

Have you read the datasheet?
24xx00 does not autoincrement the address, as clearly stated on page 8, Chapter 6:

After a byte Write command, the internal address counter will not be incremented and will point to the same address location that was just written.

This means that, with your current code, you are writing the LSB of address at the MSB location (probably 0x00?).
Moreover:

If more than 8 data bits are transmitted before the Stop bit is sent, then the device will clear the previously loaded byte and begin loading the data buffer again

meaning that only the last byte you send will take, leading to the results you observed.

EtA: it will do sequential reads, though.

[GeoSaffer]

Thanks newBrain.

You are right, when in doubt RTFM seems I had the facts mixed up between two datasheets and instead of going back and reading it again i got hung up on the wrong information.

I did however try writing to each address before instead of sequencially and had a similar result....writing only to the first address. I have now discovered as well that there was no delay between writes. I have changed the code to write to each byte on its own with a small delay between writes. this seem to work fine now.

I have attached the the working version.

Thank you so much for taking the time to look at this and giving feedback.