I'm trying to resolve a persistent issue I'm having with a BNO055 IMU on a custom PCBA. I'm communicating via I2C and am experiencing different behavior between device reset (using "Power on Reset" reset pin) with and without power cycling. In situations where I reprogram my MCU and start directly into my application code without power cycling, the IMU will respond with NAKs to any and all read/write messages. If I power-cycle the system, it works correctly. In both scenarios I'm pulling the reset pin low for ~25ms, pulling the reset pin high, and then waiting for ~725ms before initiating I2C communication. All other signals (COM1, COM2, PS0, PS1, nBOOT_LOAD_PIN) are connected to VDD or GND directly or through a 10kΩ resistor. A partial schematic is attached.
The firmware is heavily based upon the BNO055 XPlained Pro example code and is being run on a SAMD21G18A.
Can you help me to understand the differences in behavior between device reset for the BNO055 from an 'unknown' state and from a power-on state? Do I need to set the SDA/SCL lines to a certain level before/during/after Power on Reset?
Attached are logic analyzer screenshots of the system failing without power cycle (BNO055_noPowerCycle.png) and working with power cycle (BNO055_withPowerCycle.png), as well as a partial schematic (BNO055_sch.png).
I've tried bit-banging an empty I2C frame in case an I2C transmission was interrupted by the MCU being reprogrammed (the clumsy approach here: i2c-bus.org) but haven't seen any improvement from any number of clock pulses - 8, 9, 10, 16, 32.
I too am seeing this issue, the BNO055 works fine on on a power cycle, but issuing a reset by I2C seems to lock up the sensor.
Did you get this to work with help from Bosch? Thanks for any help in advance.
Hi chrisc and brentpop,
We recently discovered a bug in the reset process when the BNO055 expects a crystal to be connected. This means that the BNO055 will fail to reset if there is no external crystal attached.
To prevent the issue: