I2C Clock Stretching

[brotherdust]

Hi there Pycom folks! Hope you had a restful weekend!

I was hoping you could shed some light on something I've been banging my head on today. I am trying to implement the Bosch BNO055 IMU fusion sensor based on the Adafruit breakout: https://www.adafruit.com/products/2472

What's happening is that I can't get the sensor to communicate on the I2C bus at baud rates any higher than 1000 (ugh). According to the datasheet (see table 4.8: I2C Timings), the sensor supports fast mode (400,000).

After going through the datasheet a few more times, the only thing that really stands out to me is that this sensor uses I2C "clock stretching". This correlates with how the official Adafruit Arduino driver sets up the sensor: https://github.com/adafruit/Adafruit_BNO055/blob/master/Adafruit_BNO055.cpp#L60

The stock I2C driver in micropython seems to know about clock stretching, too:
https://github.com/pycom/pycom-micropython/blob/master/extmod/machine_i2c.c#L57

But, in the ESP32 I2C driver, it would seem these functions are completely (and conspicuously) absent. According to http://www.i2c-bus.org/clock-stretching/, "Clock stretching sounds a bit odd but is common practice."

So, my esteemed Pycom team, do you have a suggested workaround or any plans to implement this? It would seem, at least according to the available data, that the I2C functions for ESP32 would not be complete without it.

[abilio]

Hi @brotherdust, we haven't implemented clock stretching yet, I'll take note of your request. If you want, you can also go and add a feature request on github, so you'll get status updates :)

[brotherdust]

@abilio, thanks for the info! Feature requests are placed under issues, correct? On another note, is clock stretching any different for the ESP32? Or, to rephrase, is there any technical reason why it hasn't been done?

[abilio]

@brotherdust, our plan is to first complete the basic functionality of the board, and then go into specific details like this one in a second round. Of course, people's requests are also important :)

[brotherdust]

@abilio, sounds good to me. Thanks again!

[Shaun]

The I2C clock frequency setting is also not accurate.

baudrate=400000 results in an actual clock of 297kHz
baudrate=100000 results in an actual clock of 87.6kHz
baudrate=40000 results in an actual clock of 39kHz

[pedro]

any news on this topic?

[jmarcelino]

@pedro
The new firmware 1.7.5.b2 (like previous 1.7.5.b1) has hardware I2C and should support clock line stretching

Update: maybe I spoke too soon: https://github.com/espressif/esp-idf/issues/323 not sure if this means no clock stretching at all or just when I2C is slave

[Eric24]

@jmarcelino Hmmm. It looks like the '323' issue applies to I2C slave mode only, but some clarification would be nice. We have some testing to do with the new I2C HW support (and we were having troubles with certain I2C peripherals when it comes to clock stretching); I'll see if we can do some specific tests with and without clock stretching to see how the HW I2C handles it.

[livius]

@Eric24
look at current firmware 1.7.6 there are some i2c releated fixes for hardware init

[digitalfalcon]

Any news on this topic? I would also like to get the Bosch BNO055 IMU working with a Lopy.

[jmarcelino]

@digitalfalcon
Have you tried it and it doesn't work? This an old topic, a lot has changed since

[digitalfalcon]

@jmarcelino As far as I can tell it's still not working.

[jmarcelino]

@digitalfalcon
Most of the issues seem to be around what pull-ups (if any) are used, how is your sensor connected?

[Eric24]

@digitalfalcon Just to confirm, you're using I2C buss 0 or 1 (the hardware busses), right? Bus 2 is a software "bit banged" bus, which will still not support clock stretching.

PS - I can not confirm that addition of the hardware I2C bus support solved the clock stretching problems, as I've not yet gotten back to testing that particular aspect of our project.

[digitalfalcon]

@Eric24 @jmarcelino I2C Clock Stretching is working on the LoPy. Sorry for the false alarm.

[Colateral]

@abilio Do you have an update on clock stretching issue. There is also a new sensor SCD30 (from Sensiron) that face the same clock stretching issue. We can not see device address 0x61 on the BUS bus(0) on (P22, SCL=P23) nor bus(1) on (P9, SCL=P8). Sensor works fine ESP32 (arduino dev)
Any workaround for this on pycom?

[Strevens]

@Colateral I had the same issue with the SCD30. The SCD30 also supports modbus as well as I2C, which is how I got the SCD30 to work with the lopy

[tiborrr]

@Strevens great you got it to work. If you have time, could you please take a look at my topic at the following: https://forum.pycom.io/topic/6141/scd30-oserror-i2c-bus-error