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
9881 Discussions

High Speed Mode on Edison I2C Controller - not working


Hi everyone,

I have done some testing on the I2C controller on my Edison. Here are some info to identify my system:

I am using Yocto Linux 2.1 with the stock kernel 3.10.17-poky-edison+

My I2C device has vendor 0x8086 (Intel) and device number 0x1196. Apparently I am using the designware driver with model code merrifield_0 (according to i2c-designware-pcidrv.c).

Here is my issue: I am able to switch from std->fast->high speed mode through the /sys/devices/pci0000:00/0000:00:09.1/i2c_dw_sysnode/mode interface, but the clock speed that I measure on the bus with my oscilloscope has the following characteristics:

STD mode: around 100 kHz

FAST mode: around 375 kHz

HIGH mode: still around 385 kHz

So apparently the HIGH speed mode is not being enable correctly. Without the manual of the device it is impossible to decode what the driver is doing, but here is how it configures the merrifield_0 device:

/* Standard speed configuration */



/* Fast speed configuration */



/* High speed configuration - not working */



Can somebody with more knowledge give me some hint about how to enable high speed mode correctly?

4 Replies

Hello RenatoM,

Could you let us know how you measured those signals? Could you also add pictures of all measurements?



Hi Peter,

thanks for the interest. The methodology I used to acquire the measurements is the following:

1. I configure the I2C controller (nr. 6) on fast mode through the /sys interface

2. I run a C program that opens the i2c device-file with a given slave address - the slave address does not correspond to any device on the bus

3. I run a while-loop with a read operation on the device-file. Since no device answers on the bus, I get no data back, but that allows me to observe how the read request has been formed by the I2C controller on the bus using an oscilloscope.

4. I probe pins corresponding to GPIO 27 and GPIO 28 (I2C controller nr.6)

5. I measure the peak-to-peak duration and hence the frequency of the SCL signal.

I am attaching two pictures from my oscilloscope taken under "fast" and "high speed" configurations.

The picture above shows the behavior of the controller sending the address byte in "fast" configuration. The address (0x19) is correctly sent (0011001b), followed by a read bit (1b) and a NACK bit (since no device is answering). The clock speed outputted by the oscilloscope is 383 kHz. It can also be calculated using the timing between marker "a" and "b"

The picture above show the signals for the address byte generated by the controller in "high speed" mode. There are several problems with this signal. First, the clock is too low (again ~380 kHz) and it seems unstable toward the end of the byte. Moreover, the address byte now reads as: 000010011b = 0x04 (address - not what I sent) + read + NACK.

Hope it helps! Thanks again for your time.



hold on. I did a quick search for the high speed mode. Seems that what we see on the scope may be fine:

The transmission starts in fast speed mode and from the second byte on continues in high speed. Moreover, in high speed mode the first byte is a constant code: 0001XXX+NACK.

Next, the slave address is transmitted. It is hard to see from the figure if in this case the address byte is being formed correctly, but at least the signal may not be totally wrong. I need to test an actual communication with a high-speed capable device.

BTW: the clock speed in high-speed mode seems 833 kHz, which is far from the 3.4 MHz maximum, but may be ok.


I believe you are right, this might be the expected behavior from an I2C device connected to air. I believe you might find different results if you connect a device to it. Try to connect an I2C device to the board and try sending data to it, when doing so, measure it with the oscilloscope but also measure the clock signal so we can compare the timing to what we should expect. Also, remember to use pull-up resistors and that everything is connected properly, believe it or not those are the main reasons for I2C issues .