I2C clock stretching supported?

[evoortman]

Hi,
I am struggling with the communication of a BNO055 9-DOF sensor from Bosch. https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bno055-ds000.pdf
On a logic analyzer I sometimes see the bytes shifting one bit.
The datasheet states the following on page 100 : The BNO055 supports I²C standard mode and fast mode, only 7-bit address mode is supported. The BNO055 I²C interface uses clock stretching.
My questions are: could this be related to clock stretching? Is clock stretching supported by the compiler?

Erik

[david]

Hi Erik,
The sensor may be able to apply clock stretching but would only do so if overwhelmed by the micro's I2C clock speed. I think if you're applying the correct I2C bus speed for that sensor you would be unlikely to observe it happening.
Are there other devices on the same bus? A slower device may hold the clock down but I think it would only apply to the addressing stage.  Once your sensor is selected any other slower device wouldn't care (I think).
If you're having trouble even addressing the sensor then keep in mind that the I2C address given is 7 bits but those 7 bits get shifted right when the read or write bit is added.   It seems to cause so much confusion.
For example I2C address given as 0x3c = $3C = %111100
I2C address + Write = 0x78 = $78 = %1111000
Good luck.  BTW - you may find some of the open source flight control software is supporting these devices if you want to wade through endless C or C++ software.....

Cheers,
David

[evoortman]

Thanks for the replay David.
My uC is running at 4 MHz and I have declared Slow_Bus ON. This results in a 20 kHz I2C clock which is already quite slow. But I'll try @ 1MHz uC clock to see what happens.
The BNO055's 7-bit address is $ 28. I translated this to $ 50 ($ 28 + RW bit), so this should be correct.
If I don't get it working I'll post some code and analyzer images.

Erik

[tumbleweed]

Actually, it's fairly common for a uC-based I2C slave to use clock stretching so that the slave can have time to process the command (be it a write or read) before allowing transfers to continue.

This isn't related to the actual clock speed, so slowing it down may not do much of anything.

[RayEllam]

If your using HBUS commands in proton then try the bit banging method using BUS commands. There are issues with SOME
PICS using the hardware modules.

[david]

Well at that speed it's unlikely to be clock related and the address + write of $50 looks correct - you should be seeing an acknowledge from the device . If you have logic analyzer plots it implies the HBUS hardware is configured correctly and working.  Any more clues?

Cheers,
David

[tumbleweed]

If the slave is clock-stretching, this should normally occur during the 9th clock (ACK bit time).

If you're using the MSSP hardware (ie HBUS commands), this would be transparent to you... the MSSP peripheral should handle it for you.
If you're using bit-banged commands (ie BUSOUT/BUSIN), I don't believe the routines check to see if the slave is clock-stretching, so these likely won't work.

[evoortman]

If you're using the MSSP hardware (ie HBUS commands), this would be transparent to you... the MSSP peripheral should handle it for you.
If you're using bit-banged commands (ie BUSOUT/BUSIN), I don't believe the routines check to see if the slave is clock-stretching, so these likely won't work.

We where on the same page with this tought so i changed from bitbanging to Hbus and that did the job!

What I also saw with bitbanging is that the SDA line becomes high again for a short time between the clock pulses. I don't belive every slave will be happy with that.

Thanks everyone for all the support!

Erik

[tumbleweed]

What I also saw with bitbanging is that the SDA line becomes high again for a short time between the clock pulses. I don't belive every slave will be happy with that.

As long as that happens while SCL is low then that's ok. It's pretty typical for that to occur when the master releases the SDA pin (normally to let the slave assert ACK).

What's not allowed is for SDA to change while SCL is high since that'll look like a START or STOP.

[chris_cb_uk]

@evoortman did you have success with this sensor? I am looking at implementing this into a remote vehicle to give orientation information to the user.
Chris