Using LSM6DSO sensor on NRF52832

[connorshannon]

Hello, 

I'm new to pretty much all of this, but I'll do my best to explain my issue. As the title says, I'm currently trying to get a LSM6DSO sensor to work with the NRF52832 board. I'm using the Nordic sample code for LSM6DSO and using VSCode to build it for the NRF52832. I was having issues with the devicetree not being able to find the sensor using DEVICE_DT_GET_ONE (this function initially returned a negative value), so I added an extra overlay file: 

arduino_i2c: &i2c0 {

    lsm6dso@6a {

        compatible = "st,lsm6dso";

        label = "LSM6DSO";

        reg = <0x6a>;

    };

};

This seemed to fix the issue. The only other thing I changed from the base project code was adding the lines

CONFIG_LOG=y

CONFIG_LOG_PRINTK=y

to my prj.conf file so that I could log any errors.

I've fully connected the sensor to the board and have verified the connections are correct using a colleagues code, so I don't think the connections are the issue. When I build and flash the code, this is the output I get:

As I said, I'm fairly new to how Nordic organizes code and devicetree, so I'm really just not sure what to do from here. Obviously, the code is running through its main function, but it gets an error when it tries to test the trigger mode. I believe the sample code is supposed to work with an ST board, so I think getting this code to work is just a matter of making small changes to the overlay files or the configuration files, although I could easily be wrong.

Any advice would be greatly appreciated, and let me know if I can provide any more information that might help. Thank you!

[connorshannon]

I realize that I didn't actually include the code sample I was using, so here it is.

/*
 * Copyright (c) 2020 Yestin Sun
 *
 * SPDX-License-Identifier: Apache-2.0
 */

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

static inline float out_ev(struct sensor_value *val)
{
	return (val->val1 + (float)val->val2 / 1000000);
}

static void fetch_and_display(const struct device *dev)
{
	struct sensor_value x, y, z;
	static int trig_cnt;

	trig_cnt++;

	/* lsm6dso accel */
	sensor_sample_fetch_chan(dev, SENSOR_CHAN_ACCEL_XYZ);
	sensor_channel_get(dev, SENSOR_CHAN_ACCEL_X, &x);
	sensor_channel_get(dev, SENSOR_CHAN_ACCEL_Y, &y);
	sensor_channel_get(dev, SENSOR_CHAN_ACCEL_Z, &z);

	printf("accel x:%f ms/2 y:%f ms/2 z:%f ms/2\n",
			(double)out_ev(&x), (double)out_ev(&y), (double)out_ev(&z));

	/* lsm6dso gyro */
	sensor_sample_fetch_chan(dev, SENSOR_CHAN_GYRO_XYZ);
	sensor_channel_get(dev, SENSOR_CHAN_GYRO_X, &x);
	sensor_channel_get(dev, SENSOR_CHAN_GYRO_Y, &y);
	sensor_channel_get(dev, SENSOR_CHAN_GYRO_Z, &z);

	printf("gyro x:%f rad/s y:%f rad/s z:%f rad/s\n",
			(double)out_ev(&x), (double)out_ev(&y), (double)out_ev(&z));

	printf("trig_cnt:%d\n\n", trig_cnt);
}

static int set_sampling_freq(const struct device *dev)
{
	int ret = 0;
	struct sensor_value odr_attr;

	/* set accel/gyro sampling frequency to 12.5 Hz */
	odr_attr.val1 = 12.5;
	odr_attr.val2 = 0;

	ret = sensor_attr_set(dev, SENSOR_CHAN_ACCEL_XYZ,
			SENSOR_ATTR_SAMPLING_FREQUENCY, &odr_attr);
	if (ret != 0) {
		printf("Cannot set sampling frequency for accelerometer.\n");
		return ret;
	}

	ret = sensor_attr_set(dev, SENSOR_CHAN_GYRO_XYZ,
			SENSOR_ATTR_SAMPLING_FREQUENCY, &odr_attr);
	if (ret != 0) {
		printf("Cannot set sampling frequency for gyro.\n");
		return ret;
	}

	return 0;
}

#ifdef CONFIG_LSM6DSO_TRIGGER
static void trigger_handler(const struct device *dev,
			    const struct sensor_trigger *trig)
{
	fetch_and_display(dev);
}

static void test_trigger_mode(const struct device *dev)
{
	struct sensor_trigger trig;

	if (set_sampling_freq(dev) != 0)
		return;

	trig.type = SENSOR_TRIG_DATA_READY;
	trig.chan = SENSOR_CHAN_ACCEL_XYZ;

	if (sensor_trigger_set(dev, &trig, trigger_handler) != 0) {
		printf("Could not set sensor type and channel\n");
		return;
	}
}

#else
static void test_polling_mode(const struct device *dev)
{
	if (set_sampling_freq(dev) != 0) {
		return;
	}

	while (1) {
		fetch_and_display(dev);
		k_sleep(K_MSEC(1000));
	}
}
#endif

int main(void)
{
	printf("We are in main\n");
	const struct device *const dev = DEVICE_DT_GET_ONE(st_lsm6dso);
	if (!device_is_ready(dev)) {
		printk("%s: device not ready.\n", dev->name);
		return 0;
	}

#ifdef CONFIG_LSM6DSO_TRIGGER
	printf("Testing LSM6DSO sensor in trigger mode.\n\n");
	test_trigger_mode(dev);
#else
	printf("Testing LSM6DSO sensor in polling mode.\n\n");
	test_polling_mode(dev);
#endif
	return 0;
}

[rbmarcus]

I was in your position about half an hour ago. I believe trigger mode is flagged as unsupported because you haven't specified the trigger pin in your overlay. The error message is resolved for me when I specify int-pin and irq-gpios (with int-pin being either 1 or 2, and selecting between the first and second listed IRQ GPIO):

&spi1 {
	status = "okay";
	cs-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>,
			   <&gpio1 11 GPIO_ACTIVE_LOW>;
	pinctrl-0 = <&spi1_default>;
	lsm6dso@0 {
		compatible = "st,lsm6dso";
		reg = <0x0>;
		spi-max-frequency = <8000000>;
        status = "okay";
		irq-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>, <&gpio1 13 GPIO_ACTIVE_HIGH>;
        int-pin = <1>;
	};
};

[connorshannon]

Thank you for the response. So the changes I would need to make to my overlay file are to add something like 

        status = "okay";
		irq-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>, <&gpio1 13 GPIO_ACTIVE_HIGH>;
        int-pin = <1>;

to my overlay file? In your example, it looks like you're using spi whereas I'm using I2C. I also see that you specified pins 12 and 13 as the irq-gpios. For me, would those be the same pins as I'm using for the I2C connections (26 and 27)? Thanks!

[connorshannon]

I played around with a few combinations and am still getting the same error.

[rbmarcus]

I'm not sure if specifying the int pin is necessary, it may already be done in the sample code. The GPIOs should be based on your specific setup. I'm running this on a custom PCB with an nRF52840 so my pinout is likely going to be different from yours, which is also why I used SPI rather than the I2C sample default. In the overlay file you can modify the pins to your liking (for the most part) since GPIOs on Nordic chips are muxed. That is, you can change both the I2C bus pins and the pins tied to your IMU. You want to pick different GPIOs for the interrupt pins than the ones you're using for the I2C bus. Pick ones that look unused and then wire the chosen GPIOs to the INT1 and INT2 pins on your LSM6DSO.

To troubleshoot the error message, you can enable debugging in your prj.conf with CONFIG_LOG_DEFAULT_LEVEL, CONFIG_SPI_LOG_LEVEL, and CONFIG_SENSOR_LOG_LEVEL. Can you share your full prj.conf file?

Some additional information that may be beneficial for you:

• Zephyr has a guiconfig, which can also be accessed by pressing "nRF Kconfig GUI" in the Actions sidebar if you have Nordic's VSCode extension
• Nordic offers a DeviceTree Visual Editor UI with the VSCode extension
• Hovering over "st,lsm6dso" will take you to the "st,lsm6dso-12c.yaml" sensor bindings file, which then links you to the two includes "i2c-device.yaml" and "st,lsm6dso-common.yaml". These files should list all the configurations available for the I2C bus and for your specific peripheral if you don't want to use the GUI tools.
• If you haven't already, I would start with CONFIG_LSM6DSO_TRIGGER_NONE instead of TRIGGER_GLOBAL_THREAD to disable trigger and enable polling. Polling mode is more straightforward and does not require the interrupt pin configuration, so you can confirm everything else works in your code.
• Tucked away in /modules/hal/st/sensor/stmemsc/lsm6dso_STdC/driver you'll see LSM6DSO_ID defined as 0x68. I was using a variant that had a different chip ID, which caused the process to fail. That doesn't seem to be your issue if the error you're seeing is still trigger_set op not supported, but it's probably worth mentioning in case anyone else with the same problem sees this in the future.

Full disclaimer I'm just some random guy so I would take this information with a grain of salt. Hopefully a Nordic dev is able to help you figure out the root cause if we aren't able to narrow down the problem before then.