L3GD20H Wrong I2C Address

[acsmith]

Posted on March 25, 2016 at 01:52

I've got a board with a Gyro (L3GD20H) and Accel/Mag (LSM303D).  I'm interfacing with the sensors using I2C.  I can communicate with the Accel/Mag without issues.  However, the Gyro is showing up at (7bit) address 0x68 and it should be 0x6A (since SA0 is low).  I'm able to dump the registers and some of them are correct (WHO_AM_I), however, the data isn't correct.  I've scoped the lines and they look OK, it's just responding at the wrong address.  I've attached the scope readings and the schematic.

Has anyone seen this before?  I've probed all the pins and they look correct.

Thanks.

[louda.marian]

Posted on June 29, 2016 at 18:18

Hello Andrew,

the 7bit address for L3GD20H if SA0 is high is 0x6B and not 0x68. But if you are able to read some registers with correct values the problem will not be in I2C address. Do you have only those two sensors connected to I2C or is there another sensor on the same I2C? The behavior that some values are correct and some not can be observed if there are two sensors with the same I2C address connected to the same bus.

Best Regards,

Marian

[louda.marian]

Posted on June 30, 2016 at 15:40

Hello Andrew,

the I2C communication on picture you attached is wrong.I attached picture with correct communication. My configuration is almost the same as yours, just my SA0 isconnected to 1.8 V.I am afraid that you have some mistake in your program.

Best Regards,

Marian

________________

Attachments :

screenshot1.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtzK&d=%2Fa%2F0X0000000ab0%2F1cTntc0DjpOxAbcXv4TdEYsrvleG2GDF1G3PBUI3jSc&asPdf=false

[Kevin Michel]

Hi,

I've had the same issue, intermittently, on our deployed L3GD20H.

The device seems to be responding to 0x68 instead of 0x6a or 0x6b

if you talk to it too quickly after powering up the bus.

Waiting 20ms after power-up fixed the issue for me,

I don't know what's the minimal required time to have a reliable answer.

According to our internal tickets, we've also had similar issues when VDD and

VDD_IO weren't starting together or in an unexpected order.

I don't have the exact details written down, and since we had to add the 20ms

delay later, it might have been a misdiagnosed issue.

It could be worth looking into it if you're still having issues and the 20ms delay

is not working or not an acceptable constraint.

(This was especially confusing since I was doing a "preventive" I2C scan before

doing any real work on the bus to help diagnosing I2C issues: I saw a ghost

device at 0x68 during the scan, but later the L3GD20H was correctly answering

at 0x6a when doing real work).