BCM2708 I²C driver stops working sometimes

[tyrel]

The I²C driver for the BCM2708 in the Raspbian kernel gets into a state sometimes where it can't send data anymore; every request to write() times out. This can be seen by running i2cdetect -r 1 from i2c-tools; normally it takes a fraction of a second to probe the bus, but it takes nearly two minutes under this situation because each request times out instead of returning almost immediately.

I'm using a Raspberry Pi 2, currently with kernel 4.1.19-v7+, but this issue has also been reported on 4.1.18-v7+ on both Raspberry Pi 2 and Zero here: http://raspberrypi.stackexchange.com/questions/43697/i2cdetect-on-raspberry-pi-kernel-4-1-18-v7-takes-115-seconds

This message appears in dmesg output for each attempt:

[28463.668743] i2c i2c-1: transfer timed out

My current workaround is to do this when I detect the situation:

sudo rmmod i2c_bcm2708
sudo rmmod i2c_dev
sudo modprobe i2c_dev
sudo modprobe i2c_bcm2708

However that is far from ideal, as I don't know I need to do it until I detect a failure, and then I have to try to do some sort of recovery.

[pelwell]

Can you give any further information about the failure mode:

• Does it always fail from boot, or does it sometimes work a few times before failing?
• Does it only occur when you are using certain devices?
• Anything else you can think of.

[tyrel]

More recently I've found that this is happening after I run my own program. I've attempted to create a small sample program that I could use to reproduce the issue and provide to you, but so far I haven't been able to reproduce the issue.

I'm having the exact same problem now with the serial port, so my code is doing something wrong but I haven't been able to figure out what. I'm definitely closing all the file descriptors I have open to these devices.

I will continue working on it and update this issue if I discover the cause, whether it's just me being a dummy or something actually wrong with the kernel or device drivers.

[ssvenn]

I struggled with this same behavior while setting up a UPS pico from pimodules, In the end it looks like the microcontroller on the UPS board had crashed and were jamming i2c communications. Once I reset the hardware i2cdetect worked normally again. Try disconnecting your i2c peripherals and see if i2cdetect runs at the regular speed! If that fixes it, maybe you have a bad connection or dodgy component in your circuit!

[taylo232]

Hi,
I am having the identical issues with i2cdetect (slow and not detecting devices - an MCP23017 in this case). I had a working breadboard project running perfectly on my Model B. I transferred it pin for pin to my A+ and had these issues. Running the script from tyrel immediately solved the issues. Raspbian, kernel, raspi-config and firmware updates all the latest on both devices.

[lategoodbye]

@taylo232
Please tell us which pins you are using?

[taylo232]

Hi, 3,5 for i2c (to MCP23017 - reset tied high and manual address pins tied low) 6 - gnd (to breadboard ground rail) 24, 26, 7 - GPIO8,7,4 for CE, RD, WR on ICs Breadboard has own regulated 3v3 supply (de-coupled at ICs). The only other attachment on the Pi is a USB wifi dongle. This slow i2cdetect and no i2c device recognition happens most (but not every) every time I switch on the Pi. I was using it this afternoon, for example, and the i2cdetect ran quickly but failed to recognise the device, re-ran the script (sudo rmmod 12c_ ... etc) and immediately the device was recognised at address 0x20. I just re-powered while I wrote this and I had the full slow execution and no detect which the script cured. I am also getting significant read and write errors but I haven't fully ruled out any physical causes in the circuit yet: -------------------------------------------- Sun Feb 12 19:15:39 2017 Number of tests: 1000 -------------------------------------------- Fatal read errors: 12 [ 1.2 % ] Fatal write errors*: 0 [ 0.0 % ] (*They occasionally crash the script) Data check errors: 241 [ 24.1 % ] -------------------------------------------- Just one thought (probably unrelated) I use a 0.85A power supply. Would this be too low and affect i2C operation? /proc/cpuinfo processor : 0 model name : ARMv6-compatible processor rev 7 (v6l) BogoMIPS : 697.95 Features : half thumb fastmult vfp edsp java tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xb76 CPU revision : 7 Hardware : BCM2708 Revision : 0015 Serial : 00000000a97b2d43

…

On 12/02/17 19:14, Stefan Wahren wrote: @taylo232 <https://github.com/taylo232> Please tell us which pins you are using? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1379 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFwYzWL1GiX4_QzjKJ4jo_QJAWqlvWjCks5rb1oNgaJpZM4H5lvP>.

[pelwell]

vcgencmd get_throttled will report any undervoltage issues, but 0.85A sounds inadequate.

[JamesH65]

Closing due to lack of activity. Reopen if you feel this issue is still relevant.

[tyrel]

It's still happening so I don't think this should be closed.

[tyrel]

I don't know how to re-open...

[popcornmix]

There should be a button marked "Reopen and comment" below the comment box.

[tyrel]

Sorry, that option is not there for me. There's only a Comment button, on both desktop and mobile.

[popcornmix]

Are you sure your power supply is sufficient?
(e.g. by measuring 5V voltage on gpio header when device is under load)

[JamesH65]

Please update to the latest kernel which may contain a fix for this issue.

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.

[tyrel]

Sorry, the project I was working on was shelved because I²C was too unreliable due to this persistent issue. I've been unable to test any newer kernels as a result.