I2C on ESP8266 broken in 1v92 and later, worked in 1v91

Something is seriously busted relating to I2C in recent version of Espruino for ESP8266. 1v91 works, 1v92 and later does not...
Connect and AT24 EEPROM chip - the simplest I2C device you can get. It can read just fine on 92 and later, but write doesn't work for some strange reason!

I2C1.setup({scl:5,sda:4});
var eeprom=require("AT24").connect(I2C1, 64, 256);

On 1v92:

>eeprom.read(0,10);
=new Uint8Array([70, 117, 99, 107, 32, 116, 104, 101, 32, 112])
>eeprom.write(0,[123,212])
=2
>eeprom.read(0,10);
=new Uint8Array([70, 117, 99, 107, 32, 116, 104, 101, 32, 112])

On 1v91:

>eeprom.read(0,10)
=new Uint8Array([70, 117, 99, 107, 32, 116, 104, 101, 32, 112])
>eeprom.write(0,[123,212])
=2
>eeprom.read(0,10)
=new Uint8Array([123, 212, 99, 107, 32, 116, 104, 101, 32, 112])

No hardware changes between the two test cases - exact same ESP8266 board. I just flashed different espruino versions on it between these two tests.

Is there a workaround for this? Has anyone else noticed this?!

Strange, I have several i2c devices running without problems, please send the error output.

What do you mean by "error output"?

The issue as shown above is that write operations are ignored. No errors or anything, it just doesn't write to the EEPROM... I don't quite know how this could happen either! I'm baffled... It would have to be losing most of what I'm passing into I2C1.writeTo() - but not the first two bytes because reads work!

Hmm. This looks like it's not an I2C issue, but rather some very strange interpreter bugs...

A string is turning into undefined for reasons I cannot understand.

Looks like it's back to 1.91 (and I have no idea if/when I'll be able to test this on official board to confirm it happens there - these issues have left me with much less project time than I need

Hmmmmmmm

Works on a Pico on 1v95! And 1v94.

Yet on 1v92/93/94 (can't use 1v95, because on many of the 8266's, wifi.save() breaks the wifi) on esp8266, it doesn't work.

I would very much like to upgrade beyond 1.91 on my ESP8266's.

I'm willing to offer a bounty of $20 of merchandise from my store (plus any hardware you might need to test this - if you happen to not have an AT24 EEPROM + breakout handy) for a fix to this issue.

I have done more investigation. I am still quite baffled.

I tried directly using I2C.writeTo() to write the EEPROM, to no avail. What is weird is that the first two bytes of the writes must be making it through because reads require two bytes to be written to set the address, and that works - but if the third byte made it out, that would enable it to write one byte, and it doesn't do that.

I can move the same module that fails on ESP8266 running 1v95, onto a pico running 1v95 and it works fine - and reads work fine on both. So it's not a hardware issue with the EEPROM or something silly like not holding WP low. And it works fine on an ESP8266 running 1v91.

I just can't figure out what exactly is going on here... Anyone?

I suspect it's this change that broke it: ESP8266: Add i2c clock stretch (#1097)

add pinMode(WPPin,'output') before this pin is used, by default all pins are set as 'input_pullup'

Please share a link where to buy those EEPROM modules

Theyre available everywhete you normally get chinese modules if you want th ed module on pcb. https://www.ebay.com/sch/i.html?_nkw=at24+eeprom+module&_sacat=0

All the module has is jumpers for address pins and wp, 10k pull ups, a socket for the at24 and pin header.

Bare at24-series eeprom can be had from any electronics supplier. There are lots of manufacturers of interchangible eeproms

https://github.com/espruino/Espruino/issues/1311

With a pico and an esp8266 from kickstarter on an 24lc256 eeprom there is nothing failed.

esp8266 is on version 1v94 and pico is on 1v95

 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v94 Copyright 2017 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 512KB:256/256, manuf 0xc8 chip 0x4013
>

var eeprom;
function dd() {
//I2C2.setup( {scl: B10, sda: B3 } ); // pico
//eeprom=require("AT24").connect(I2C2, 64, 256);

I2C1.setup({scl:D2, sda:D0, bitrate:400000}); //esp8266
eeprom=require("AT24").connect(I2C1, 64, 256);
}

setTimeout(function () {
  console.log("Hello World");
  dd();
}, 1000);


/* pico
=undefined
Hello World
>eeprom.read(0,10)
=new Uint8Array([0, 180, 196, 4, 111, 81, 16, 0, 28, 0])
>                   ^
>eeprom.write(0,[55,99])
=2
=undefined
>eeprom.read(0,10)
=new Uint8Array([55, 99, 196, 4, 111, 81, 16, 0, 28, 0])
>
*/

/* esp8266
=undefined
Hello World
>eeprom.read(0,10)
=new Uint8Array([55, 99, 196, 4, 111, 81, 16, 0, 28, 0])
>
=undefined
>eeprom.write(0,[99,55])
=2
>eeprom.read(0,10)
=new Uint8Array([99, 55, 196, 4, 111, 81, 16, 0, 28, 0])
>
*/

Thanks for sharing this test 👍🏻

That is extremely mysterious, as I have reproduced this behavior with several EEPROMs on 3 different ESP8266's. In the issue, I also get totally different results (neither of which involve successful writing) with hardware and software I2C (see issue for deets)

Just tested and confirmed that the difference is NOT bitrate being set - I get the same results either way.

Okay, did some more testing here:

With software I2C, this just plain doesnt work. On an official Espruino Pico:

 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v95 Copyright 2017 G.Williams
>
=undefined
>test() //with hardware I2C1 on pins B6, B7
new Uint8Array([5, 24, 99, 107, 32, 116, 104, 101, 32, 112])
new Uint8Array([7, 26, 99, 107, 32, 116, 104, 101, 32, 112])
=undefined
>
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v95 Copyright 2017 G.Williams
>
=undefined
>test() //software I2C on B6, B7
new Uint8Array([252, 33, 0, 32, 1, 0, 0, 0, 10, 0])
new Uint8Array([252, 33, 0, 32, 1, 0, 0, 0, 10, 0])
=undefined

The first one, with hardware I2C, is reading actual data off the chip. I do not know where the garbage that it's reading back with software I2C is coming from....

Reads using software I2C similarly give bad values on the ESP8266, while hardware I2C can at least read the correct values off the chip...

|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v95 Copyright 2017 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 4MB:1024/1024, manuf 0xe0 chip 0x4016
>
=undefined
>test()
new Uint8Array([200, 31, 255, 63, 200, 243, 255, 63, 220, 53])
new Uint8Array([200, 31, 255, 63, 200, 243, 255, 63, 172, 53])
=undefined
>


>
>
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v95 Copyright 2017 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 4MB:1024/1024, manuf 0xe0 chip 0x4016
>
=undefined
>test()
new Uint8Array([7, 26, 99, 107, 32, 116, 104, 101, 32, 112])
new Uint8Array([7, 26, 99, 107, 32, 116, 104, 101, 32, 112])
=undefined

It would appear that software I2C is totally broken? How come this doesn't show up with other devices... this isn't subtle.

Yet the AT24 I am using is clearly OK because it works fine with hardware I2C on the Pico!

ESP32 works with hardware I2C (though a WARNING is printed to console for reasons unclear), does not work with software I2C (Though the gibberish numbers it reports are different!)

 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v95 Copyright 2017 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
>WARNING: jshI2CSetup: driver installed, sda: 4 sdl: 5 freq: 400000, 
=undefined
>test()
new Uint8Array([7, 26, 99, 107, 32, 116, 104, 101, 32, 112])
new Uint8Array([9, 28, 99, 107, 32, 116, 104, 101, 32, 112])
=undefined
>
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v95 Copyright 2017 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
>
=undefined
>test()
new Uint8Array([136, 108, 251, 63, 136, 108, 251, 63, 176, 73])
new Uint8Array([136, 108, 251, 63, 136, 108, 251, 63, 224, 194])
=undefined

It is time to use a logic analyser.

And may be it is time to check power supply :)
I think, oscilloscope is usefull, too. You can check signal voltage levels etc. It is usual bug when I work with I2C. Sometimes pullups need to be changed after I2C clock change, sometimes something else happens... In fact, oscilloscope is my main tool to debug I2C.

I have tried both with soft and hard on a pico also, but I get no differense.

var i2c = new I2C();
i2c.setup( {scl: B6, sda: B7 } ); // pico soft i2c
eeprom=require("AT24").connect(i2c, 64, 256);

I2C1.setup( {scl: B6, sda: B7 } ); // pico
eeprom=require("AT24").connect(I2C1, 64, 256);

What hardware are you using? What address are you reading/writing to?

Was that with 1v95?

@DrAzzy See #10

What the hell.

It works with the scope connected, but not with the scope disconnected. What sorcery is this?!

It looks to me like I2C is currently just on the edge of working

Edit: Compared 1v91 and 1v95 - On 1v91, when a 1 is sent, SDA is pulsed high, and SCL is briefly pulsed high in the middle of the HIGH on SDA. On 1v95, SDA and SCL go high about simultaneously. With no scope probe connected to SCL, it doesn't work with the EEPROMs. With a scope probe on SCL, I suspect it slows the rise time just enough that SDA is clearly in the correct state when it detects SCL as going high.

@Gordon, in 1v95 you fixed the spike on auto-configured ports. I know this was detected on Espruino (Wifi) board. I see that @DrAzzy has issues on ESP8266 and not on Espruino board(s). I hope the change did not mess and create new spikes somewhere else...

It's right on the edge

Like, some chips will work, others won't, in the external EEPROM module (but none of them work on the more compact board I have wired up).

It was the ESP8266 addition that added support for clock stretching in 1v92 that did it I think.

@allObjects the spike reduction change won't be an issue here.

I've made some changes now for ESP8266 and software I2C that may fix this - but I'm working blind as I don't have an EEPROM on me to test with.

Thanks Gordon, will test this later