• State Verified Answer
  • Replies 13 replies
  • Subscribers 27 subscribers
  • Views 2141 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 273531
Options

Unable to Connect nRF5340DK with BMI270 Over I2C

user105514

I am attempting to get the BMI270 sample working on an nRF5340DK, using nRF Connect SDK v1.6.0, but all attempts at device_get_binding("BMI270"), device_get_binding(DT_LABEL(DT_INST(0, bosch_bmi270))), and similar return null.  I am using the following config and overlay files

#prj.conf

CONFIG_UART_CONSOLE=n
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y

CONFIG_I2C=y
CONFIG_SENSOR=y
CONFIG_BMI270=y

/* nrf5340dk_nrf5340_cpuapp.overlay - no shield */

&arduino_i2c {
	status = "okay";

	bmi270@68 {
		compatible = "bosch,bmi270";
		reg = <0x68>;
		label = "BMI270";
	};
};

On the hardware side I'm using a BMI270 breakout connecting SDA to P1.02 and SCL to P1.03.

I have also used a shield that sends SDA to P0.25 and SCL to P0.26, with the following overlay

/* nrf5340dk_nrf5340_cpuapp.overlay - with shield */

&i2c1 {
    sda-pin = <25>;
    scl-pin = <26>;
};

&arduino_i2c {
	status = "okay";

	bmi270@68 {
		compatible = "bosch,bmi270";
		reg = <0x68>;
		label = "BMI270";
	};
};

In all attempted cases

#include <zephyr.h>
#include <device.h>
#include <drivers/sensor.h>
#include <stdio.h>

void main(void)
{
	const struct device *dev;

	dev = device_get_binding("BMI270");

	if (dev == NULL) {
		printf("Could not get %s device\n",
		       DT_LABEL(DT_INST(0, bosch_bmi270)));
		return;
	}
	...
}

gives the output

00> *** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
00> Could not get BMI270 device

in J-Link RTT Viewer.

Any help would be greatly appreciated.

  • 0

    Further update, the BMI270 sample works perfectly on the nRF52833DK.  I used the above prj.conf to enable the RTT viewer, and the sample worked without modification (see below).  It seems clear that the problem is with the nRF5340DK.

    nrf52833-bmi270

  • 0

    Hi Jonathan, sorry to hear you're having trouble.

    To try to diagnose, I changed the sample as follows:
     
    gist.github.com/.../7abd6107b22c20470e04e780c58cf119
     
    My goal there is to figure out whether device_get_binding() is returning NULL because
     
    1. the device doesn't exist, or
    2. the device initialization function failed
     
    I built with:
     
    $ west build -b nrf5340dk_nrf5340_cpuapp
     
    If the build fails, it's 1. If the build doesn't fail, I'm guessing it's 2.  The build succeeded, so it's not 1.
     
    To confirm that it's 2., I would have to run the program with a breakpoint on bmi270_init(), to see if it returns nonzero.
     
    I don't have hardware, though -- could you please get the bmi270_init() return value on your nRF5340 setup to see what happened?
     
    If it's returning nonzero, the error number and a stack trace when bmi270_init() returns would help diagnose further.

  • 0 in reply to user81830

    Hi Marti,

    Stepping through bmi270_init(), it looks like the error is being generated at ret = write_config_file(drv_dev), see below.

  • 0 in reply to user105514

    Thanks!

    From your screenshot, you're getting -EIO from the i2c_burst_write() call on line 35, which indicates a real error coming out of i2c_nrfx_twim_transfer() in the I2C driver, i2c_nrfx_twim.c.

    Beyond just looking at the bus, you can build like this to enable more logs:

    west build -b nrf5340dk_nrf5340_cpuapp -- -DCONFIG_LOG=y -DCONFIG_LOG_MODE_IMMEDIATE=y  -DEXTRA_CFLAGS="-DNRFX_TWIM_CONFIG_LOG_ENABLED=1 -DNRFX_TWIM_CONFIG_LOG_LEVEL=4"

    I'm a bit surprised you're getting a different result on nRF52833DK since it's the same driver, but maybe comparing those logs will show where things go wrong on nRF5340.

  • 0 in reply to user81830

    Hi Marti,

    I really appreciate your help. I ran with the extra flags, but I didn't see anything that pointed to an answer in the logs.  I am very enthusiastic about the new features on the nrf5340, but this level of complication just to print IMU data over i2c doesn't bode well for the more complex development to come.  It seems like we need to stick with the nrf52833 for now. Thanks again for trying to help us find an answer though. 

Related
Terms of service