• 0
Aaron

Issue with BNO055 sensor on uC32 via I2C

Question

Good evening! I am trying to use an Adafruit BNO055 breakout board with a ChipKit uC32 board, but there’s some kind of underlying bug causing the initialization code to fail. I’ve tracked it down to how the reset of the BNO055 is happening, but I’ve hit a wall at how to go deeper. Any advice would be welcome.

Hardware used:

  • Adafruit Feather Bluefruit LE
  • Digilent ChipKit uC32
  • Adafruit BNO055 orientation board breakout
  • Breadboard, wires, etc. Photos of hardware setup attached.

To start, I tested using the BNO055 and the Adafruit sensorapi example sketch on an Adafruit Bluefruit LE via the I2C connection. This worked just fine. I've used it for other projects in the past, so that's old hat:

 

Then, when I first tested the uC32 with the normal ChipKit-core distribution found via the ChipKit-core url, the I2C implementation was broken. None of the 3 different I2C sensors I had worked. After following the instructions to update ChipKit-core to 1.1.0-13 to fix I2C bug, as suggested below, I as able to connect to devices via I2C:

Note: I did set JP6 and JP8 to enable the I2C interface on the uC32.

Tested ChipKit uC32 using the I2C interfaces on the Adafruit BME280 and Si1145 breakout boards. Both worked just fine. Data was read and written properly.

Unfortunately, when connecting the BNO055 orientation board from here:

The board is recognized (by the device ID of 0xA0), but then the ChipKit uC32 hangs after first println in the sensorapi example sketch. It goes into the bno.begin() call and never returns.

Since I can’t do any deeper debugging in the main library, I copied out the BNO055 library (called it C_BNO055) and built against my version. Started with no changes other than the name of the library, include guards, and filenames. Worked just fine on Bluefruit LE, but exhibited the same issues on the uC32.

  • My source code for the library modified for testing is attached to this post.

I had combined the three breakout boards into a single program. This worked just fine on the Bleufruit LE, and it accessed all three sensors without issue, but the same bno.begin() call would hang everything.

So, I stripped out the other sensors and tested with debugging messages in my custom bno.begin() definition found in C_BNO055.cpp.

The code executes until the first BNO055 reset is attempted. Writing 0x20 to the BNO055_SYS_TRIGGER_ADDR resets the sensor. This loop then waits for the device to return 0xA0 for the chip ID, which indicates that it's ready to be used again.

  Serial.println("  [x] Doing a reset and waiting for the address to stabilize.");
  write8(BNO055_SYS_TRIGGER_ADDR, 0x20);
  while (read8(BNO055_CHIP_ID_ADDR) != BNO055_ID)
  {
    Serial.print("  [x] Waiting for BNO055 to reset. ADDR of: ");
    Serial.println(read8(BNO055_CHIP_ID_ADDR), HEX);
    delay(10);
  }
  delay(50);
  Serial.print("  [x] BNO055 address is now: ");
  Serial.println(read8(BNO055_CHIP_ID_ADDR), HEX);

 

That loop runs about 8 times (see attached screenshot) for the ChipKit uC32, then just stops. Every read it gets an ID of 0x00 (zero).

 

When the same code is run on the Bluefruit LE, it gets an ID of 0xFF until the board resets (see attached screenshot). Then it gets 0xA0 like it should and continues execution, and my larger program is able to read/write to the BNO055 and other sensors on the same I2C bus.

 

I believe there’s some kind of issue in the ChipKit-core implementation for I2C that’s being exposed by the series of calls leading up to the reset of the BNO055 board. I’m not sure how to proceed at debugging or testing the system. Any advice or investigation would be welcome.

I have:

  •   Changed the I2C address of the BNO055 by connecting the ADR pin to Vcc and changing the address in the .h file. Worked for Bluefruit, not for uC32.

  •   Commented out that address check and added in a delay(300) call. While the code progressed, it crashed when trying to access other I2C devices in loop().

  •   Tried a similar test on a ChipKit MX3ck board with the same results.

  •   I’ve tried re-wiring the board/jumpers and testing my solder joints.

 

I'm trying to get this board working on the uC32 as part of the sensor package we're building for the WSU Aerospace Club's rocket. If you'd like me to bring my hardware for testing to Digilent, just let me know via email and I'd gladly cross town to get some help.

Thank you for your time.

    -- Aaron Crandall

 

 

Adafruit Bluefruit BNO55 Custom library output.PNG

Adafruit BNO055 sensorapi output.PNG

Chipkit BNO055 HW setup.jpg

ChipKit BNO055 sensorapi output.PNG

ChipKit BNO55 Custom library output.PNG

FeatherBoard HW Setup.jpg

Share this post


Link to post
Share on other sites

8 answers to this question

Recommended Posts

  • 0

Greetings! Follow up with more information about this issue.

On another forum, it was pointed out to me that the BNO055 chip uses clock stretching during its I2C communications. This means the slave device can hold the clock line low, which should make the master wait for the data to be ready. Does anyone know if the ChipKit-core 1.1.0-13 release implements clock stretching?

Thank you.

Share this post


Link to post
Share on other sites
  • 0

Hi Aaron,

I apologize for not getting back to you sooner. Looking through the library code on GIthub for chipKIT Core (link here), it seems to me that what you are running into is that the Wire library chipKIT core as well as the DTWI library do not share the same functions as the Arudino Wire library. So essentially, when the bno.begin function is called it then starts using write8, read8, and setClockStretchLimit commands which are not functions inside of the chipKIT libraries, causing your code to hang.

On the other hand, the DTWI library does appear to support clock stretching (or at least there are lines that deal with clock stretching inside of the Cpp library without calling any functions), but again, they just don't use the same function names.

So, I guess then there are two different approaches to solve this. The first would be to trick the compiler into using the Arudino Wire library rather than the chipKIT one designed for MPIDE (I presume by specifying more of the path file in the #include line) and hope everything works nicely, but I'm not sure there is avr code that the compiler would flip out over for the chipKIT board though).

The other would be to change the functions that were called in the BNO055 library to the chipKIT Wire (not DTWI specifically) library function calls (looking through the example code and other files on the Github here) which seem to be begin, beginTransmission, write, read, requestFrom and others. (It also looks like send and receive are still valid, they just call write and read though). However, it doesn't appear to have any clock stretching functions, so you may want to run at just a slightly slower pace than the maximum clock rate to get around that since I don't know if the DTWI library that is included in the Wire.cpp will take care of it for you or not.

Let me know if you have any questions.

Thanks,
JColvin

Share this post


Link to post
Share on other sites
  • 0

JColvin,

Thank you for the response. I'll see which way seems to make sense. Checking the Arduino IDE library will be quick, and I pretty much presume will have trouble, but it's an easy check.

Rewriting some of the API calls is probably the proper route, so I'll let you know how it goes.

Share this post


Link to post
Share on other sites
  • 0

Hi Aaron,

I am trying to couple a Feather M0 with a BNO055 and I am using adafruit libraries but for some reason Feather does not detect BNO055. Could you please provide some insight since you have already done that successfully? Thank you.

Share this post


Link to post
Share on other sites
  • 0

BradJ,

  I have used the BNO055 successfully on several Arduino boards, though not with the Feather M0, only the Feather 32u4 boards. The primary thing to watch for is the wiring. Making sure you have both the SCL and SDA wires in the right order, plus VCC and GND. If that all looks good, I would check another I2C board with your Feather M0, then try a different Arduino if you've got one to verify that both the Feather and the BNO boards are working.

  If that all fails, then you might need to dig around to see if the Feather M0's libraries don't work for some reason, but it's the last place I'd check.

  Good luck with the project. The BNO055 board is a very nice piece of gear to use for all kinds of IMU kinds of projects.

Share this post


Link to post
Share on other sites
  • 0

Thanks for your reply. I ended up installing pullup resistors on SCL and SDA as mentioned by gammaburst in here: https://forums.adafruit.com/viewtopic.php?f=19&t=113148 and by adafruit in here: https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/faqs Good thing is I got it to work and communicate with Feather M0 but I still need to figure out a few more details. As you said, BNO055 is a nice and powerful unit.

Share this post


Link to post
Share on other sites
  • 0

BradJ - I'm glad you figured it out.

You'll find that some boards already have the pullup resistors in place, so sometimes they're needed and sometimes they're not. It's always worth checking the documents and schematics to make sure they're in place so the I2C bus operates properly.

If this one is solved, are you able to mark it or change the title to have [SOLVED] in it? Future googlers will appreciate it.

Share this post


Link to post
Share on other sites
  • 0

@Aaron I'm currently experiencing the exact same issue you originally reported. I'm using a chipKIT CMOD (CK1) with the Adafruit BNO055 sensor. I have the most up-to-date installation of the Arduino IDE and the chipkit libraries.

If you don't mind me asking, I don't think the answer to this post was ever added. On your May 9, 2016 comment you mentioned you were going to try a few things, but I don't see any follow-up as to whether you were able to use the sensor with the chipkit or not.

Do you recall if you were able to fix the issue? And how? I'm going to have time later in the week to tinker with this but thought of asking in case anyone has any answer... I think the things to try would be:

  1. Add the extra resistors to the I2C lines (as per Adafruit's FAQ)
  2. Point to the Arduino Wire library instead
  3. Rewrite the examples with chipkit-specific Wire library

Any help is very welcomed... cheers!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now