cancel
Showing results for 
Search instead for 
Did you mean: 

BNO085 not working with STM32L433RC-P nucleo board

DUBEYISM
Associate

Dear Support Team,

I hope this message finds you well.

I am currently working on a project where I am trying to interface your BNO085 IMU module with an STM32L433RC-P Nucleo board. Despite numerous attempts, I have not been able to retrieve any meaningful data from the sensor.

Here are some of the key points of what I’ve tried so far:

I’m using I²C (also tested with UART) for communication.

Verified all hardware connections and logic level compatibility (3.3V).

Tried using both polling and interrupt-based approaches with STM32 HAL.

I have already tested the sensor separately with Arduino, and it works fine.

I also attempted different initialization sequences and delays, but the sensor remains unresponsive on STM32.

I would appreciate it if you could help guide me with any known compatibility issues or suggestions specific to using the BNO085 with STM32 microcontrollers. If you have any example code, documentation, or tips for STM32 integration, it would be immensely helpful.

Looking forward to your support.

5 REPLIES 5
Andrew Neil
Super User

Welcome to the forum.

You need to give some more detail - please see: How to write your question to maximize your chances to find a solution.

Specifically:

  • A schematic of your connections. Some good, clear photos also help
  • The code you've tried - see How to insert source code
  • What debugging have you done; eg, scope or analyser traces of the comms

 


@DUBEYISM wrote:

your (sic?) BNO085 IMU module 


The BNO085 isn't an ST product ?

https://www.ceva-ip.com/product/bno-9-axis-imu/ - have you looked there for software drivers?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Is the I2C address of the BNO085 shifted one bit left to use it  with HAL?  eg( bnodev.dev_addr=BNO085_I2C_ADDR1<<1; )

Andrew Neil
Super User

@DUBEYISM wrote:

I’m using I²C (also tested with UART) for communication..


If it supports UART, the best and easiest way to start is by connecting it to a terminal where you can send commands manually, and observe the responses - without all the complications and uncertainties of embedded firmware.

 

Then, once you've practiced and got familiar with what commands to send, and how the device responds, you'll be equipped to implement that in the STM32.

 

Similarly on the STM32, start by connecting it to a terminal where you can easily test that your code sends and receives data...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

I am using adafruit bno085 breakout board and it is working fine when used with arduino it is working fine but when i am trying to use it with nucleo board its not working 

 


@DUBEYISM wrote:

I am using adafruit bno085 breakout board  


You mean this: https://www.adafruit.com/product/4754 ?

Please always give a link to 3rd-party products - so that we can be sure what you're referring to.

Does it provide pull-ups?

Again, please show:

  • A schematic of your connections. Some good, clear photos also help
  • The code you've tried - see How to insert source code
  • What debugging have you done; eg, scope or analyser traces of the comms

As @Vangelis Fortounas said, are you sure that you have the correct I2C address and that you are presenting it correctly?

See this and this.

 


@DUBEYISM wrote:

it is working fine when used with arduino it is working fine


So compare & contrast your Arduino setup with your Nucleo setup.

The presentation of the I2C address is certainly a thing that could differ...

Put an oscilloscope on the I2C lines - are they clean & working ?

Put an analyser on the I2C bus - is the Nucleo sending the right stuff ?

 

Do you even get an ACK from the device?

You can check with HAL_I2C_IsDeviceReady

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.