BNO055 unstable interrupt pin at startup

[Gamli]

Hi,

We are having problems with the BNO055 on our product. This problem seems to be quite unstable and the frequency of its occurrence seems to vary between units. We are communicating with the sensor using UART and using external crystal oscillator and the imu fusion mode.

When the device is started (or rebooted) the BNO055 is initialized. The reset signal is followed by the interrupt pin going high until the BNO055 is ready. In our case we give it a certain time to be ready, and then we initialize it and start running it as it suits our application.

However - occasionally the interrupt pin seems to stay high for an unusually long time - in the case below it is more than 6 seconds (compared to a usual 500ms).
What we do when the sensor is not responding correctly, we wait a bit and try again. This happens 10 times and then we report an error. In this case, it works normally after these 6 seconds - but we cannot design our product expecting a 6 second wait to initialize this sensor.

Have you seen this or similar problem before? Any ideas what might be causing this? For information, we leave all interrupt related registers as default as we are not utilizing its functions for our application.

I attached a scope capture where the device is repeatedly rebooted thus resetting and initializing the BNO055 until the problem appears. Until the problem appears, everything seems to be working as expected and nothing unusual is happening before the interrupt pin stays high for this (relatively) large amount of time.

BR,
Gamli

[Gamli]

Hi,

In addition to the above problem: The BNO055 occasionally has another similar error, but while in normal operation when the host processor is reading data from the sensor. Suddenly the error seems to have a bus overrun error (0x07) followed by a 500ms off-time where the interrupt pin goes high, and it seems like the BNO055 is resetting itself thus losing its configuration. This seems to happen shortly after reset of the sensor, on the first minute of operation or something like that.

Again, this happens only occasionally but often enough that our product cannot operate safely - and handling this error dramatically decreases the quality of the product.

We are sampling the sensor every 10ms (at its data rate limit), and the occasional data not being ready would not be a big problem as long as we would get data at the next data reading. However, the unexpected reset and 500ms off-time is the big problem here.

Any ideas really appreciated!

/Hergils

[BSTRobin]

Hi Gamli,

From your description, we know that you use IMU mode and interrupt. Can you describe the complete sensor configuration?
Which interrupt trigger events have you configured
What is your application code like?
We need to know the above information in order to reproduce your question.

[Gamli]

Hi BSTRobin,

As the above information clearly states, I am NOT using the interrupts in my application. I leave that entirely untouched. All I want from the sensor is data. No other logic or functionality.

Our initialization routine is as follows:

• Set BNO to config mode
• Set BNO to power mode normal
• set to use external oscillator
•  fusion IMU mode, running on an external crystal oscillator, re-mapping the
• Remap axis value and sign
• Set operating mode to Fusion IMU mode.

We are then sampling values every 10ms, as mentioned above, which should be fine. I have tried decreasing the sampling rate with the same results.

Do you have any idea of what might be causing the sensor to be waiting/not ready for this amount of time?

/Gamli

[BSTRobin]

Hi Gamli,

1. You can try using the internal clock;
2. You can compare it with BNO055 shuttleboard if you have.

BNO055 is not recommended for use in new designs.