# Why is i2cset giving “resource busy” on my BeagleBone Black?

After trying to get Adafruit's 8x8 LED Matrix python example code to work on both my Raspberry Pi and my BeagleBone Black, I realized there is probably something wrong with Adafruit's code and not me. The matrix is working just fine with a Teensy3.1.

I decided that this is a good time to cut my losses and learn how to program i2c.

In my first steps I came across this useful blog where someone did this using the i2cset command. Unfortunately the device seems busy.

Any ideas?

According to one person, "UU" on the i2cdetect, could mean "Probing was skipped, because this address is currently in use by a driver".

Others had also mentioned "modules" that may already be using the i2c bus, and that one could remove these "modules" and try again.

• Something that might be worth a try if you haven't already is removing the device and try the i2cdetect again, the last time I had a similar problem it was because the device was on a different bus / address to what the docs indicated so I was trying to access something else. It might be worth trying an i2cset -f as well. – PeterJ Nov 23 '14 at 8:14

It ended up being the second i2c bus that I needed to use. As you can see below, 0x70 is the "chip address" available on bus 2! UU is signifying something unavailable or busy.

After this I was able to follow the nice instructions here, but using bus 2.

Specifically,

i2cset -y 2 0×70 0×21

i2cset -y 2 0×70 0×81

i2cset -y 2 0×70 0xe0


for starting the multiplexing oscillator, enabling the display with no blink, and brightness

Using this information I was actually able to modify Adafruit's code for matrix8x8_test.py example, explicitly defining the i2c bus and chip address display = Matrix8x8.Matrix8x8(address=0x70, busnum=2). This is on a BeagleBone Black wired exactly as Adafruit said. I hope this helps someone. I will definitely be learning the i2c bus inferface myself as it's going to be worth it in the future when stuff like this comes up.