@jmarcelino
I had high hopes and was rather pleased you pointed out the variant using a controlled stop. Sady it doesn't work for me.
Here is my code. Changing the string I try to write doesn't change anything.
I hadsome concern in my Python noobishness that my assignments to the addressing array may not be correct but a print(str(addressing)) of it showed it was correct (not in th below code).
Oh. I saw you mention an older I2C eeprom you had. I checked it out - it may be a 5v only part.

@jmarcelino
Wow. I didn't know you could make stop optional. I'll re-read the docs and see if I was blind on this. I would have tried it if so. That would allow page read and page write as stop bit/ack bit is used etc.

However I've looked for any information on memory read and memory write and been unable to determine if the routines send the correct intialization. I think I did pose the question on another thread and didn't get an answer.

Also, I know that the previous firmware would read the first read of data correctly the first time up after a power up (sometimes) - then fail every other time. I thought to do that it must have setup the A1 command - maybe not on a read etc and first time up....

Maybe you have the solution - a million thanks if so.

Yes - absolutely...The 24LC512 and others demand a leading command xA1 or xA0 for read or write respectively - and also bits 1, 2 and 3 are the chip number on the bus - for those interested. I didn't see how other chips (can have up to 8 on the one bus of this size) could be addressed if it was automatic so making it generic is actually better.

Strangely, Arduino Wire library does the correct thing by sending the lead in code - and quite pointless saying that - but without contrary knowledge I thought it might be the same here.

Yes, I believe I have the bus addressing corrrect with - but clearly without the leading A1 it won't work.

I2C.readfrom_mem is a generic "read from sequential registers" function it doesn't know about each memory chip's protocol. Likewise I'm not sure it does the signalling the way the Microchip protocol expects, do you have a logic analyser?

I have an I2C eeprom to test but not sure when I'll be able to do it, may take a few days.

@livius
Hi. Thanks for asking.
Unfortunately yes - I programmed it with an Arduino and I know it contains data. Code inthe arduino reads it back etc etc. Also, It worked and read back correctly only once after power up of a WiPy previously and failed everytime thereafter.
Erased records are 0xFF as well... Being all 00 is strange.

@daniel
Hi and thanks for the update.
Sadly it doesn't resolve the I2C memory issue I have. I use pullups on SDA and SCL of 4K7 at the moment, I bypass Vss at the chip etc. I'm using a WiPy2 and the P9/P10 pins which I believe is the "main" I2C bus.
I'm running baudrate=100000 - I tried 10000 and that crashed (no biggie, 100khz is fine for a 3V memory).
The scan routine returns "80" which is correct for an I2C memory by Microchip.
Using 'result = i2c.readfrom_mem(80, 0, 32)'
Reading a known programmed I2C memory however returns all "00" data as below.
-- start copy --
scanning
[80]
0 b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00'
-- end copy --
Hope that helps in debugging.