Intel® Makers
Intel® Edison, Intel® Joule™, Intel® Curie™, Intel® Galileo
Welcome - This is a Peer-to-Peer Forum only. Intel has discontinued these products but you may find support from other customers on this Forum

Edison + I2C

New Contributor I

Hello everybody,

I am having trouble with the i2c-6 of my Edison.

I'm using the Arduino Breakout board and when I type:

i2cdetect -y -r 6

the i2c crashes. Showing me this in loop:

[ 280.787684] i2c-designware-pci 0000:00:09.1: ===== REGISTER DUMP (i2c) =====

[ 280.787780] i2c-designware-pci 0000:00:09.1: DW_IC_CON: 0x65

[ 280.787852] i2c-designware-pci 0000:00:09.1: DW_IC_TAR: 0x77

[ 280.787922] i2c-designware-pci 0000:00:09.1: DW_IC_SS_SCL_HCNT: 0x2f8

[ 280.787991] i2c-designware-pci 0000:00:09.1: DW_IC_SS_SCL_LCNT: 0x37b

[ 280.788061] i2c-designware-pci 0000:00:09.1: DW_IC_FS_SCL_HCNT: 0x87

[ 280.788130] i2c-designware-pci 0000:00:09.1: DW_IC_FS_SCL_LCNT: 0x10a

[ 280.788199] i2c-designware-pci 0000:00:09.1: DW_IC_INTR_STAT: 0x0

[ 280.788267] i2c-designware-pci 0000:00:09.1: DW_IC_INTR_MASK: 0x246

[ 280.788337] i2c-designware-pci 0000:00:09.1: DW_IC_RAW_INTR_STAT: 0x10

[ 280.788405] i2c-designware-pci 0000:00:09.1: DW_IC_RX_TL: 0x20

[ 280.788474] i2c-designware-pci 0000:00:09.1: DW_IC_TX_TL: 0x20

[ 280.788543] i2c-designware-pci 0000:00:09.1: DW_IC_ENABLE: 0x1

[ 280.788611] i2c-designware-pci 0000:00:09.1: DW_IC_STATUS: 0x2

[ 280.788679] i2c-designware-pci 0000:00:09.1: DW_IC_TXFLR: 0x3

[ 280.788747] i2c-designware-pci 0000:00:09.1: DW_IC_RXFLR: 0x0

[ 280.788814] i2c-designware-pci 0000:00:09.1: DW_IC_TX_ABRT_SOURCE: 0x0

[ 280.788882] i2c-designware-pci 0000:00:09.1: DW_IC_DATA_CMD: 0x0

[ 280.788949] i2c-designware-pci 0000:00:09.1: ===============================

[ 280.789049] CPU: 1 PID: 284 Comm: i2cdump Tainted: G W O 3.10.17-poky-edison+ # 1

[ 280.789054] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48

[ 280.789061] task: f5dc5e90 ti: f5fca000 task.ti: f5fca000

[ 280.789123] Stack:

[ 280.789192] Call Trace:

[ 280.789625] Code: 10 b3 ff ff 89 f8 09 d0 80 ce 04 83 ff 02 0f 45 d0 a1 94 72 bd c1 89 90 00 b3 ff ff f7 c6 00 02 00 00 74 15 e8 20 58 0b 00 56 9d <83> c4 04 5b 5e 5f 5d c3 8d b6 00 00 00 00 56 9d e8 39 5b 0b 00

[ 280.789650] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O 3.10.17-poky-edison+ # 1

[ 280.789655] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48

[ 280.789664] task: c1bce1c0 ti: c1bc8000 task.ti: c1bc8000

[ 280.789727] Stack:

[ 280.789795] Call Trace:

[ 280.790029] Code: 50 08 83 e2 08 75 39 31 d2 83 c0 08 89 d1 0f 01 c8 0f ae f0 89 f6 89 e0 25 00 e0 ff ff 8b 40 08 a8 08 75 07 b1 01 89 f0 0f 01 c9 <85> 1d 78 60 c1 c1 75 0d 8d 55 f0 b8 05 00 00 00 e8 47 1a d7 ff

[ 280.790634] i2c-6: recovery ignore

I tested with 2 different Edison chips I have at the same Arduino breakout and they have the same behavior. I also tested in my mini breakout board the same thing happens and during the boot it shows something about the i2c.

I found out I was having some problems with my i2c while I was testing a PCA9548 (i2c multiplexer add:0x77) to control 8 VCNL4040 (proximity sensors add:0x60). I started testing only one sensor at a time and I created a for loop to read in which channel the sensor was.

# Configure I2C #

x = mraa.I2c(6) # Initialize i2c-6

x.address(0x77) # Address for PCA9548

for register in range(0x0, 0xFF):


VCNL_4040 = 0X60 # Sensor I2C address

DEVICE_ID = 0x0C # Register to check the device ID

PS_DATA = 0x08 # Register to read proximity data ...(see datasheet for more information)

_receive = [0,0]

vcnl = mraa.I2c(6)


vcnl.writeReg(DEVICE_ID, 0x00)


_receive[0] = vcnl.readWordReg(DEVICE_ID)

print "Reg: ", register, "ID:", int(_receive[0])

So it came the surprise! The sensor that was on channel 0 (SC0 & SD0) was supposed to show the sensor ID when the MUX register is 0x1, but it was showing the ID when the register was 0x7 (i.e. bits 0,1,2 on), the same happened with the sensors that were supposed to be on channels 1 and 2. The sensor on channel 3 was showing 0xB (bits 0,1,3 on), channel 4 0x13 (bits 0,1,4 on), channel 5 0x83 (bits 0,1,7 on), channel 6 0x43 (bits 0,1,6 on) and channel 7 0x23 (bits 0,1,5 on).

Does anyone have a clue about what is going on?


8 Replies

Hi martinianodl,

Could you tell me how did you configure the pins before attempting to connect your device?

Also, you might want to take a look at this workaround Apparently the user had a similar issue and was able to create a tool that emulates the role of i2ctools and manages to scan the devices successfully. I would suggest you to give a try.



New Contributor I

Hi PabloM_Intel,

What do you mean in how did I configure the pins?

I tried the m2ctool and it works! I can detect the MUX on address 0x77 now. The only problem is that I am still can't read the proximity sensors.

I ran the python code above and now the MUX registers are different from yesterday and keep changing every different run.

I also ran some tests using the i2cset to set the MUX registers using shell but I can't read the sensor on channel zero sending 0x1 to the MUX (same as the python code).

Do you think it's my MUX that is with problems?

Here is how I am wiring the MUX:

Thank you!

Lucas Martiniano de Oliveira

New Contributor II


i2cdetect -y -r 6

will make the system crach and is not recommended.

If your able to connect to the i2c(1) and not i2c(6) do that.

New Contributor I


I'm running some tests on my PCA9548A and I found out that when I choose channel 1 or above, it powers the desired channel with 2.28V and the rest of the channels with 2.25V. Even though when I choose all the channels at the same time (0xFF) it powers all the channels with 2.33V.

Also when I read which register is selected it returns me the right one.

Do you think it is normal? I can't find anything on the data sheet.

import mraa

import sys

x = mraa.I2c(6) # Initialize i2c-6

x.address(0x77) # Address for PCA9548

registers = [0x0, 0x1, 0x2, 0x4, 0x8, 0x10, 0x20, 0x40, 0x80, 0xFF]

i = int(str(sys.argv[1]))

print registers[i]


print x.readByte()

Thank you!

New Contributor II

Got any schematic of your connection to the PCA9548A?

is it like Fig. 14 on the data sheet? If it is the voltage on the pins are supposed to be high.

Are you reading voltage with multimeter or oscilloscope?

New Contributor I

Hi KimLorentz

I'm using a multimeter and the way I am connecting the PCA9548 the pins are not supposed to be high (I think).

I do have the schematic:

As you can see all the pull up resistors are wired to the Dip Switch and they are OFF (the proximity sensors don't work when they are ON).

The other switches are all ON, so the address of the PCA9548 is 0x77, which is weird according to the data sheet, although this address is the one that works.

I don't know if this is the best way to connect everything but as I printed the PCB and I as worried about something going wrong I did this way.

I also could figure out a way to read 5 sensors, when I write the Mux register starting with (0b111x xxxx) it works.


New Contributor II

Why do you use an i2c mux? cant you connect the i2c devices together?

One i2c buss can handle 127 devices(minus reserved addresses) or more depended on address bit resolution.

I only use mux if I got more sensors with the same address number.

New Contributor I

I'm using the i2c mux to connect the 8 i2c proximity sensors (VCNL4040) which they have the same address 0x60.