BNO055 power on reset issues

[brentbop]

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).

[jbthompson]

Hi, I believe we might be experiencing this issue as well.

We have 4 custom boards using the BNO055 (no external crystal) and 2 of them seem to be having the reset issue while the rest behave just fine.

Is this clock issue consistent or intermittent? 

Thank you.

[o_o]

It is currently unclear if the issue is consistent or not. The text from the official Microchip Errata is not very precise. See section 1.5.7

[jbthompson]

We've updated our design to include an external crystal to mitigate the power on reset issue.

We did not use the same crystal as the bosch bno055 shuttle board since it was too large for our design but instead went with a smaller  2 pin crystal oscillator (32.678khz) with PN: FC-135R32.7680KA-AG3

Is there a particular reason Bosch went with the large tuning fork oscillator? PN: MS1V-T1K 32.768kHz 7pF +/-20PPM TA.

Attached is our schematic for the BNO055. We would really like to get this right the second time around so any help verifying this design would be greately appreciated!

[o_o]

jbthompson,

Crystal selection is up to you, there are no particular reasons for the selection of that specific part number other than general availability and cost at the time.

-Pin #10 is a digital output that indicates when the part is executing bootloader code. Connecting it to GND will effectively create a short-circuit at every power-on.
-Pin #4 is required to be connected to your MCU for firmware upgrade in the field. At the moment Bosch does have an updated firmware available, but this is likely to change in the future.
-Pin #9 Atmel changed the recommendation for capacitance on the CAP pin to >800nF. We have yet to update our own datasheet, but the recommended value is now 1uF
-Make sure that your 3V3 net have enough capacitance somewhere else on the PCB. The capacitors in your snapshot are good enough for local decoupling, but >1uF total capacitance is also required.

[jbthompson]

I see, ok this is great feedback. Thank you very much 🙂