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.
Question
Aaron
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:
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:
https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview
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.
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.
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:
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
Link to comment
Share on other sites
8 answers to this question
Recommended Posts
Archived
This topic is now archived and is closed to further replies.