Skip to main content
Visitor II
September 5, 2020
Solved

Can I leave SDO_A/G pin floating on the LSM9DS1?

  • September 5, 2020
  • 2 replies
  • 932 views

Does it have internal pull-up? Or do I need to connect that to a pin? Is there a way to "burn" the i2c address?

I'm asking as I have a design where I left that pin open. On some devices I have I2C communication issues, and I am asking myself if they could be related to this issue ...

    This topic has been closed for replies.
    Best answer by Eleon BORLINI

    Hi @TWied.1​ ,

    well... it is not a best practice, indeed... Please note that the SDO_A/G pin is the I2C least significant bit of the device address (SA0) for the accelerometer and gyroscope (datasheet p.11). The line is open-drain by default because it is an SPI line... Leaving it unconnected means that it is not in a fixed voltage state, thus causing the SA0 bit (which defines the device address) to change.

    0693W000003R9gqQAC.png

    Is the I2C communication issue limited and repeatable on only some device? If so, you could try to change the device address on that samples and check the I2C communication.

    -Eleon

    2 replies

    ST Employee
    September 9, 2020

    Hi @TWied.1​ ,

    well... it is not a best practice, indeed... Please note that the SDO_A/G pin is the I2C least significant bit of the device address (SA0) for the accelerometer and gyroscope (datasheet p.11). The line is open-drain by default because it is an SPI line... Leaving it unconnected means that it is not in a fixed voltage state, thus causing the SA0 bit (which defines the device address) to change.

    0693W000003R9gqQAC.png

    Is the I2C communication issue limited and repeatable on only some device? If so, you could try to change the device address on that samples and check the I2C communication.

    -Eleon

    TWied.1Author
    Visitor II
    September 15, 2020

    Thanks for your answer.

    It's worse. It looks like the address changes at undefined times during runtime of the device which renders any communication with the device unreliable ..

    i'll have to correct the design.