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

pozz <pozzugno@gmail.com> wrote:
> 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).
>
> 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).
>
> 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.

>
> [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

Il 08/11/2022 23:08, antispam@math.uni.wroc.pl ha scritto:
> pozz <pozzugno@gmail.com> wrote:
>> 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.

>> 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.

> 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.

>> 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.

>> [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
>

On 11/9/22 2:32 AM, pozz wrote:
> Il 08/11/2022 23:08, antispam@math.uni.wroc.pl ha scritto:
>> pozz <pozzugno@gmail.com> wrote:
>>> 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.

>
> 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.

>
>
>>> 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).

>
>> 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.
>
>
>>> 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.
>
>
>>> [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
>>
>

On Thursday, November 10, 2022 at 8:12:57 AM UTC-4, Richard Damon wrote:
> On 11/9/22 2:32 AM, pozz wrote:
> > Il 08/11/2022 23:08, anti...@math.uni.wroc.pl ha scritto:
> >> pozz <pozz...@gmail.com> wrote:
> >>> 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.
> >
> > 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.
> >
> >
> >>> 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).
> >
> >> 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.
> >
> >
> >>> 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 <pozzugno@gmail.com> wrote:
> Il 08/11/2022 23:08, antispam@math.uni.wroc.pl ha scritto:
> > pozz <pozzugno@gmail.com> wrote:
> >> 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.
>
>
> >> 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.
>
>
> > 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

Il 10/11/2022 13:12, Richard Damon ha scritto:
> On 11/9/22 2:32 AM, pozz wrote:
>> Il 08/11/2022 23:08, antispam@math.uni.wroc.pl ha scritto:
>>> pozz <pozzugno@gmail.com> wrote:
>>>> 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.
>
>>
>> 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

>>>> 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).

>>> 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.
>>
>>
>>>> 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.
>>
>>
>>>> [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
>>>
>>
>

On 2022-11-09, pozz <pozzugno@gmail.com> wrote:
>>
>> 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