Raspbian I2C default driver fails since change to kernel 4.9.y

[Hardy56]

I had a I2C connected sensor working fine for more than a year with raspbian jessie and kernel 4.4.y - then i decided to try an update to raspbian stretch 2 weeks ago.
With that I2C didn't work anymore.
Giving the command line $ i2cget -y 1 0x48 0x52 results in an invalid byte read (0xFF returned - 0x00 expected).
Stepwise downgrade showed up a clear correlation to the change to kernel 4.9.y . With kernel 4.4.y all works fine.
An i2c trace shows this result:

Reducing the baudrate results in a working transfer somewhere at baudrates of 4000 baud.
Going to rates in the range of 10k works for short transfers like single byte or word - not for blockread of up to 32 bytes. Looks like the timing issue sums up or is caused by latency.
A closer look to i2c trace at the time where repeated start should appear using a baudrate of 40k shows this:

The repeated start is corrupted having a gap of around 2.1 µsec instead of holding clock high while data going low.

Here a screenshot of a succesful transfer at 10k:

At this time the easiest workaround is to use the fallback to the old BCM2708 driver by inserting the respective line in config.txt . Although this driver doesn't perform a repeated start (which might save some time) it is working stable also at higher baudrates (tested up to 400k).
Also alternatives like PiGPIO are working well.
This issue might be the underlying root cause for older issue #828 .
I hope this post helps fixing the problem and i want to thank all the contributors for their great work at this place !

[mattallen37]

In my experience, it seems that the RPi fails to handle clock stretching under certain circumstances (as demonstrated here). When it goes to issue a repeated start, it assumes that SCL is high, and if a slave is holding it low (clock stretching), it will result in an invalid re-start. If the RPi would wait until SCL is released (high state) before a repeated start, I think it would work fine.

[Hardy56]

@mattallen37 , yes you're absolutely right!
Triggered by your nice suggestion i checked it. I inserted 100 Ohm series resistors in the clock and data lines close to the sensor and used a real oscilloscope this time, tapping the lines:

This was taken at 80 kbaud. Obviously clock stretching is performed in general, but fails only at the repeated start.
Short explanation for interpretation: By that 100 Ohm resistor sending a zero by the slave will result in round about 300 mV residue voltage at the line - low enough to be still operable, but now indicating the source of that action.
Thanks for your comment !

[mattallen37]

See this image for more details. I've noted the times in orange, circled the failure point in yellow, and circled the okay in green. Based on this, it seems that if the slave stretches the clock for less than 10uS (even if it's 9.94uS), the RPi fails to see it as a clock stretch, and goes on, pulling SCL low exactly 10uS after the previous fall. As seen here, that means SCL might only be high for as little as 0.06uS (60 nS)! This is far too short, and can lead to the slave not seeing the clock rise and fall. If SCL is held low for at least 10uS (10.05 as seen here), the RPi recognizes the clock stretch and adds 10uS to the clock cycle (allowing SCL to stay high for 9.95uS in this case, which is longer than necessary, but works fine).

What the RPi needs to do is hold the clock low for 5uS, then release it and wait for it to go high (once the slave releases it), and then not pull it back low until at least 5uS later.

*everything at standard 100kbps clock speed.

Note that I was using a 3.3v <> 5v I2C logic level shifter with the scope on the 5v side, but that's irrelevant of the timing issue.

[willd]

Has there been any work on this lately? It still seems to be an issue on 4.9.76.

[JamesH65]

@P33M Would it be worth trying 4.14? Have there been any changes in that branch?

BRANCH=next rpi-update

will get the latest bleeding edge 4.14 kernel.

[jakemagee]

Does anyone have the ability to test with an x86 machine? Is it possible this is an issue with the upstream i2c infrastructure rather than the RPi specific i2c driver?

[eddyedyy]

I am posting here as I think the problem is related.

I have tried different tutorials and forums where people had same/similar issues with i2c but still, I can't solve this problem.

I tried two different BMP180 Digital Barometric Pressure Sensor modules and even IIC/12C/TWI 1602 Serial LCD module

None of them showed up on the i2c detect -y 1

I have Raspberry PI 3 B and the following versions and Raspbian GNU/Linux 9 (stretch)
picture shows that only -- is the outcome for the i2cdetect -y 1 command
https://forums.adafruit.com/download/file.php?id=55367

Is there a solution or this is the issue that cannot be solved?

[pelwell]

You should not have both i2c drivers loaded - I'm not saying that is the cause of your problem, but it isn't right. All you need in config.txt is dtparam=i2c_arm=on.

[eddyedyy]

pelwell, thanks for your reply.

I tried to leave only dtparam=i2c_arm=on in config.txt but still, nothing changed.

[pelwell]

I found a BMP180 in a drawer and hooked it up to a Pi3 running 4.9 (and 4.14). In both cases the device was detected (with dtparam=i2c_arm=on):

pi@raspberrypi:~$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77

It also returned temperature and pressure (with dtoverlay=i2c-sensor,bmp180):

pi@raspberrypi:~$ cat /sys/bus/iio/devices/iio:device0/in_temp_input
54800
pi@raspberrypi:~$ cat /sys/bus/iio/devices/iio:device0/in_pressure_input
102.793000000

I don't know what your problem is, but it isn't the kernel version. Please post photos of your wiring.

[JamesH65]

This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

[JamesH65]

Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.