Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BNO055 unable to read multiple bytes continuously in I2C at 400Khz or 100Khz

    BNO055 unable to read multiple bytes continuously in I2C at 400Khz or 100Khz

    New Poster

    In my application we have used BNO055 as 1 of the peripherals along with other 2 peripherals, where I'm not able to do multiple bytes read and write continuously.Whereas I'm able to read and write multiple bytes for other two peripherals continuously.

    Ex:- Magnetometer is set to 30Hz bandwidth,  AccMag mode is set and I2C is kept at 400Khz or 100Khz.

    Whenever the device which contains the BNO055 is kept stable I'm able to read the data continuously even while the multiple byte read method is used.

    When the device is moved little I don't get the data continuous instead there will be no proper transactions in the bus, not only the Magnetometer readings im not able to read the chip Id and next bytes in the multibyte read method.

    As the number of bytes read increases the transactions on the bus ceases.Ex:- If 2 byte read i get most data if it increases to 4 bytes the continuous data read ceases.

    But if a single byte read is performed I'm able to read the data at 30Hz frequency.

    5 REPLIES 5

    Community Moderator
    Community Moderator

    Please see the logic analyzer result i captured with APP2.0 for BNO055 ACCMAG mode and sensor is in motion status. 

    From the plotter,  you can see the multiple reads are correct. 

    The address is 0x28 also when i capture the plotter. 

    When i open your plotter of non-countious,  i saw the following pattern.  after first reading,  the sensor already send ACK.  this means slave already release the I2C bus.  but host didn't send new clock.  Instead of it,  both SDA and SCL are pull to high at the end. 

    Clock stretch is slave hold SCK to low until it is ready.  you can also see in your log,  the ACK will be sent from slave quite long time after sending last bit of registers.  then host directly start next clock for reading. 

    Also after first byte get ACK,  next clock comes with a new START signal for reading from address 0x73 with NAK (280 ms later) twice,  then go back to 0x28 (BNO055 address).  

    Can you check if you have any other high pirority interrupt with I2C bus communication at your platform?