VEML7700 with ARDUINO DUE BOARD

[paolovr970]

I tried using VEML7700 sensor with ARDUINO DUE (3.3v) via i2c but NO SUCCESS. Conversely, with ARDUINO UNO or ESP32 boards, everything goes OK. The sensor is seen by i2cscanner. DUE board has a pull-up resistor for SCL and SDA of 1.5k. Any idea of the solution? thanks

[PaulZC]

Hi @paolovr970 ,

The DUE has two I2C (TwoWire) ports:

Which one are you using? Perhaps you need to use Wire1 instead of Wire? Please try Wire1.begin(); and mySensor.begin(0x10, Wire1);

I hope this helps,
Paul

[paolovr970]

Thank you, PaulZC, but unfortunately, also on I2C1, it doesn't work. (on DUE I2C1 has not PULLUP resistor)
The sensor is seen by DUE (i2cscan for I2C1 is ok, and the sensor is seen).
When I run the sketch, the Lux returned are "0.0000". I also tried to change the configuration (50ms and sensitivity 1_8), but the sensor remains fixed to 100ms and x1.

Any other possible solution?

[PaulZC]

Hi @paolovr970 ,

I am seeing the same thing. The library examples work well on ESP32, but returns "0.000" on DUE...

I think it might be caused by I2C clock stretching, but I am not sure...

Until later,
Paul

[PaulZC]

Hi @paolovr970 ,

Here is the I2C start-up sequence on the DUE:

And here is the start-up sequence on the ESP32:

Note the small delays between each register read / write on the ESP32.

Looking in detail at the first write to register 0, here on DUE:

And here on ESP32:

Note how on the DUE, the SDA rising and falling edges are closely aligned to the falling edge of SCL. On ESP32, the SDA edges are offset by approximately 1/4 of a clock cycle.

From a TI document "Understanding the I2C Bus":

The critical thing is that "SDA line is stable while SCL line is high".

The DUE appears to be violating that. The SDA transitions are aligned with the falling edge of SCL.

This in turn could violate the t_HDDAT "Data hold time" of the VEML7700:

To me, this is a clear smoking gun...

I suggest you give up on the DUE, and go with the ESP32 instead...

Best wishes,
Paul

[PaulZC]

I am closing this because it seems that the root issue lies in the DUE hardware / firmware, not in this library.

Very best wishes,
Paul