While exploring new I2C devices or bringing up I2C devices on Linux, and especially when things are not working, one of the common doubts which linger around is, is there a problem in hardware or software. In fact, this is a common doubt for any type of device, why only I2C. And the easiest way ahead for all such standard protocols is to have a user space tool / application, which can scan the devices without depending on any device specific driver. Assumption here is that the corresponding bus driver is in place. Depending on the protocol, the tools may be different. So, here our focus is on I2C.
i2cdetect is a powerful and simple tool for figuring out I2C devices. If an I2C device is detectable with i2cdetect, it means hardware is fine and if not detectable means some issue with the hardware. And the debugging could proceed accordingly. Executing i2cdetect may need root privileges and can be used as follows:
List the I2C buses available:
# i2cdetect -l
Say, 0 & 1 are available. Then, each bus could be scanned to see what all device addresses exist on each bus. It is assumed that we know the device addresses of our devices. Here’s how to scan say bus 0:
# i2cdetect -y 0
If this doesn’t work, issuing an error, you may add a “-r” option to use the SMBus commands, which should work.
# i2cdetect -y -r 0
Output of the working command will be an array of all device address locations on that bus, with “- -” or “UU” or a device address, as its value.
“- -” indicates address was probed but no device responded. So, if you are expecting a device at some address and got “- -“, it means either it is not on this bus, or the device is not getting detected because of some hardware issue, which could be hardware lines not connected properly, or voltage supply issue, or something else.
“UU” indicates that probing of this address was skipped because the address is currently in use by a driver. This is strong indication that the device is present, and highly likely that the driver is also in place.
Device Address in hexadecimal indicates that the device has been detected.
In both the above cases, hardware side of the device & its connections are all fine. And if it is still not working as expected in case it is showing “UU”, it is high chances that the driver may need tuning / modification. Just to be doubly sure about that, you may verify it by changing the device with an another one, if possible.
And for the case showing the device address in hexadecimal, either a software driver is needed for it or it may be accessed using some user space accessing mechanism.
Note: i2cdetect is part of the i2c-tools package. So, if it is not available on the corresponding Linux system, the i2c-tools package may need to be installed.
Can I detect SMbus slave device using i2cdetect command?
Very helpful. Thanks!
when i tried the command i2cdetect -y -r 1, it got crashed and showed some logs like this
root@OpenWrt:/sys/bus/i2c/devices# i2cdetect -y -r 1
0 1 2 3 4 5 6 7 8 9 a b c d e f[ 601.974250] Bad mode in Error handler detected, code 0xbf000002 — SError
[ 601.974563] WARN: Access Violation!!!, Run “cat /sys/kernel/debug/qcom_debug_logs/tz_log” for more details
[ 601.974903] WARN: Access Violation!!!, Run “cat /sys/kernel/debug/qcom_debug_logs/tz_log” for more details
[ 601.993783] Internal error: Oops – bad mode: 0 [#1] PREEMPT SMP
can you please tell why this happens?
Check out the logs as suggested in the error message.
Is there a way to detect i2c device id using i2c tools in linux..
(Example Reference : https://www.microchip.com/forums/m1013076.aspx)
In above link, they are mentioning host to send raw 0xF8, and 0xF9 on to the bus.
Is there a way to send those device id detection command from linux user space using i2c utilities.
Sending raw is fine. You may use i2cdump. But the link expects a particular protocol sequence. That may not be possible.