Detection of I2C Devices

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.

Anil Kumar Pugalia (123 Posts)

The author is a hobbyist in open source hardware and software, with a passion for mathematics, and philosopher in thoughts. A gold medallist from the Indian Institute of Science, Linux, mathematics and knowledge sharing are few of his passions. He experiments with Linux and embedded systems to share his learnings through his weekend workshops. Learn more about him and his experiments at https://sysplay.in.


   Send article as PDF   

7 thoughts on “Detection of I2C Devices

  1. Arvind

    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?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *