Raspberry Pi I2C vs. Bosch BNO055 Clock Stretching: SCL Current Visualization

Clipping a Tek A6302 Hall effect current probe around the I2C SCL line between a Raspberry Pi and an Adafruit BNO055 sensor breakout board:

RPi I2C SCL current probe

RPi I2C SCL current probe

The arrow on the probe points toward the Pi, so (conventional) current flowing through the 10 kΩ pulldown resistors into the Pi will be positive and current flowing from the Pi into the BNO055 will be negative.

The top (yellow, analog) trace shows the current (1 mA/div) flowing through SCL:

I2C 100kHz - BNO055 SCL 1 mA-div - B7 Rd error

I2C 100kHz – BNO055 SCL 1 mA-div – B7 Rd error

The four distinct current levels show the clock state:

  • +1 mA = Pi pulling low
  • 0 mA = SCL high, no sinks active
  • -1 mA = Pi and BNO055 pulling low (clock stretching!)
  • -2 mA = BNO055 pulling low

The 0 mA baseline isn’t exactly at zero, because the AM502 amp has thermal drift like you wouldn’t believe, particularly with the gain cranked to 1 mA/div.

The probe + amp calibration seems slightly bogus: a 3.3 V supply pulled to ground at the Pi through the 10 kΩ resistor on the BNO055 breakout should deliver 0.33 mA, not nearly 1 mA. It’s close enough for now; I should cook up a probe calibration fixture.

The BNO055 sinks about 2 mA, which suggests a 1.6 kΩ pullup to 3.3 V on the Pi. Although you’re supposed to have one pullup on the I2C bus lines, some casual searching with the obvious keywords shows the Pi has 1.8 kΩ resistors on board.

Huh. Who knew?

So Adafruit’s advice to add 2.2 or 3.3 kΩ pullups at the BNO055 (admittedly, for a Beaglebone, not a Pi, but I suspect some folks miss such details) lowers the parallel resistance to about 1 kΩ, just about as low as you should go. It is not obvious to me that reducing the resistance by a factor of two will change the bus timing by enough to rescue a marginal situation (stipulated: the Pi is beyond marginal). TI has a useful App Note  on the subject of I2C pull up resistance calculations.

Anyhow, I now have a way to examine the Pi’s clock stretching bugginess in grim detail, which is the point of this exercise. Note that the hardware bug has remained un-fixed (probably tagged WONTFIX) in all Pi silicon versions, including the Pi 3 as of 2018.


  1. #1 by madbodger on 2018-09-03 - 09:24

    That’s cool, actually getting to SEE who’s pulling the bus and when!

    • #2 by Ed on 2018-09-03 - 12:39

      I absolutely did not expect to see current going in both directions, because I expected one terminator on the far end. Verily: hell hath no fury like that of an unjustified assumption …

  2. #3 by scruss2 on 2018-09-03 - 20:36

    The line from the Foundation when this comes up on the bulletin board seems to be that the SoC (all of ’em) doesn’t support clock stretching, and if you need it, use software I²C

    • #4 by Ed on 2018-09-04 - 11:55

      Yup, good old bit-banging FTW.

      If you were expecting (or need) a reasonable transfer speed with low CPU load, then a Pi just isn’t the right hammer for the job. Which is a shame, because it almost works.

  1. Raspberry Pi I2C Bus Timing vs. BNO055 Clock Stretching | The Smell of Molten Projects in the Morning