Clipping a Tek A6302 Hall effect current probe around the I2C SCL line between a Raspberry Pi and an Adafruit BNO055 sensor breakout board:
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:
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.
5 thoughts on “Raspberry Pi I2C vs. Bosch BNO055 Clock Stretching: SCL Current Visualization”
That’s cool, actually getting to SEE who’s pulling the bus and when!
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 …
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
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.
Comments are closed.