Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BMI088 gyroscope does not communicate properly via I2C

    BMI088 gyroscope does not communicate properly via I2C



    I have been trying to use BMI088, communicating via I2C at 400kHz.
    The accelerometer part of the chip works perfectly, reading our correct acceleration values,

    but I get completely wrong results from the gyroscope.

    Already the chip ID register #0 reads out 0x0a, while it should
    be 0x0f according to the datasheet and the registers with angular
    velocities read out highly fluctuating 'random' numbers with the sensor lying on the table.

    I have tried two modules, first a module obtained from SEEED studio, and later
    the original Bosch shuttle board with BMI088, purchased from Mouser, connected for I2C communication according to the datasheet.

    (I was afraid the chinese one might be a poor clone of the chip.)

    However, both modules did show the same problem. The code marking on the chips is:
    365/P1827/001 and 365/P1827/008 respectively.

    I am using STM32F37 MCU and code based on STM's library for I2C and

    several other I2C sensors worked well in the setup.

    Since the I2C communication with the BMI088 accelerometer works perfectly,
    I do not see where could be the problem  with my I2C connection/software.
    I am using I2C address 0x19 for acc. and 0x69 for gyro (with appropriate
    pullups), 3V3 power.
    So I am really puzzled with the problem. Do you have any ideas?

    With best regards,
    Jiri Pittner


    5 REPLIES 5

    Community Moderator
    Community Moderator

    Hi Jiri,

    Can you briefly describe your connection diagram and code used to verify it? I will try to duplicate your setup and give feedback about the same.




    I can confirm these laser markings match BMI088.


    Already the chip ID register #0 reads out 0x0a, while it should
    be 0x0f according to the datasheet 

    Before investigating any furhter, you should check with a logic analyzer that the bus protocol is propwerly decoded by your MCU. Invalid chip_id is a pretty big deal, and this is not something that is possible without communication issues.

    If the communication cannot be trusted, neiter is the data.


    The complete schematics, source code,  and description of the project is at

    Originally I connected the SEEED BMI088 module (which contains 3v3/5v level shifters and 3v3 regulator) to 5V-level I2C bus,

    connector P806.  I have then seen that the level shifters on the module are a bit slow, so I removed and jumped them them, as well as the 3v3 regulator

    from the module and connected it to 3V3-level I2C bus, connector P803. Since it did not help, I was afraid the SEEED module might

    contain a Chinese clone and I purchased the shuttle board from Mouser and connected it for I2C communication exactly according to

    the datasheed and to the 3V3-level I2C bus, connector P803. Both modules have the same problem - communication with accelerometer

    works perfectly, while gyroscope gives already bad chip_id and garbage. It could be that gyroscope is more sensitive to exact timing or other signal

    integrity issues on the I2C bus, while for accelerator it is OK. I have understood that BMI088 are basically 2 totally independent chips in one package.

    Another component on the same I2C bus which I succesfully tested was magnetometer HMC5883, connected to P801, so it must be something

    rather subtle. I plan to look in detail on the signals with my old rigol scope (unfortunatelly I have no professional logic analyzer for easy decoding of busses like I2C). I may try also to connect the module to a different CPU, like raspberry pi, and try I2C there, or I could try SPI communication (but this I do not like since

    I would need 2 chipselect signals not available at my present board). Anyway  I would be thankful for any hints for debugging, in particular if you happen

    to have a STM32(F37) development board and could try I2C communication with this particular MCU to reproduce the issue.

    I found it eventually - the culprit was a fault 24C16 eeprom on the same bus, which obviously confused its address

    and entered into the communication, spoiling it. After replacement by another eeprom (different size/manufacturer) it all works fine.