06-08-2022 02:10 PM - edited 06-08-2022 02:39 PM
I find that the BNO055 induces quite long I2C clock stretching. The BNO055 is running in normal power mode and DNOF mode. Below is the CALIB STATUS read once every 1.2 seconds. There is no other I2C traffic.
Below are some scope traces; These were all taken during the same test. It randomly occurs
Is this expected behaviour, or do I have an problem?
06-09-2022 04:39 AM
Hi Digisolve,
For I2C protocol, BNO055 is an I2C slave device, and the I2C clock is initiated by the I2C master(host side).
You could see the following I2C communication waveform on application board that has different clock waveform with your platform.
06-09-2022 10:29 AM
The I2C spec allows the slave to stretch the clock by holding it low. This is to allow slow slaves to slow the bus down until it's ready
In my code I've just added a signal (P0.1) which I drive high while while checking for the SCL signal to go high, then drive it low once SCL has gone high
#define NEGATE_SCL {SCL_DIR_ADDR = SCL_DIR_NEG; \
SCL_DAT_ADDR = SCL_DAT_NEG; \
stP0.B1 = 1; \
while(SCL_DAT_ADDR != SCL_DAT_NEG);} \
stP0.B1 = 0;
I think the below traces shows clearly that the BNO055 must be holding off (stretching) SCL as my P0.B1 signal is high during this time.
It doesn't always do it & I suspect it's fine, but it does seem quite long. I just want to be sure.
06-14-2022 03:13 PM
Please can I get some feedback. My client is chasing me daily. Thank you
06-27-2022 08:07 AM
Hi Digisolve,
After the I2C stop signal, the bus will be pulled high. You can try to read one byte at a time, then each byte read will generate a stop signal.
By the way, what impact does the current waveform have on your application?