Question about I2C Bus Recovery

[harriso...@gmail.com]

Hello all,

I have a quick question about the I2C bus on the Beaglebone Black. 

I have built a system with a number of I2C slaves, but sometimes (rarely, once in 50,000 communications or less) they seem to hang and hold the bus in a fixed state. The I2C standard in theory has a fix for this (toggling the CLK 9 times), which forces the slave to release the bus.

Is this fix implemented for the Beaglebone Black? I figured it might be only in recent Linux kernels, and hence I am upgrading my system to Debian 10/Linux 4.19 (previously it was the default Debian 8). However, I saw on a Raspberry Pi forum (here) that bus recovery functionality might be chip-specific, and so I worry that this may functionality may not exist for the AM335X. If not, how might I go about implementing it?

Thank you in advance for any assistance.

[gra...@flex-radio.com]

The method you refer to is not part of the "I2C Standard", but more a side effect of how I2C works,

so it is a "hack" to try to un-hang a bus, but no guarantee of success.

It is not implemented as an API call in Linux that I know of.

You might be able to trick the I2C hardware peripheral into doing this, by sending multiple repeated stops or bus resets, which are part of the API.

As the article you referenced says, the only sure way to send the 9 clock pulses is to de-initialize the I2C hardware peripheral, convert the two I2C pins temporarily back to GPIO pins and bit bang the pins to do what you want in software.

This might be difficult in Linux, since the kernel is very protective of any hardware peripherals and IO pins that have been assigned to it.

If you are getting a bus hang one out of 50,000 transactions, then there is something wrong with your bus implementation.

It should not do that.

Your time might be better spent reviewing your bus implementation: pull up values, bus capacitance, wire lengths, terminations, layout architecture, ground references, and noise environment.

Put a scope on the I2C lines and look at your signal integrity.

Slow down the I2C clock and see if the symptoms change.

--- Graham

==