However, there is a problem with those pullup resistors if you are going to power this with 5V (which I suspect the EEPROM requires) -- since they are also connected to the 5V line. To use a 5V device with i2c with a 3v3 device, you need to connect the pullups to the 3v3 line, so that the maximum voltage seen by the devices is 3.3V.

Nope. I hit a brick wall and was considering getting another EEPROM to see if that was the issue...but now I read your post and the one from mikruth I see that there is probably an issue with the code...

ioukos wrote:My goal is to store on eeprom a timestamp (unix) and a value from a sensor, do you think it's possible ?

I can see no reason why not!

I intend to use these EEPROMS to keep state on all sorts of things across the reboot-boundary. They are such a small overhead in terms of space and cost that it would be unreasonable to risk trashing the ESP8266 flash when you could use one of these chips. Put them on a socket and if you ever go beyond their natural lifespan, you just replace them!

I too continue to get only /xff back from the chip.....awaiting developments!

The fact that just connecting the eeprom to the esp8266 erases it suggests, that the issue is not with the code or esp's i2c peripheral, but either with the power or some rogue signals that are getting sent on boot.

If I remove the resistors, I get variable rubbish when I try to scan.
So the chip/wiring gives every indication that it is correct and working...
A write command does NOT yield any error, but the read command just returns the "b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'" stuff...

What other tests could I do (baring a logic analyser) to locate the problem?

After many tests, it seems that the ESP running micropython is not reading, writing or destroying any data on the eeprom.
I previously had some problems with erroneous data due to a broken jumper cable.
The eeprom can be found OK with xxx.scan() on the ESP and will also be found correctly, when the eeprom address is changed, so it can see the chip, but any read or write commands are accepted but don't seem to be executed.
One other thing I noticed is that if the sda line is not connected to the eeprom, Arduino incorrectly returns 255 for every memory location.

Note:
The 24XX512 does not generate any
Acknowledge bits if an internal programming
cycle is in progress.

7.0
ACKNOWLEDGE POLLING
Since the device will not acknowledge during a write
cycle, this can be used to determine when the cycle is
complete (this feature can be used to maximize bus
throughput). Once the Stop condition for a Write
command has been issued from the master, the device
initiates the internally timed write cycle. ACK polling
can be initiated immediately. This involves the master
sending a Start condition, followed by the control byte
for a Write command (R/W
=
0
). If the device is still
busy with the write cycle, then no ACK will be returned.
If no ACK is returned, then the Start bit and control byte
must be re-sent. If the cycle is complete, then the
device will return the ACK and the master can then
proceed with the next Read or Write command. See
Figure 7-1 for flow diagram.

I've run some tests with multiple WeMos D1 Minis, a WeMos D1 Mini Pro, a PyBoard 1.0 and my VCC-GND STM32F407VET6 board and captured reads and writes with a logic analyser.

In summary, I couldn't get any ESP8266 on either 3v3 or 5v rails to read/write to the device. All return b'\xff\xff'...
PyBoard 1.0 at v1.8.2 and v1.8.7 on 3v3 using both software and hardware I2C was also unable to read/write to the device.
My VCC-GND STM32F407VET6 board running v1.8.7 using 3v3 was the only device that worked every time, with every test.
I tried two identical EEPROM modules. LC Technology AT24C256. Both working as expected with the STM32 board.
Bytes written with the STM32 were still present after failed overwrite attempts with other boards.