Discussion:
I2C bus recovery
(too old to reply)
pozz
2022-11-08 15:08:52 UTC
Permalink
I wanted to implement an I2C bus recovery during initialization. The
reason is well known in literature[1].

I read the function i2c_generic_recovery[2] of Linux kernel, but I don't
understand one thing.

The bus recovery is necessary to bring a slave to the end of a byte
transmission that could be interrupted for some reason.
However the slave could be transmitting 0xFF, so why the above function
breaks the loop if SDA is detected high?

[Line 620] /* Break if SDA is high */

Maybe it's better to send 9 clock cycles whatever the level of SDA line.

And what about STOP condition at the end of the 9 clock cycles? Is it
necessary? It should be (SCL is already high): set SDA low, pause, set
SDA high.

Do you use this sort of bus recovery?


[1]
https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf

[2] https://elixir.bootlin.com/linux/v4.5/source/drivers/i2c/i2c-core.c#L604
a***@math.uni.wroc.pl
2022-11-08 22:08:52 UTC
Permalink
Post by pozz
I wanted to implement an I2C bus recovery during initialization. The
reason is well known in literature[1].
I read the function i2c_generic_recovery[2] of Linux kernel, but I don't
understand one thing.
The bus recovery is necessary to bring a slave to the end of a byte
transmission that could be interrupted for some reason.
However the slave could be transmitting 0xFF, so why the above function
breaks the loop if SDA is detected high?
[Line 620] /* Break if SDA is high */
With normal devices start followed by stop should reset state of the bus.
Howere, to send start we need SDA high. If this is bus with single
master SDA should be high at least at the end of byte (bus should
flat high as device waits for ACK).
Post by pozz
Maybe it's better to send 9 clock cycles whatever the level of SDA line.
I am not sure if this helps: writer is supposed to stop seeing new
start, so it is not clear if extra clock give anything for writers.
OTOH, if bus is clocked reader could get wrong data, so it seem
better to reset bus as soon as possible (that is first time when
SDA is high).
Post by pozz
And what about STOP condition at the end of the 9 clock cycles? Is it
necessary? It should be (SCL is already high): set SDA low, pause, set
SDA high.
Do you use this sort of bus recovery?
Well, I plan to do so. But I do not like to use untested code,
and to preperly test it I would need special driver to inject
various upsets to I2C bus.
Post by pozz
[1]
https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf
[2] https://elixir.bootlin.com/linux/v4.5/source/drivers/i2c/i2c-core.c#L604
--
Waldek Hebisch
pozz
2022-11-09 07:32:46 UTC
Permalink
Post by a***@math.uni.wroc.pl
Post by pozz
I wanted to implement an I2C bus recovery during initialization. The
reason is well known in literature[1].
I read the function i2c_generic_recovery[2] of Linux kernel, but I don't
understand one thing.
The bus recovery is necessary to bring a slave to the end of a byte
transmission that could be interrupted for some reason.
However the slave could be transmitting 0xFF, so why the above function
breaks the loop if SDA is detected high?
[Line 620] /* Break if SDA is high */
With normal devices start followed by stop should reset state of the bus.
Howere, to send start we need SDA high. If this is bus with single
master SDA should be high at least at the end of byte (bus should
flat high as device waits for ACK).
Do you think that a slave transmitting 0xFF interrupts the transmission
in the middle as soon as it detects a falling transition on SDA (STOP)?

Anyway, in this case the STOP transmission is necessary after reading
SDA high. I couldn't find the STOP transmission in the Linux kernel
code, only a few clock cycles until SDA is detected high.
Post by a***@math.uni.wroc.pl
Post by pozz
Maybe it's better to send 9 clock cycles whatever the level of SDA line.
I am not sure if this helps: writer is supposed to stop seeing new
start, so it is not clear if extra clock give anything for writers.
Yes, if the slave transmitting something stops after seeing a STOP (SDA
going low). I don't know it this is a well-known specification and if
all the I2C slaves implement this specification correctly.
Post by a***@math.uni.wroc.pl
OTOH, if bus is clocked reader could get wrong data, so it seem
better to reset bus as soon as possible (that is first time when
SDA is high).
What do you mean with reader? When the bus is stuck, the writer is the
slave and the reader should be the master that is trying to recovery the
bus, so technically it is not reading anything.

Are you thinking of a bus with multiple slaves? They shouldn't be
reading anything.
Post by a***@math.uni.wroc.pl
Post by pozz
And what about STOP condition at the end of the 9 clock cycles? Is it
necessary? It should be (SCL is already high): set SDA low, pause, set
SDA high.
Do you use this sort of bus recovery?
Well, I plan to do so. But I do not like to use untested code,
and to preperly test it I would need special driver to inject
various upsets to I2C bus.
Yes, this should be ideal, but it's not simple to inject errors in the
I2C bus, so I asked for some ideas and suggestions.
Post by a***@math.uni.wroc.pl
Post by pozz
[1]
https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf
[2] https://elixir.bootlin.com/linux/v4.5/source/drivers/i2c/i2c-core.c#L604
Richard Damon
2022-11-10 12:12:50 UTC
Permalink
Post by pozz
Post by a***@math.uni.wroc.pl
Post by pozz
I wanted to implement an I2C bus recovery during initialization. The
reason is well known in literature[1].
I read the function i2c_generic_recovery[2] of Linux kernel, but I don't
understand one thing.
The bus recovery is necessary to bring a slave to the end of a byte
transmission that could be interrupted for some reason.
However the slave could be transmitting 0xFF, so why the above function
breaks the loop if SDA is detected high?
     [Line 620] /* Break if SDA is high */
With normal devices start followed by stop should reset state of the bus.
Howere, to send start we need SDA high.  If this is bus with single
master SDA should be high at least at the end of byte (bus should
flat high as device waits for ACK).
Do you think that a slave transmitting 0xFF interrupts the transmission
in the middle as soon as it detects a falling transition on SDA (STOP)?
IT is suppossed to if it meets the standard. ANY change of SDA when SCL
is High resets the logic of every device on the bus in response to the
Start or Stop bit just sent.
Post by pozz
Anyway, in this case the STOP transmission is necessary after reading
SDA high. I couldn't find the STOP transmission in the Linux kernel
code, only a few clock cycles until SDA is detected high.
You don't need a STOP, you need either a start or stop. When you enable
the I2C controller and start a transmission, it will begin with a start,
and that will provide the needed reset.
Post by pozz
Post by a***@math.uni.wroc.pl
Post by pozz
Maybe it's better to send 9 clock cycles whatever the level of SDA line.
I am not sure if this helps: writer is supposed to stop seeing new
start, so it is not clear if extra clock give anything for writers.
Yes, if the slave transmitting something stops after seeing a STOP (SDA
going low). I don't know it this is a well-known specification and if
all the I2C slaves implement this specification correctly.
It is a well known requirement of the I2C specification that any start
or stop bit needs to reset the logic of devices.

Not all devices support it though, but if you have one that doesn't and
you get stuck like this, your only answer is some other form of reset
(like a power cycle).
Post by pozz
Post by a***@math.uni.wroc.pl
OTOH, if bus is clocked reader could get wrong data, so it seem
better to reset bus as soon as possible (that is first time when
SDA is high).
What do you mean with reader? When the bus is stuck, the writer is the
slave and the reader should be the master that is trying to recovery the
bus, so technically it is not reading anything.
Are you thinking of a bus with multiple slaves? They shouldn't be
reading anything.
Post by a***@math.uni.wroc.pl
Post by pozz
And what about STOP condition at the end of the 9 clock cycles? Is it
necessary? It should be (SCL is already high): set SDA low, pause, set
SDA high.
Do you use this sort of bus recovery?
Well, I plan to do so.  But I do not like to use untested code,
and to preperly test it I would need special driver to inject
various upsets to I2C bus.
Yes, this should be ideal, but it's not simple to inject errors in the
I2C bus, so I asked for some ideas and suggestions.
Post by a***@math.uni.wroc.pl
Post by pozz
[1]
https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf
[2]
https://elixir.bootlin.com/linux/v4.5/source/drivers/i2c/i2c-core.c#L604
Rick C
2022-11-10 17:06:42 UTC
Permalink
Post by Richard Damon
Post by pozz
Post by a***@math.uni.wroc.pl
Post by pozz
I wanted to implement an I2C bus recovery during initialization. The
reason is well known in literature[1].
I read the function i2c_generic_recovery[2] of Linux kernel, but I don't
understand one thing.
The bus recovery is necessary to bring a slave to the end of a byte
transmission that could be interrupted for some reason.
However the slave could be transmitting 0xFF, so why the above function
breaks the loop if SDA is detected high?
[Line 620] /* Break if SDA is high */
With normal devices start followed by stop should reset state of the bus.
Howere, to send start we need SDA high. If this is bus with single
master SDA should be high at least at the end of byte (bus should
flat high as device waits for ACK).
Do you think that a slave transmitting 0xFF interrupts the transmission
in the middle as soon as it detects a falling transition on SDA (STOP)?
IT is suppossed to if it meets the standard. ANY change of SDA when SCL
is High resets the logic of every device on the bus in response to the
Start or Stop bit just sent.
Post by pozz
Anyway, in this case the STOP transmission is necessary after reading
SDA high. I couldn't find the STOP transmission in the Linux kernel
code, only a few clock cycles until SDA is detected high.
You don't need a STOP, you need either a start or stop. When you enable
the I2C controller and start a transmission, it will begin with a start,
and that will provide the needed reset.
Post by pozz
Post by a***@math.uni.wroc.pl
Post by pozz
Maybe it's better to send 9 clock cycles whatever the level of SDA line.
I am not sure if this helps: writer is supposed to stop seeing new
start, so it is not clear if extra clock give anything for writers.
Yes, if the slave transmitting something stops after seeing a STOP (SDA
going low). I don't know it this is a well-known specification and if
all the I2C slaves implement this specification correctly.
It is a well known requirement of the I2C specification that any start
or stop bit needs to reset the logic of devices.
Not all devices support it though, but if you have one that doesn't and
you get stuck like this, your only answer is some other form of reset
(like a power cycle).
Post by pozz
Post by a***@math.uni.wroc.pl
OTOH, if bus is clocked reader could get wrong data, so it seem
better to reset bus as soon as possible (that is first time when
SDA is high).
What do you mean with reader? When the bus is stuck, the writer is the
slave and the reader should be the master that is trying to recovery the
bus, so technically it is not reading anything.
Are you thinking of a bus with multiple slaves? They shouldn't be
reading anything.
Post by a***@math.uni.wroc.pl
Post by pozz
And what about STOP condition at the end of the 9 clock cycles? Is it
necessary? It should be (SCL is already high): set SDA low, pause, set
SDA high.
Do you use this sort of bus recovery?
Well, I plan to do so. But I do not like to use untested code,
and to preperly test it I would need special driver to inject
various upsets to I2C bus.
Yes, this should be ideal, but it's not simple to inject errors in the
I2C bus, so I asked for some ideas and suggestions.
This is why when Intel wanted to use I2C on their motherboards, they made and improvement to have a time out on the bus, so all devices could reset out of a hang condition. I forget the name of their version, SMbus or something like that.

If you use chips rated for their spec, they will work.
--
Rick C.

--+++ Get 1,000 miles of free Supercharging
--+++ Tesla referral code - https://ts.la/richard11209
pozz
2022-11-10 22:39:44 UTC
Permalink
Post by Richard Damon
Post by pozz
Post by a***@math.uni.wroc.pl
Post by pozz
I wanted to implement an I2C bus recovery during initialization. The
reason is well known in literature[1].
I read the function i2c_generic_recovery[2] of Linux kernel, but I don't
understand one thing.
The bus recovery is necessary to bring a slave to the end of a byte
transmission that could be interrupted for some reason.
However the slave could be transmitting 0xFF, so why the above function
breaks the loop if SDA is detected high?
     [Line 620] /* Break if SDA is high */
With normal devices start followed by stop should reset state of the bus.
Howere, to send start we need SDA high.  If this is bus with single
master SDA should be high at least at the end of byte (bus should
flat high as device waits for ACK).
Do you think that a slave transmitting 0xFF interrupts the
transmission in the middle as soon as it detects a falling transition
on SDA (STOP)?
IT is suppossed to if it meets the standard. ANY change of SDA when SCL
is High resets the logic of every device on the bus in response to the
Start or Stop bit just sent.
Post by pozz
Anyway, in this case the STOP transmission is necessary after reading
SDA high. I couldn't find the STOP transmission in the Linux kernel
code, only a few clock cycles until SDA is detected high.
You don't need a STOP, you need either a start or stop. When you enable
the I2C controller and start a transmission, it will begin with a start,
and that will provide the needed reset.
I see, anyway I was looking at an old Linux kernel code. In the actual
code[1], a STOP condition is really sent before exitigin bus recovery
function.

[1]
https://github.com/torvalds/linux/blob/master/drivers/i2c/i2c-core-base.c#L200
Post by Richard Damon
Post by pozz
Post by a***@math.uni.wroc.pl
Post by pozz
Maybe it's better to send 9 clock cycles whatever the level of SDA line.
I am not sure if this helps: writer is supposed to stop seeing new
start, so it is not clear if extra clock give anything for writers.
Yes, if the slave transmitting something stops after seeing a STOP
(SDA going low). I don't know it this is a well-known specification
and if all the I2C slaves implement this specification correctly.
It is a well known requirement of the I2C specification that any start
or stop bit needs to reset the logic of devices.
Not all devices support it though, but if you have one that doesn't and
you get stuck like this, your only answer is some other form of reset
(like a power cycle).
Oh yes, I thought that a slave that had started a byte transmission
needed to receive 9 clock cycles to go to the end and reset its internal
state-machine. From what you say, this is not true. Even when a STOP
condition is detected in the middle of a byte transmissione, the I2C
device should reset I2C state machine.

Of course, if this I2C slave device is transmitting 0 (keeping SDA low),
it's impossible to create a STOP or START condition from the master. The
master needs to send clock cycle until the slave release SDA (because
the byte transmission is really finished or because it is transmitting a 1).
Post by Richard Damon
Post by pozz
Post by a***@math.uni.wroc.pl
OTOH, if bus is clocked reader could get wrong data, so it seem
better to reset bus as soon as possible (that is first time when
SDA is high).
What do you mean with reader? When the bus is stuck, the writer is the
slave and the reader should be the master that is trying to recovery
the bus, so technically it is not reading anything.
Are you thinking of a bus with multiple slaves? They shouldn't be
reading anything.
Post by a***@math.uni.wroc.pl
Post by pozz
And what about STOP condition at the end of the 9 clock cycles? Is it
necessary? It should be (SCL is already high): set SDA low, pause, set
SDA high.
Do you use this sort of bus recovery?
Well, I plan to do so.  But I do not like to use untested code,
and to preperly test it I would need special driver to inject
various upsets to I2C bus.
Yes, this should be ideal, but it's not simple to inject errors in the
I2C bus, so I asked for some ideas and suggestions.
Post by a***@math.uni.wroc.pl
Post by pozz
[1]
https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf
[2]
https://elixir.bootlin.com/linux/v4.5/source/drivers/i2c/i2c-core.c#L604
a***@math.uni.wroc.pl
2022-11-10 17:26:16 UTC
Permalink
Post by pozz
Post by a***@math.uni.wroc.pl
Post by pozz
I wanted to implement an I2C bus recovery during initialization. The
reason is well known in literature[1].
I read the function i2c_generic_recovery[2] of Linux kernel, but I don't
understand one thing.
The bus recovery is necessary to bring a slave to the end of a byte
transmission that could be interrupted for some reason.
However the slave could be transmitting 0xFF, so why the above function
breaks the loop if SDA is detected high?
[Line 620] /* Break if SDA is high */
With normal devices start followed by stop should reset state of the bus.
Howere, to send start we need SDA high. If this is bus with single
master SDA should be high at least at the end of byte (bus should
flat high as device waits for ACK).
Do you think that a slave transmitting 0xFF interrupts the transmission
in the middle as soon as it detects a falling transition on SDA (STOP)?
Anyway, in this case the STOP transmission is necessary after reading
SDA high. I couldn't find the STOP transmission in the Linux kernel
code, only a few clock cycles until SDA is detected high.
Post by a***@math.uni.wroc.pl
Post by pozz
Maybe it's better to send 9 clock cycles whatever the level of SDA line.
I am not sure if this helps: writer is supposed to stop seeing new
start, so it is not clear if extra clock give anything for writers.
Yes, if the slave transmitting something stops after seeing a STOP (SDA
going low). I don't know it this is a well-known specification and if
all the I2C slaves implement this specification correctly.
Post by a***@math.uni.wroc.pl
OTOH, if bus is clocked reader could get wrong data, so it seem
better to reset bus as soon as possible (that is first time when
SDA is high).
What do you mean with reader? When the bus is stuck, the writer is the
slave and the reader should be the master that is trying to recovery the
bus, so technically it is not reading anything.
Are you thinking of a bus with multiple slaves? They shouldn't be
reading anything.
If you see low on SDA this could be writer slave sending 0 or
reader slave sending ACK.
--
Waldek Hebisch
Michael Schwingen
2022-11-13 10:52:16 UTC
Permalink
Post by pozz
Post by a***@math.uni.wroc.pl
Well, I plan to do so. But I do not like to use untested code,
and to preperly test it I would need special driver to inject
various upsets to I2C bus.
Yes, this should be ideal, but it's not simple to inject errors in the
I2C bus, so I asked for some ideas and suggestions.
I had the same problem (testing error recovery code paths, and getting the
"stop at the right time" working on a STM32F1), so I made a special test
slave based on an AtMega88:

https://www.schwingen.org/i2c-fault-injection/

(You can use an arduino nano if you don't want to build your own PCB).

Together with test code on your host, and maybe a logic analyzer, this
allows rapidly testing lots of error events.

cu
Michael

Loading...