I am attempting to read and write from/to an EEPROM chip, and have got access to this 64 kbit device.

It appears I can write to the device and read from it, but there appears to be some strangeness around addressing the written data for later writing.

I am using this page as a reference for my code, and getting some strange results. For starters, the 64 kbit is in fact 8k, and I was able to write to the 10000 the byte and read from it (though I suspect it rolled over on the memory address).

The strangeness was when I attempted to write two adjacent bytes to two adjacent addresses. The subsequent read of the two addresses read the second byte both times. It was as if the location pointer was stuck on the last read.

when I reset my code, I can read the previously written addresses, confirming they are not just stuck in memory.

Similarly when I write an array of bytes to an address, I can read back the bytes, but if I change the read pointer to read again, the bytes are returned all the same, until the pointer goes a significant distance away from the read address (over say 50 bytes). At this point the return data is all 255.

Finally if I read many bytes, requesting say 50, the most I get back is 32 bytes.

Say I write:

[60, 61, 62, 63, 64, 65] to position 8000 in memory

if I attempt to read from the address or addresses near it or anywhere else, I either get the exact bytes I wrote at whatever position I request, or I get nothing (all 255).

I have managed to read old data from other locations from previous compiles, so the data is for sure in the chip, just accessing it seems uncertain.

Some read results:

7000: [255, 255, ..., 255]
7500: [255, 255, ..., 255]
7980: [60, 61, 62, 63, 64, 65, 255, 255, ..., 255]
8040: [60, 61, 62, 63, 64, 65, 255, 255, ..., 255]
7960: [60, 61, 62, 63, 64, 65, 255, 255, ..., 255]
8060: [60, 61, 62, 63, 64, 65, 255, 255, ..., 255]
7940: [60, 61, 62, 63, 64, 65, 255, 255, ..., 255]
8500: [255, 255, ..., 255]
8150: [60, 61, 62, 63, 64, 65, 255, 255, ..., 255]


  const int memoryI2CAddress = 0x50;

  void Initialise() {

  void Test() {
    unsigned int baseAddress = 8000;
    byte data[6] = {64, 65, 66, 66, 65, 61};
    Wire.write((byte)(baseAddress >> 8));
    Wire.write((byte)(baseAddress && 0xFF)); 
    Wire.write(data, 6);


  void ReadTest(unsigned int baseAddress) {
    Wire.write((byte)(baseAddress >> 8));
    Wire.write((byte)(baseAddress && 0xFF));   

    int count = Wire.requestFrom(memoryI2CAddress, 50);
    while (Wire.available()) { Serial.println(Wire.read()); }


The data addressing seems to be sensitive to the first address byte and not the second. When inverting the order of the most and least significant bytes and comparing to the MSB change with the address, I can reliably return the byte at the correct address. This appears to explain why I either get the same data for some addresses and not others, where the MSByte is or is not changing.

So why is the system insensitive to the least significant byte in the address?

  • Good catch, was a typo in my description.
    – J Collins
    Feb 10, 2022 at 15:51
  • 8000 in my description is in decimal, under the 8192 limit
    – J Collins
    Feb 10, 2022 at 16:00
  • I'm not sure I understand what your question is. But, what I'm wondering when reading it is whether or not you read section 6 of your linked datasheet.
    – timemage
    Feb 10, 2022 at 17:25
  • I have read 6 and 8, but admit I'm not totally au fait with it and am wondering what the Wire library will be doing on my behalf. What have you spotted explicitly? Primarily I'm not getting an expected behaviour in reading and writing to specific addresses of one or several bytes, either the write is not writing to the correct address, and/or the read is not reading from the correct address.
    – J Collins
    Feb 10, 2022 at 17:31

1 Answer 1


Sadly the simple answer is in how the least significant byte was being calculated, and the boolean operator generating it.

Wire.write((byte)(baseAddress && 0xFF)); 

should have been

Wire.write((byte)(baseAddress & 0xFF));

Tough lesson to check my assumptions!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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