Fixing BNO055 Sensor Issues With Zephyr RTOS

Aug 10, 2025 by Omar Yusuf 45 views

Troubleshooting BNO055 Sensor Compatibility Issues with Zephyr RTOS

Hey guys,

It sounds like you're running into some snags getting your BNO055 sensor to play nicely with the latest Zephyr RTOS. I totally get the frustration – compatibility issues can be a real headache. Let's dive into these warnings and errors to see if we can sort things out.

Understanding the BNO055 Sensor and Zephyr RTOS Integration

Before we get into the nitty-gritty of troubleshooting, let's quickly recap what we're dealing with. The BNO055 is a smart little sensor that combines an accelerometer, gyroscope, and magnetometer, making it perfect for applications needing orientation and motion data. Zephyr RTOS, on the other hand, is a fantastic real-time operating system designed for resource-constrained devices. Integrating these two should open doors for some cool projects, but as you've discovered, it's not always smooth sailing.

Decoding the Warnings and Errors

Let's break down the specific issues you're encountering. You've highlighted two key problems:

1. Incompatible Pointer Type Warning

The first issue is this warning:

C:/Users/billy/Projects/bf/zephyr/blinky/drivers/sensor/bosch/bno055/bno055.c:250:90: warning: passing argument 3 of 'i2c_reg_read_byte_dt' from incompatible pointer type [-Wincompatible-pointer-types]
  250 |                 err = i2c_reg_read_byte_dt(&config->i2c_bus, BNO055_REGISTER_POWER_MODE, &power);
      |                                                                                          ^~~~~~
      |                                                                                          |
      |                                                                                          enum bno055_PowerMode *
In file included from C:/Users/billy/Projects/bf/zephyr/blinky/drivers/sensor/bosch/bno055/bno055.c:9:
C:/Users/billy/zephyrproject/zephyr/include/zephyr/drivers/i2c.h:1649:67: note: expected 'uint8_t *' {aka 'unsigned char *'} but argument is of type 'enum bno055_PowerMode *
 1649 |                                        uint8_t reg_addr, uint8_t *value)

What's going on?

This warning is a classic type mismatch. The i2c_reg_read_byte_dt function, which is used to read a byte from an I2C register, expects a uint8_t * (a pointer to an unsigned 8-bit integer) as the third argument. This is where the read value will be stored. However, you're passing &power, which is a pointer to an enum bno055_PowerMode. These are different data types, hence the warning.

Why does this matter?

While it's "just" a warning, it indicates a potential bug. The function might be writing data into memory that isn't the right size or format for your power variable, leading to unexpected behavior or crashes.

How to fix it:

The solution here is to use a uint8_t variable to read the power mode and then convert it to the enum bno055_PowerMode if necessary. Here's how you could adjust your code:

uint8_t power_raw;
err = i2c_reg_read_byte_dt(&config->i2c_bus, BNO055_REGISTER_POWER_MODE, &power_raw);
if (err) {
    // Handle error
    return err;
}
enum bno055_PowerMode power = (enum bno055_PowerMode)power_raw;

In this snippet, we first read the power mode into power_raw, a uint8_t. Then, we cast power_raw to enum bno055_PowerMode and assign it to your power variable. This ensures that the data is read correctly and then interpreted in the desired format.

2. Expected Expression Before ',' Token Error

The second issue is a more severe error:

C:/Users/billy/Projects/bf/zephyr/blinky/drivers/sensor/bosch/bno055/bno055.c:1958:86: error: expected expression before ',' token
 1958 |                            (.irq_gpio = GPIO_DT_SPEC_INST_GET_OR(n, irq_gpios, {0}))),             \
      |                                                                                      ^
C:/Users/billy/zephyrproject/zephyr/include/zephyr/sys/util_internal.h:72:26: note: in definition of macro '__DEBRACKET'
   72 | #define __DEBRACKET(...) __VA_ARGS__
      |                          ^
C:/Users/billy/zephyrproject/zephyr/include/zephyr/sys/util_internal.h:64:9: note: in expansion of macro '__GET_ARG2_DEBRACKET'
   64 |         __GET_ARG2_DEBRACKET(one_or_two_args _if_code, _else_code)
      |         ^
C:/Users/billy/zephyrproject/zephyr/include/zephyr/sys/util_internal.h:59:9: note: in expansion of macro '__COND_CODE'
   59 |         __COND_CODE(_XXXX##_flag, _if_1_code, _else_code)
      |         ^
C:/Users/billy/zephyrproject/zephyr/include/zephyr/sys/util_macro.h:204:9: note: in expansion of macro 'Z_COND_CODE_1'
  204 |         Z_COND_CODE_1(_flag, _if_1_code, _else_code)
      |         ^
C:/Users/billy/zephyrproject/zephyr/include/zephyr/devicetree.h:5083:9: note: in expansion of macro 'COND_CODE_1'
 5083 |         COND_CODE_1(DT_HAS_COMPAT_STATUS_OKAY(DT_DRV_COMPAT),   \
      |         ^
C:/Users/billy/Projects/bf/zephyr/blinky/build/blinky/zephyr/include/generated/zephyr/devicetree_generated.h:8422:47: note: in expansion of macro 'BNO055_INIT'
 8422 | #define DT_FOREACH_OKAY_INST_bosch_bno055(fn) fn(0)
      |                                                ^
C:/Users/billy/zephyrproject/zephyr/include/zephyr/sys/util_internal.h:105:36: note: in expansion of macro 'DT_FOREACH_OKAY_INST_bosch_bno055'
  105 | #define UTIL_PRIMITIVE_CAT(a, ...) a##__VA_ARGS__
      |                                    ^
C:/Users/billy/Projects/bf/zephyr/blinky/drivers/sensor/bosch/bno055/bno055.c:1966:1: note: in expansion of macro 'DT_INST_FOREACH_STATUS_OKAY'
 1966 | DT_INST_FOREACH_STATUS_OKAY(BNO055_INIT)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~

What's going on?

This error is trickier because it involves macros and the Device Tree. It essentially means the compiler is stumbling over a comma within a macro expansion. The error arises during the initialization of the BNO055 driver, specifically when trying to get the IRQ (Interrupt Request) GPIO (General Purpose Input/Output) configuration from the Device Tree.

Why does this matter?

This is a fatal error, meaning your code won't compile. It points to a problem in how the BNO055 driver is using the Device Tree to configure the interrupt pin.

How to fix it:

The root cause is likely in how the irq_gpios property is defined in your Device Tree. Let's take a closer look at the Device Tree snippet related to your BNO055 instance. It should look something like this:

&i2c1 {
    bno055@28 {
        compatible = "bosch,bno055";
        reg = <0x28>;
        irq-gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>; // Example
    };
};

The key part is the irq-gpios property. This property tells the driver which GPIO pin is connected to the BNO055's interrupt output. The error suggests that there might be an issue with the format or the values provided in this property. It could be a syntax error, an incorrect pin number, or a missing GPIO controller reference.

Here are a few things to check:

Syntax: Make sure the irq-gpios property is defined correctly. It should be a <&gpioX pin flags> tuple, where gpioX is the GPIO controller node, pin is the pin number, and flags are the interrupt flags (e.g., GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW).
GPIO Controller: Verify that the gpioX reference in your irq-gpios property exists in your Device Tree and is correctly configured.
Pin Number: Double-check that the pin number you're using is the correct pin connected to the BNO055's interrupt output.
Missing {0}: Sometimes, the {0} in the macro GPIO_DT_SPEC_INST_GET_OR(n, irq_gpios, {0}) can cause issues if the irq-gpios property is not defined. You can try defining a default value in your Device Tree to avoid this.

Zephyr Version Compatibility

Now, to address your initial question about Zephyr version compatibility: this is a critical point. The Zephyr RTOS is under active development, and APIs and Device Tree bindings can change between versions. The errors you're seeing could very well be due to incompatibilities between your BNO055 driver code and the latest Zephyr version.

To figure out the compatible Zephyr version, I'd recommend a few things:

Check the Repository: Go back to the repository where you found the BNO055 driver. Look for any documentation or README files that specify the Zephyr version it was tested with.
Examine the Code: If there's no explicit version mentioned, try looking at the commit history. You might find clues about when the driver was last updated or which Zephyr versions were used during development.
Experiment: If all else fails, you might need to do some experimentation. Try checking out older Zephyr releases (using Git tags) and see if the driver builds and runs correctly. You can use west init -m zephyr --mr <tag> to checkout a specific tag.

General Troubleshooting Tips

Beyond these specific errors, here are some general tips for troubleshooting hardware/software integration issues in Zephyr:

Verbose Build: Use the verbose build option (-v) when compiling your project. This will show you the full compiler commands, which can be helpful for debugging.
Device Tree Overlays: If you're making changes to your Device Tree, consider using Device Tree Overlays. This allows you to modify the Device Tree without directly editing the board's main Device Tree file.
Logging: Add plenty of logging to your driver code. Use printk() to output debug messages and sensor readings. This will help you understand what's happening at runtime.
Debugging Tools: Zephyr supports various debugging tools, such as GDB. Learn how to use these tools to step through your code and inspect memory.
Community Support: Don't hesitate to reach out to the Zephyr community for help. The Zephyr project has an active community forum and a Slack channel where you can ask questions.

Wrapping Up

Troubleshooting compatibility issues can be tough, but with a systematic approach, you can usually find the root cause and get things working. In your case, focus on resolving the pointer type warning and the Device Tree error. Also, make sure you're using a Zephyr version that's compatible with your BNO055 driver.

Good luck, and let me know if you have any more questions! We're here to help you get your project off the ground.