Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #31395

Re: I2C bus recovery

Show all headers | View raw

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
> 

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

I2C bus recovery pozz <pozzugno@gmail.com> - 2022-11-08 16:08 +0100
  Re: I2C bus recovery antispam@math.uni.wroc.pl - 2022-11-08 22:08 +0000
    Re: I2C bus recovery pozz <pozzugno@gmail.com> - 2022-11-09 08:32 +0100
      Re: I2C bus recovery Richard Damon <Richard@Damon-Family.org> - 2022-11-10 07:12 -0500
        Re: I2C bus recovery Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-10 09:06 -0800
        Re: I2C bus recovery pozz <pozzugno@gmail.com> - 2022-11-10 23:39 +0100
      Re: I2C bus recovery antispam@math.uni.wroc.pl - 2022-11-10 17:26 +0000
      Re: I2C bus recovery Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-13 10:52 +0000

csiph-web