I2C on ESP8266 broken in 1v92 and later, worked in 1v91 #5987
Replies: 1 comment
-
Posted at 2018-01-14 by @MaBecker Strange, I have several i2c devices running without problems, please send the error output. Posted at 2018-01-14 by DrAzzy 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! Posted at 2018-01-15 by DrAzzy 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 Posted at 2018-01-16 by DrAzzy 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. Posted at 2018-01-17 by DrAzzy 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) Posted at 2018-01-17 by @MaBecker add Posted at 2018-01-17 by @MaBecker Please share a link where to buy those EEPROM modules Posted at 2018-01-17 by DrAzzy 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 Posted at 2018-01-18 by Frida 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
Posted at 2018-01-18 by @MaBecker Thanks for sharing this test 👍🏻 Posted at 2018-01-18 by DrAzzy 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) Posted at 2018-01-19 by DrAzzy Just tested and confirmed that the difference is NOT bitrate being set - I get the same results either way. Posted at 2018-01-19 by DrAzzy Okay, did some more testing here: With software I2C, this just plain doesnt work. On an official Espruino Pico:
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...
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! Posted at 2018-01-19 by DrAzzy 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!)
Posted at 2018-01-19 by @MaBecker It is time to use a logic analyser. Posted at 2018-01-19 by SergeP And may be it is time to check power supply :) Posted at 2018-01-19 by Frida I have tried both with soft and hard on a pico also, but I get no differense.
Posted at 2018-01-19 by DrAzzy What hardware are you using? What address are you reading/writing to? Was that with 1v95? Posted at 2018-01-19 by @MaBecker @drazzy See #10 Posted at 2018-01-21 by DrAzzy 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. Posted at 2018-01-21 by @allObjects @gfwilliams, 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... Posted at 2018-01-21 by DrAzzy 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. Posted at 2018-01-22 by @gfwilliams @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. Posted at 2018-01-22 by @MaBecker Thanks Gordon, will test this later Posted at 2018-01-22 by Frida Downloaded from github yesterday, and compiled on linux.
This is my test setup. Attachments: Posted at 2018-01-24 by DrAzzy Frida - look at your test results again - your logs above show the problem occuring! You started with the first two bytes on the EEPROM being [99,55], then you wrote [55,99] to those bytes - and then read it back out and those two bytes were still [99,55] - just like what I see: Write doesn't work! Posted at 2018-01-24 by DrAzzy
the waveforms look better on the scope - but I still can't get it to work correctly, and now I don't really understand why. Same symptoms though. I can't figure out why it's not working - especially because, as I mentioned, it doesn't fail with the scope connected. I'm not sure what's going on with the Software I2C. When using I2Ctouse=new I2C({scl:5,sda:4,bitrate:100000}); my scope refuses to trigger at all off of any I2C conditions. With the I2C triggering off, I don't see any signal going by at all when using software I2C... Posted at 2018-01-24 by @MaBecker Paul is writing to offset 2 Posted at 2018-01-24 by Frida Tried today with an atmlu016 on breadboard, without pullup resistors and without capacitor. Can not see any problems here.
Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-01-14 by DrAzzy
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!
On 1v92:
On 1v91:
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?!
Beta Was this translation helpful? Give feedback.
All reactions