BMI088 gyroscope does not communicate properly via I2C

[jpittner]

Hello,

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

[kgoveas]

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.

Regards,
kgoveas

[o_o]

I can confirm these laser markings match BMI088.

 wrote:

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.

[jpittner]

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

http://www.pittnerovi.com/jiri/hobby/electronics/avionics

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.

[jpittner · Accepted solution]

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.