I2C - can't find device address

Zogg Baubas

i2cdetect always produces the same output. Tried reading everyone of the reported addresses and all of them return 0xff, even though I'v connected MPU6050 to the Omega's power board.

root@Omega-BA8F:~# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

omega2-ctrl also fails:

root@Omega-BA8F:~# omega2-ctrl gpiomux get
unable to open mmap fileroot@Omega-BA8F:~#

I dont even know where to begin debugging this, any help appreciated.

luz

@Zogg-Baubas If it's not a gpiomux problem (see below), I would try to run the i2c at lower speed. I had a similar issue with i2c peripherals connected via relatively long wires, but got it working as soon as I reduced the bus speed.

However that was on the Omega1, which had bitbanged gpio i2c, where you could set the bus speed as parameter to the i2c-gpio-custom kernel module. I haven't used i2c on the Omega2's hardware-supported i2c yet, but for sure there's a way to set bus speed.

Regarding gpiomux/omega2.-ctrl: do you have the latest FW installed? The error message probably means that the /dev/mem device is missing, and this was a problem in one of the Omega2 firmware images (accidentally built w/o KERNEL_DEVMEM support, see here).

WereCatf

@Zogg-Baubas I am also seeing those false positives when using i2cdetect on my Omega2+, but I haven't yet dug into it or tried to use I2C on mine. I don't know where those false positives come from and it kind of bothers me. i2cdetect -q -y 0 makes them go away, but they shouldn't appear in the first place.

I may take a better look later on today.

WereCatf

I still don't know why i2cdetect fails, but actually using I2C seems to work fine. I've got an I2C LCD-module that I just tested and sure enough, text gets printed on it without an issue. Non-functional i2cdetect is less than useful, unfortunately.

ziger zigs

Just a quick word from some of my own frustrated testing with I2Cdetect:

The reason -q causes the false positives to disappear is because -q is "quick write". It tells you this if you leave out -y, since -y removes the prompt that tells you what's going on.

Conversely, you will get nothing but false positives if you instead use -r, which is "read" the first byte of every address to find out who's where.

I think this has to do with how reading from something that isn't there results in 0xff.

If you've managed to get I2C working with your Omega2, I'd be real interested in hearing what your setup is. I'm about two seconds away from giving up on the I2C libraries and just bit banging to figure things out.

t-gabor

@ziger-zigs Actually I had some success with the bit-banging i2c-gpio-custom kernel module. Unfortunately it is not part of the official repo, I had to compile the needed kernel modules myself. I am asking for adding it here.

Brad Tittle

I used this little script to scan all of the addresses.

#!/bin/sh
for i in $(seq 3 122 )
do
echo "PORT -- $1 -- " printf '0x%x' $i
i2cdump -y $1 printf '0x%x' $i
done

save as scanDump.sh
chmod 777 scanDump.sh

i2cdetect -l

got me a list of the available busses. My bus shows up as

10000900.i2c

so I ran

scanDump.sh 10000900.i2c

The only address that had anything different was 0x3f

Apparently 0x3f is the correct address, but I still am not getting anything to show up on the LCD using the tutorial.

Brad Tittle

I finally got the LCD screen to run properly from the Python library in the tutorials.

I can't say I had to change anything. I did have to adjust the voltage (err contrast? brightness?) on with the potentiometer on the back of the LCD. It was set either too high or too low. I thought I had adjusted it before, but apparently everything wasn't lined up. This last time around, I had SCL plugged into 19 and SDA into 20. I will go sit in a corner later.

Changes to the Tutorial that I had to discover.

opkg install ca-bundle (to install the certificate bundle to let git work right)
The script I used above to help me find the right address, but the address was the same as in the documentation from the gentleman who made the library.
The script fails if you don't add the address.

python lcd.py --line1="HELLO WORLD" --line2="LET FREEDOM RING!" --address=0x3f

is what worked for me.

Adjusting the brightness with the blue Trim Pot (Trimming potentiometer) after something has been written to the screen.

Hope this helps someone. I ran around in circles for quite awhile.

Michael Cuddy

@Brad-Tittle Thanks for this, Brad ... saved me a bunch of time. I didn't get anything on my LCD until ~~I cranked the contrast pot all the way to its limit~~ I connected the backpack to 5v on the expansion dock (first attempt was with the breadboard dock, which doesn't have 5V). seems like ~~bad design on the backpack~~ the backpack should be 3v not 5v.

TL;DR: Serial LCD backpack is 5V.

-- pryankster

CoffeeCat

@Brad-Tittle

Trying to resolve this on my Omega2+ with the 16X2 LCD, and using your script (Thanks for sharing it!). What could be causing this error when running it?

Thanks in advance.

Arne Schmitz

I am interested in this topic as well. I am trying to get a Si470x to run on the Omega2. On the Pi this was trivially to do.

On the Omega2, I cannot even get the Si470x to show up in i2cdetect. On top of that I also see the false positives.

I am using the Breadboard dock with a massive 3A USB PSU.

UFD

Hi @Arne-Schmitz ,

Please try and use "bit-banged" I2C, you may find this post usefull:
I2C Detect Slave Method

Arne Schmitz

@UFD thanks, I will try that. So the i2c implementation really seems to be buggy?