VEML6075 I2C sensor not working with ESP32

[ladyada]

Using an Adafruit Feather ESP32 wired up to an Adafruit VEML6075. A user of our library noticed this here and I verified it with a few different libaries/examples for this sensor.
adafruit/Adafruit_VEML6075#2

It's repeating start and VEML's have had an odd i2c stack so its not terribly surprising
Test code: https://github.com/adafruit/Adafruit_VEML6075
Hardware: https://www.adafruit.com/product/3964
BSP: v1.0.0 from board manager, with Adafruit Feather ESP32 selected (but i really doubt this has to do with the hardware, probably any ESP32 board can be tested)

[stickbreaker]

Release 1.0.0 does not work when ReSTART operations are used. This error has been fixed in this GitHub dev repo.

When me-no-dev generates a new release the fix will be available through board manager.

Until then, you can manually apply the fixes by substituting the four i2c files from this repo:

• \cores\esp32\esp32-hal-i2c.h
• \cores\esp32\esp32-hal-i2c.c
• \libraries\Wire\src\Wire.h
• \libraries\Wire\src\Wire.cpp

Chuck.

[JasonMorris1]

thankyou. The sensor is working now! :). 👍 👍 🥇

[ladyada]

@me-no-dev hey me - is there anything blocking a minor release fix that we can help with? I2c repeated-start sensors are pretty common these days :)

[midnightmaker]

The above four files are a huge improvement for I2C. There was no communication with an MPU6050 - there is now! It's still very temperamental. I'm using the Doit.com ESP32 Dev Kit V1, trying the standard SDA/SCL pins and alternates, I find the behavior similarly challenged. Sometimes after the sensor has been working for a couple of minutes, the values freeze. At this point the clock and data lines are no longer active on the scope - clock stays high and data is low. At other times, the new firmware recovery works and the sensor communication is restored. Other times, only a hardware reset works.

Here is an example of a successful recovery:

[D][esp32-hal-i2c.c:1300] i2cProcQueue(): Gross Timeout Dead start=0xc4d5, end=0xc508, =51, max=51 error=1
[E][esp32-hal-i2c.c:314] i2cDumpI2c(): i2c=0x3ffc1030
[I][esp32-hal-i2c.c:315] i2cDumpI2c(): dev=0x60013000 date=0x16042000
[I][esp32-hal-i2c.c:317] i2cDumpI2c(): lock=0x3ffb21a8
[I][esp32-hal-i2c.c:319] i2cDumpI2c(): num=0
[I][esp32-hal-i2c.c:320] i2cDumpI2c(): mode=1
[I][esp32-hal-i2c.c:321] i2cDumpI2c(): stage=3
[I][esp32-hal-i2c.c:322] i2cDumpI2c(): error=1
[I][esp32-hal-i2c.c:323] i2cDumpI2c(): event=0x3ffb222c bits=200
[I][esp32-hal-i2c.c:324] i2cDumpI2c(): intr_handle=0x3ffb225c
[I][esp32-hal-i2c.c:325] i2cDumpI2c(): dq=0x3ffb2520
[I][esp32-hal-i2c.c:326] i2cDumpI2c(): queueCount=2
[I][esp32-hal-i2c.c:327] i2cDumpI2c(): queuePos=1
[I][esp32-hal-i2c.c:328] i2cDumpI2c(): errorByteCnt=0
[I][esp32-hal-i2c.c:329] i2cDumpI2c(): errorQueue=2
[I][esp32-hal-i2c.c:330] i2cDumpI2c(): debugFlags=0x00000000
[I][esp32-hal-i2c.c:349] i2cDumpInts(): Debug Buffer not Enabled
AcX = -6820 | AcY = -1328 | AcZ = -13344 | Tmp = 26.37 | GyX = -185 | GyY = -32513 | GyZ = 32639
[I][esp32-hal-i2c.c:1091] i2cProcQueue(): Bus busy, reinit
[W][esp32-hal-i2c.c:1363] i2cCheckLineState(): invalid state sda(14)=0, scl(27)=1
[D][esp32-hal-i2c.c:1371] i2cCheckLineState(): Recovered after 1 Cycles

There are other instances where the "Recovered After" Cycle count is 9 cycles, but mostly the count is 1.
There still seems to be a fundamental problem here. The sensor works flawlessly on my nrf52, Simblee and Arduino UNO boards. It is only on the ESP32 board that the issue appears. Any ideas?

The code sample is taken directly from the Arduino web site:

`// MPU-6050 Short Example Sketch
// By Arduino User JohnChi
// August 17, 2014
// Public Domain
#include<Wire.h>
const int MPU_addr = 0x68; // I2C address of the MPU-6050
int16_t AcX, AcY, AcZ, Tmp, GyX, GyY, GyZ;
void setup() {
pinMode(27, OPEN_DRAIN | INPUT | OUTPUT );
pinMode(14, OPEN_DRAIN | INPUT | OUTPUT );

Wire.begin( 14, 27, 100000);
Wire.beginTransmission(MPU_addr);
Wire.write(0x6B); // PWR_MGMT_1 register
Wire.write(0); // set to zero (wakes up the MPU-6050)
Wire.endTransmission(true);
Serial.begin(115200);
}
void loop() {
Wire.beginTransmission(MPU_addr);
Wire.write(0x3B); // starting with register 0x3B (ACCEL_XOUT_H)
Wire.endTransmission(false);
Wire.requestFrom(MPU_addr, 14, true); // request a total of 14 registers
AcX = Wire.read() << 8 | Wire.read(); // 0x3B (ACCEL_XOUT_H) & 0x3C (ACCEL_XOUT_L)
AcY = Wire.read() << 8 | Wire.read(); // 0x3D (ACCEL_YOUT_H) & 0x3E (ACCEL_YOUT_L)
AcZ = Wire.read() << 8 | Wire.read(); // 0x3F (ACCEL_ZOUT_H) & 0x40 (ACCEL_ZOUT_L)
Tmp = Wire.read() << 8 | Wire.read(); // 0x41 (TEMP_OUT_H) & 0x42 (TEMP_OUT_L)
GyX = Wire.read() << 8 | Wire.read(); // 0x43 (GYRO_XOUT_H) & 0x44 (GYRO_XOUT_L)
GyY = Wire.read() << 8 | Wire.read(); // 0x45 (GYRO_YOUT_H) & 0x46 (GYRO_YOUT_L)
GyZ = Wire.read() << 8 | Wire.read(); // 0x47 (GYRO_ZOUT_H) & 0x48 (GYRO_ZOUT_L)
Serial.print("AcX = "); Serial.print(AcX);
Serial.print(" | AcY = "); Serial.print(AcY);
Serial.print(" | AcZ = "); Serial.print(AcZ);
Serial.print(" | Tmp = "); Serial.print(Tmp / 340.00 + 36.53); //equation for temperature in degrees C from datasheet
Serial.print(" | GyX = "); Serial.print(GyX);
Serial.print(" | GyY = "); Serial.print(GyY);
Serial.print(" | GyZ = "); Serial.println(GyZ);
delay(100);
}
`

[lbernstone]

Please don't hijack the thread. Open a different thread if you have issues with a different device. Please use appropriate markup for console text and code. This thread is resolved(AFAICT), just waiting for a release version.

[stickbreaker]

@midnightmaker open a new issue, describe your hardware, when SDA is stuck low, something is driving it. The reset function in ESP32 I2C will always make the ESP32 stop driving SDA, the MPU6050 is usually the culprit for holding SDA low. With your error being GROSS timeout, this means the MPU6050 didn't answer, try increasing the timeout Wire.setTimeOut(milliseconds) the MPU6050 can be programmed to stretch SCL until it finishes a conversion. If the ESP32 times out, the MPU6050 still thinks it is in a read operation. Increase timeout.

If you want more help open a NEW issue.

Chuck.

[midnightmaker]

Apologies - I was not looking for help or trying to hijack the thread. I was trying to advise that the behavior of the I2C port was still erratic in a general sense on the ESP32 when compared with other Arduino hardware. However, with the explanation from Chuck above, a change to the timeout does indeed correct the periodic firmware reset behavior. My concern that there was still a general ESP32 I2C problem was misplaced. Thanks for the helpful comment Chuck.

[ladyada]

hiya @igrr @me-no-dev checking back on this, i noticed no commits in the last 6 weeks - is this repo still going to be developed & supported?

[me-no-dev]

@ladyada sorry, was preoccupied with other things. Have not really been in one place. I see no reason to throw "is this repo still going to be developed & supported". I am looking for ways to get some help on the repo. Will update IDF and cut a release.