Error setting sampling frequency on lsm6dso - nrf52833

[ReginaA101]

Hi all,

I am running the lsm6dso zephyr sample on my nrf52833 dev kit. I am unable to set the sampling frequency. I get this error after flashing:

This is my overlay file:

My SDK version is 2.7 and I am on Zephyr 3.6.99

My debugger suggests that the issue could be from this case failing in i2c_nrfx_twim.c

However, the IMU address is listed at 7 bits long in the datasheet.

Does anyone have any suggestions?

[Håkon Alseth]

Hi,

 

Try setting "accel-odr" member:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.7.99-ncs1/dts/bindings/sensor/st,lsm6dso-common.yaml#L17

 

Also, I would recommend that you run on 100 kHz first, as 400 kHz requires stronger pull resistors (ie. external pull present).

 

Kind regards,

Håkon

[ReginaA101]

Also, I get an error code -22 whenever I try to set the sampling frequency for the LSM6DSO

[Håkon Alseth]

Hi,

 

Please note that zephyr supports lsm6dso, and not lsm6dsox directly. I do not know the exact difference between the two sensors, but they seem to have a similar i2c address atleast.

 

If you zoom into the rising edge of your saleae logic trace at approx. +0.5 sec, you should see some i2c communication. Please share this, and check if the sensor ACKs.

 

ReginaA101 said:

This is the sensor board I have

https://www.st.com/en/evaluation-tools/steval-mki217v1.html

Is there any possible configurations I could be missing to enable i2c communication? I have verified the connection of SDA/SCL/VDD and GND pins.

There is two sensors on this board, you will have to make sure that the board itself is not modified, as the default is to have both sensors connected over the common i2c lines.

ReginaA101 said:

I am using the same sample https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/sensor/lsm6dso I just changed one line in main due to getting a "device not ready" error:

It seems like you have changed this line:

https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/sensor/lsm6dso/src/main.c#L111C53-L111C63

 

I would strongly recommend that you keep this "as-is", ie. revert your change, as this line is crucial in terms of initializing and using the lsm6dso sensor driver.

 

Kind regards,

Håkon

 

[ReginaA101]

Thanks for your suggestions 

I have reverted the change

I am still getting a device not ready error.

I zoomed into the section you told me and I am getting an initialization. Seems that the first 7 bits are 6A which was the i2c address I believe.

It doesnt seem like I am getting any ACK though

[Håkon Alseth]

Hi,

 

Your sensor does not ACK (ie. NAK), as the LSBit in the transaction is high, indicating that there is a problem on the sensor side.

 

You should go over your physical connection and see if there's anything that isn't properly connected (VDD, VDDIO, GND, SDA and SCL).

 

Kind regards,

Håkon

[ReginaA101]

Hi Håkon,

You were right, there was some missing connections. I have verified all of the connections now.

I can write to the sensor but I cannot read from the sensor. 

I have verified that I can get the "WhoAmI" register (0x6C) 

I still get a device not ready error. 

When I use a debugger, I get the init_res value to be 5, which i believe is an input output error. Is it possible that I still have a configuration issue with my device tree? 

Best,

Regina

[Håkon Alseth]

Hi Regina,

 

It is very strange that the sensor ACKs twice, then NAKs on the read-out of WHOAMI register.

Have you checked with the vendor to hear if this might be an issue with the overall setup of the sensor on the module that you have? I see that it is i2c/i3c/SPI capable, it might be that this behaviour is a side-effect of a floating pin on the selection of the transport for instance?

 

Kind regards,

Håkon 

[ReginaA101]

Hi Håkon,

The manufacturer has not responded to me but I will let you know if they do. In the meantime, I want to check a couple of things.

First, does the bias_pull_up in the device tree take care of this?

This came from the lsm6dsox datasheet. Also, what is the resistance of the bias_pull_up?

Thanks,

Regina

[Håkon Alseth]

Hi,

ReginaA101 said:

First, does the bias_pull_up in the device tree take care of this?

Yes. The pull-ups are internal to the chip, and are nom. 13k - this is too weak for 400 kHz mode, but works fine for 100 kHz mode.

 

Kind regards,

Håkon

[ReginaA101]

Hi Håkon,

I talked to the manufacturers of my chip. They said that the second NAK is expected when reading one byte. So the sensor is behaving as expected. I still have a device not ready error though, with init_res == 5.

It seems like my device tree is okay

Any other suggestions that could cause this?