LSM6DSO not replying on I2C

[Myzhar]

Hi all,

I have a custom board with an LSM6DSO connected to an STM32F072 on I2C.

The IMU shares the I2C bus with other sensors that can communicate with the MCU without any issue, so the bus is working.

The LSM6DSO instead does not reply, there was an error in the schematic because there was a pullup resistance on INT1 that has been removed, so the sensor should correctly run in I2C mode. But it does not. SA0 is on GND, so it should reply to the address 0x6A, but it is not possible to read the WHO_AM_I register (see attached picture).I tried to change the configuration of the INT1 pin on the MCU, leaving it unconfigured, setting it as output pin in push-pull mode with and without pull-down, and I also tried to set it as open-drain, but without success.

Do you have any clue about the possible causes of this problem?

Following the schematic of the circuit, R125 and R240 have been removed, SCL and SDA have 1k pull-up to 3V3:

 

Thank you in advance,

Walter

[Eleon BORLINI]

Hi Walter @Community member​ ,

Did you try to run an I2C scan code (from 00h to FFh) to check if it is an issue related to the I2C address value or to the communication in general?

Please note that the full I2C address has to take into account also of the R/W bit, so the complete address in your case (in order to read the WHO_AM_I register) is D5h.

The schematic looks otherwise ok. Can you try with this?

-Eleon

[Myzhar]

Hi Eleon,

I have not performed a full scan, but I'm pretty sure that I'm using the correct address because I'm using the STM MEMS library and it correctly works for all the other sensors on the same bus (1x LIS3MDL, 1x LPS22HB, and 2x STTS751).

My only doubt is regarding how to correctly configure the GPIO pin of the MCU that is connected to INT1.

I'm frightened that for some reason it's driving the LSM6DSO into I3C mode, but as I wrote in my first message, I tried all the possible configurations for it.

[Eleon BORLINI]

Hi Walter,

you have to leave the INT1 pin floating (internal pull-down), so that the I2C/I3C both active. Or at least the GPIO initialized low: otherwise, only the

But the I2C and the I3C protocols are different, so if the INT1 is in the usual configuration, and you communicate with that slave address, only the I2C will ack the line.

Can you try powering off the other sensors and communicate only with the LSM6DSO?

-Eleon

[Myzhar]

Hi Eleon,

that's what I tried: I set the GPIO pin of the MCU where the INT1 signal is connected to output push-pull mode with internal pull-down. But it did not solve the problem.

Also disabling the other sensors is unuseful.

Like you suggested I performed a 00h-FFh scan and only the other devices are replying on their correct address.

The next thing that I want to try is to change the address, I have no other ideas about the possible cause of the problem

[Myzhar]

@Eleon BORLINI​ I used the LSM6DSL of the IoT Node Discovery Kit and on its schematic, the pins SCx and SDX are floating. We connected them to GND as suggested on the datasheet... is it possible that they should be left floating instead?

I tried also to change the address of the MCU moving the resistor from GND to 3V3, but nothing changed. The device is still not reachable

[Eleon BORLINI]

Hi @Community member​ ,

But are you using the LSM6DSL or the LSM6DSO?

Note that with the LSM6DSL you have to consider the following connections (datasheet, p.20):

 

-Eleon

[Myzhar]

We are using an LSM6DSO, I posted the picture of the LSM6DSL because I used it in my preliminary tests on an IoT Node Discovery Kit.

LSM6DSL and LSM6DSO are very similar and both datasheets say to connect SDx and SCx to VDDIO or GND, but on YOUR devkit they are left floating and that devkit works as expected.

[Eleon BORLINI]

Hi @Community member​ ,

Both on STEVAL-MKI196V1 (adapter for the LSM6DSO) and on the STEVAL-MKI178V1 (adapter for the LSM6DSL), that are the reference kits for ST IMU sensors, the SCx and SDx pins are intended to be connected to the application processor, so they are kept in a known condition.

 

Which reference kits are you referring to?

-Eleon

[Myzhar]

Hi @Eleon BORLINI​ 

we preliminary tested the sensors with B-L4S5I-IOT01A and STEVAL-MKSBOX1V1because they were the only two boards available "quickly".

Yesterday I ordered an X-NUCLEO-IKS01A3 (I should receive it today) that provides the same sensors stack that we are using so I can conduct other tests to understand why our circuit is not working as expected.