2016-03-24 05:52 PM
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.Solved! Go to Solution.
2019-12-10 01:39 AM
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).
2016-06-29 09:18 AM
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, Marian2016-06-30 06:40 AM
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=false2019-12-10 01:39 AM
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).