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

Groups > comp.arch.embedded > #31140 > unrolled thread

I2C Communication between two Microcontrollers

Back to article view | Back to comp.arch.embedded

Contents

  I2C Communication between two Microcontrollers Neelakantappa M <neelakantamaagi253@gmail.com> - 2022-07-05 06:28 -0700
    Re: I2C Communication between two Microcontrollers pozz <pozzugno@gmail.com> - 2022-07-05 16:22 +0200
    Re: I2C Communication between two Microcontrollers Richard Damon <Richard@Damon-Family.org> - 2022-07-05 22:33 -0400
    Re: I2C Communication between two Microcontrollers David Brown <david.brown@hesbynett.no> - 2022-07-06 08:49 +0200
      Re: I2C Communication between two Microcontrollers pozz <pozzugno@gmail.com> - 2022-07-06 09:52 +0200
        Re: I2C Communication between two Microcontrollers Stephen Pelc <stephen@vfxforth.com> - 2022-07-06 08:27 +0000
          Re: I2C Communication between two Microcontrollers pozz <pozzugno@gmail.com> - 2022-07-06 11:20 +0200
            Re: I2C Communication between two Microcontrollers Stef <me@this.is.invalid> - 2022-07-06 13:43 +0200
            Re: I2C Communication between two Microcontrollers Stephen Pelc <stephen@vfxforth.com> - 2022-07-06 15:49 +0000
          Re: I2C Communication between two Microcontrollers David Brown <david.brown@hesbynett.no> - 2022-07-06 11:52 +0200
            Re: I2C Communication between two Microcontrollers chris <chris-nospam@tridac.net> - 2022-07-07 17:19 +0100
              Re: I2C Communication between two Microcontrollers Dimiter_Popoff <dp@tgi-sci.com> - 2022-07-07 19:49 +0300
                Re: I2C Communication between two Microcontrollers Richard Damon <Richard@Damon-Family.org> - 2022-07-07 23:22 -0400
                  Re: I2C Communication between two Microcontrollers Mike Perkins <spam@spam.com> - 2022-08-05 22:07 +0100
                    Re: I2C Communication between two Microcontrollers Richard Damon <Richard@Damon-Family.org> - 2022-08-05 21:10 -0400

#31140 — I2C Communication between two Microcontrollers

I want to test the I2C protocol between two STM32 (STM32L152RC) microcontrollers. Can somebody guide me on how to do it or suggest tutorials?

I have seen some online portals where they are communicating between a microcontroller and any sensor. That I have done already. Now I want to test it between two MCU boards.

[toc] | [next] | [standalone]

#31141

Il 05/07/2022 15:28, Neelakantappa M ha scritto:
> I want to test the I2C protocol between two STM32 (STM32L152RC) microcontrollers. Can somebody guide me on how to do it or suggest tutorials?
> 
> I have seen some online portals where they are communicating between a microcontroller and any sensor. That I have done already. Now I want to test it between two MCU boards.

I don't know very well these MCUs, but I think ST ecosystem gives you 
all the examples that you need to start understanding I2C communication 
between two MCUs.

Of course, you need an example of master I2C and an example of slave I2C.

[toc] | [prev] | [next] | [standalone]

#31142

On 7/5/22 9:28 AM, Neelakantappa M wrote:
> I want to test the I2C protocol between two STM32 (STM32L152RC) microcontrollers. Can somebody guide me on how to do it or suggest tutorials?
> 
> I have seen some online portals where they are communicating between a microcontroller and any sensor. That I have done already. Now I want to test it between two MCU boards.

The key is (at least) one of the MCU's needs a I2C driver that responds 
as a slave device. Then the other one, the master, can send a I2C 
command and possibly get an answer.

[toc] | [prev] | [next] | [standalone]

#31143

On 05/07/2022 15:28, Neelakantappa M wrote:
> I want to test the I2C protocol between two STM32 (STM32L152RC)
> microcontrollers. Can somebody guide me on how to do it or suggest
> tutorials?
> 
> I have seen some online portals where they are communicating between
> a microcontroller and any sensor. That I have done already. Now I
> want to test it between two MCU boards.

I am always a little sceptical about using I²C between microcontrollers, 
and a lot more sceptical about using it between boards.  It can  be good 
enough in simple cases, but all too often I have seen systems that 
started out simple, and ended up trying to do far too much with I²C.

It is a protocol that works well with a microcontroller as the master 
communicating with slow slave devices (simple ADC/DACs, small EEPROMs, 
etc.) on the same board.  It works poorly when you need more data 
transfer or higher speeds, and can be quite inefficient on many 
microcontrollers when they are acting as slaves.

It is also less than ideal for off-board traffic.  For short range, with 
closely coupled ground and little electrical noise, it can work fine - 
but it does not work well over longer distances, and multi-master (or 
even multi-slave, with microcontroller slaves) can be very awkward.  I 
have seen systems where I²C has been used for bigger inter-card buses, 
and the effort required to make it stable, noise-free and reliable meant 
it was more costly and complex than alternatives such as CAN or RS-485 
would have been.

So my advice here is to think about where you are going in the future. 
I²C might be the most convenient protocol between two cards on your 
desk.  But will it be the best choice for the final product - or its 
future versions?  Obviously only you can answer that, but if it is not, 
then it is better to think about it now than later.

[toc] | [prev] | [next] | [standalone]

#31144

Il 06/07/2022 08:49, David Brown ha scritto:
> On 05/07/2022 15:28, Neelakantappa M wrote:
>> I want to test the I2C protocol between two STM32 (STM32L152RC)
>> microcontrollers. Can somebody guide me on how to do it or suggest
>> tutorials?
>>
>> I have seen some online portals where they are communicating between
>> a microcontroller and any sensor. That I have done already. Now I
>> want to test it between two MCU boards.
> 
> I am always a little sceptical about using I²C between microcontrollers, 
> and a lot more sceptical about using it between boards.  It can  be good 
> enough in simple cases, but all too often I have seen systems that 
> started out simple, and ended up trying to do far too much with I²C.
> 
> It is a protocol that works well with a microcontroller as the master 
> communicating with slow slave devices (simple ADC/DACs, small EEPROMs, 
> etc.) on the same board.  It works poorly when you need more data 
> transfer or higher speeds, and can be quite inefficient on many 
> microcontrollers when they are acting as slaves.
> 
> It is also less than ideal for off-board traffic.  For short range, with 
> closely coupled ground and little electrical noise, it can work fine - 
> but it does not work well over longer distances, and multi-master (or 
> even multi-slave, with microcontroller slaves) can be very awkward.  I 
> have seen systems where I²C has been used for bigger inter-card buses, 
> and the effort required to make it stable, noise-free and reliable meant 
> it was more costly and complex than alternatives such as CAN or RS-485 
> would have been.
> 
> So my advice here is to think about where you are going in the future. 
> I²C might be the most convenient protocol between two cards on your 
> desk.  But will it be the best choice for the final product - or its 
> future versions?  Obviously only you can answer that, but if it is not, 
> then it is better to think about it now than later.

I agree with David for all points, considering that I2C and UART need 
both only two pins (at least for single master and single slave) and 
that modern MCUs most probably can configure pins for I2C or UART.

Moreover I add I hate I2C even for simple slave devices, such as EEPROM 
or ADCs/DACs. I prefer much more a simple SPI, even if I have to waste a 
pin for every slave.

I found that I2C peripherals embedded in most of MCUs are very complex 
and most of the time they aren't reliable.
After some testing, I usually decide to write a bit-banging I2C code.

[toc] | [prev] | [next] | [standalone]

#31145

On 6 Jul 2022 at 09:52:23 CEST, "pozz" <pozzugno@gmail.com> wrote:

> I found that I2C peripherals embedded in most of MCUs are very complex
> and most of the time they aren't reliable.
> After some testing, I usually decide to write a bit-banging I2C code.

I have to agree here. I2C is conceptually simple, bu it is an edge triggered
protocol and is very sensitive to noise unless you use buffer devices. It
is excellent for master devices, but writing the slave software is much more
complex to cover all cases.

A client of ours carefully wrote hardware drivers for their CPUs and put
them on test. They saw one failure every hour or so. They then reverted
to the bit-bang drivers supplied by us with the compiler. No failures in two
weeks.

I have looked at these problems every few years or so, and the problem
for hardware drivers has always been fast noise pulses on the I2C lines.
By fast I mean up to several 10s of nanoseconds at a volt or so.

On the other hand we once did a hospital autoclave for which all I/O was
over I2C and it was rock solid ... but we used the recommended buffer
chips everywhere.

Stephen
-- 
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#31146

Il 06/07/2022 10:27, Stephen Pelc ha scritto:
> On 6 Jul 2022 at 09:52:23 CEST, "pozz" <pozzugno@gmail.com> wrote:
> 
>> I found that I2C peripherals embedded in most of MCUs are very complex
>> and most of the time they aren't reliable.
>> After some testing, I usually decide to write a bit-banging I2C code.
> 
> I have to agree here. I2C is conceptually simple, bu it is an edge triggered
> protocol and is very sensitive to noise unless you use buffer devices. 

Sorry for my stupid question, what do you mean with buffer devices?
When you have master and slave on the same board, you put a wire between 
SDA/SCL pins and a couple of pull-up resistors.


> It
> is excellent for master devices, but writing the slave software is much more
> complex to cover all cases. >
> A client of ours carefully wrote hardware drivers for their CPUs and put
> them on test. They saw one failure every hour or so. They then reverted
> to the bit-bang drivers supplied by us with the compiler. No failures in two
> weeks.

Same for me. I2C hardware peripherals don't add any pro against a 
bit-bang solution (I'm talking always for masters), at least if you 
write blocking code that waits for the end of I2C transaction.


> I have looked at these problems every few years or so, and the problem
> for hardware drivers has always been fast noise pulses on the I2C lines.
> By fast I mean up to several 10s of nanoseconds at a volt or so.

Yes, I think one solution is to reset and reconfigure the peripheral (if 
possible) when the software detects some problems.


> On the other hand we once did a hospital autoclave for which all I/O was
> over I2C and it was rock solid ... but we used the recommended buffer
> chips everywhere.

Again, what are buffer chips?

[toc] | [prev] | [next] | [standalone]

#31148

On 2022-07-06 pozz wrote in comp.arch.embedded:
> Il 06/07/2022 10:27, Stephen Pelc ha scritto:
>> On 6 Jul 2022 at 09:52:23 CEST, "pozz" <pozzugno@gmail.com> wrote:
>> 
>>> I found that I2C peripherals embedded in most of MCUs are very complex
>>> and most of the time they aren't reliable.
>>> After some testing, I usually decide to write a bit-banging I2C code.
>> 
>> I have to agree here. I2C is conceptually simple, bu it is an edge triggered
>> protocol and is very sensitive to noise unless you use buffer devices. 
>
> Sorry for my stupid question, what do you mean with buffer devices?
> When you have master and slave on the same board, you put a wire between 
> SDA/SCL pins and a couple of pull-up resistors.

Try a google search for "I2C buffer". ;-)

There are plenty.

I would not choose I2C for connection between 2 parts of a device, but
we have an existing device that uses I2C over a 2 meter cable and that
works quite well. There is an I2C multiplexer (PCA9548A) in the remote
part to select one of 8 I2C devices. (all same, so same adresses, so
cannot use adressing to select a device). This device uses this buffer
on both sides of the cable:

https://www.ti.com/product/P82B96

-- 
Stef

I want another RE-WRITE on my CEASAR SALAD!!

[toc] | [prev] | [next] | [standalone]

#31149

On 6 Jul 2022 at 11:20:34 CEST, "pozz" <pozzugno@gmail.com> wrote:

>> On the other hand we once did a hospital autoclave for which all I/O was
>> over I2C and it was rock solid ... but we used the recommended buffer
>> chips everywhere.
> 
> Again, what are buffer chips?

When the distance is further than normal (see spec) or the environment
is very electrically noisy, you need buffer chips to eliminate/reduce
noise problems, e.g.
 
https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/ic-bus-repeaters-hubs-extenders:MC_41849

In the autoclave, there were a number of switched mains devices.

The other application was in a powered railway carriage.

Stephen
-- 
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#31147

On 06/07/2022 10:27, Stephen Pelc wrote:
> On 6 Jul 2022 at 09:52:23 CEST, "pozz" <pozzugno@gmail.com> wrote:
> 
>> I found that I2C peripherals embedded in most of MCUs are very complex
>> and most of the time they aren't reliable.
>> After some testing, I usually decide to write a bit-banging I2C code.
> 
> I have to agree here. I2C is conceptually simple, bu it is an edge triggered
> protocol and is very sensitive to noise unless you use buffer devices. It
> is excellent for master devices, but writing the slave software is much more
> complex to cover all cases.
> 

A key problem for I²C is the multi-drop nature of the lines.  The edges 
themselves are not the big problem, it is the weak pull-up that leaves 
the lines very susceptible to noise and interference.  SPI has edges, as 
do most protocols with a clock signal, but there the master drives high 
and low, giving a far more "solid" line.

I²C can be fine in simple cases, but there are several less-used 
features that complicate it, especially when used together.  That 
includes multi-master, clock stretching, 10-bit addressing, and newer 
faster speeds.  Good luck trying to make a microcontroller slave that 
works with all of that!

There is also the possibility of bus hang and invalid states.  This can 
hit you during development - if you stop your microcontroller and 
restart it (perhaps with a new program version) in the middle of an I²C 
transaction, you can leave the slaves stuck - they may need a reset or 
power-cycle to recover.

[toc] | [prev] | [next] | [standalone]

#31150

On 07/06/22 10:52, David Brown wrote:
> On 06/07/2022 10:27, Stephen Pelc wrote:
>> On 6 Jul 2022 at 09:52:23 CEST, "pozz" <pozzugno@gmail.com> wrote:
>>
>>> I found that I2C peripherals embedded in most of MCUs are very complex
>>> and most of the time they aren't reliable.
>>> After some testing, I usually decide to write a bit-banging I2C code.
>>
>> I have to agree here. I2C is conceptually simple, bu it is an edge
>> triggered
>> protocol and is very sensitive to noise unless you use buffer devices. It
>> is excellent for master devices, but writing the slave software is
>> much more
>> complex to cover all cases.
>>
>
> A key problem for I²C is the multi-drop nature of the lines. The edges
> themselves are not the big problem, it is the weak pull-up that leaves
> the lines very susceptible to noise and interference. SPI has edges, as
> do most protocols with a clock signal, but there the master drives high
> and low, giving a far more "solid" line.
>
> I²C can be fine in simple cases, but there are several less-used
> features that complicate it, especially when used together. That
> includes multi-master, clock stretching, 10-bit addressing, and newer
> faster speeds. Good luck trying to make a microcontroller slave that
> works with all of that!
>
> There is also the possibility of bus hang and invalid states. This can
> hit you during development - if you stop your microcontroller and
> restart it (perhaps with a new program version) in the middle of an I²C
> transaction, you can leave the slaves stuck - they may need a reset or
> power-cycle to recover.

The original Iic from Philips was for consumer equipment and has
worked well for that sort of application, but it's not robust enough
for professional work imho. I would never use it unless an io
device needed it, such early Teletext devices. As you say spi
is a far better sorted design...

Chris

[toc] | [prev] | [next] | [standalone]

#31151

On 7/7/2022 19:19, chris wrote:
> On 07/06/22 10:52, David Brown wrote:
>> On 06/07/2022 10:27, Stephen Pelc wrote:
>>> On 6 Jul 2022 at 09:52:23 CEST, "pozz" <pozzugno@gmail.com> wrote:
>>>
>>>> I found that I2C peripherals embedded in most of MCUs are very complex
>>>> and most of the time they aren't reliable.
>>>> After some testing, I usually decide to write a bit-banging I2C code.
>>>
>>> I have to agree here. I2C is conceptually simple, bu it is an edge
>>> triggered
>>> protocol and is very sensitive to noise unless you use buffer 
>>> devices. It
>>> is excellent for master devices, but writing the slave software is
>>> much more
>>> complex to cover all cases.
>>>
>>
>> A key problem for I²C is the multi-drop nature of the lines. The edges
>> themselves are not the big problem, it is the weak pull-up that leaves
>> the lines very susceptible to noise and interference. SPI has edges, as
>> do most protocols with a clock signal, but there the master drives high
>> and low, giving a far more "solid" line.
>>
>> I²C can be fine in simple cases, but there are several less-used
>> features that complicate it, especially when used together. That
>> includes multi-master, clock stretching, 10-bit addressing, and newer
>> faster speeds. Good luck trying to make a microcontroller slave that
>> works with all of that!
>>
>> There is also the possibility of bus hang and invalid states. This can
>> hit you during development - if you stop your microcontroller and
>> restart it (perhaps with a new program version) in the middle of an I²C
>> transaction, you can leave the slaves stuck - they may need a reset or
>> power-cycle to recover.
> 
> The original Iic from Philips was for consumer equipment and has
> worked well for that sort of application, but it's not robust enough
> for professional work imho. I would never use it unless an io
> device needed it, such early Teletext devices. As you say spi
> is a far better sorted design...
> 
> Chris

I basically agree but things are not that bad as long as one
does not push things too far. For me the worst part has been dealing
with in-built I2C controllers, used two and both worked but each
took me *days* to defeat - unlike the first time I used I2C
some decades ago, bitbanging it from a HC11, which took me
only an hour or two.  Never used an MCU as an I2C slave yet, may
do so soon but who knows.
The peripherals I have used - some eeprom, RTC, ADC and perhaps
some I can't think of now have all behaved; of course one has to
deal with hanged bus situations, I have not seen a part which
needs repower to get fixed (must have been lucky I guess).
I have managed to upset the bus, being open drain, routing it
too close to a flyback convertor switch, the latter doing 100V
excursions "pretty fast" (tens of ns for the 100V I think).
Changing the pullups on the I2c from 2k to 1k fixed that
(still not that much of "too close", some luck again :).

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#31152

On 7/7/22 12:49 PM, Dimiter_Popoff wrote:
> On 7/7/2022 19:19, chris wrote:
>> On 07/06/22 10:52, David Brown wrote:
>>> On 06/07/2022 10:27, Stephen Pelc wrote:
>>>> On 6 Jul 2022 at 09:52:23 CEST, "pozz" <pozzugno@gmail.com> wrote:
>>>>
>>>>> I found that I2C peripherals embedded in most of MCUs are very complex
>>>>> and most of the time they aren't reliable.
>>>>> After some testing, I usually decide to write a bit-banging I2C code.
>>>>
>>>> I have to agree here. I2C is conceptually simple, bu it is an edge
>>>> triggered
>>>> protocol and is very sensitive to noise unless you use buffer 
>>>> devices. It
>>>> is excellent for master devices, but writing the slave software is
>>>> much more
>>>> complex to cover all cases.
>>>>
>>>
>>> A key problem for I²C is the multi-drop nature of the lines. The edges
>>> themselves are not the big problem, it is the weak pull-up that leaves
>>> the lines very susceptible to noise and interference. SPI has edges, as
>>> do most protocols with a clock signal, but there the master drives high
>>> and low, giving a far more "solid" line.
>>>
>>> I²C can be fine in simple cases, but there are several less-used
>>> features that complicate it, especially when used together. That
>>> includes multi-master, clock stretching, 10-bit addressing, and newer
>>> faster speeds. Good luck trying to make a microcontroller slave that
>>> works with all of that!
>>>
>>> There is also the possibility of bus hang and invalid states. This can
>>> hit you during development - if you stop your microcontroller and
>>> restart it (perhaps with a new program version) in the middle of an I²C
>>> transaction, you can leave the slaves stuck - they may need a reset or
>>> power-cycle to recover.
>>
>> The original Iic from Philips was for consumer equipment and has
>> worked well for that sort of application, but it's not robust enough
>> for professional work imho. I would never use it unless an io
>> device needed it, such early Teletext devices. As you say spi
>> is a far better sorted design...
>>
>> Chris
> 
> I basically agree but things are not that bad as long as one
> does not push things too far. For me the worst part has been dealing
> with in-built I2C controllers, used two and both worked but each
> took me *days* to defeat - unlike the first time I used I2C
> some decades ago, bitbanging it from a HC11, which took me
> only an hour or two.  Never used an MCU as an I2C slave yet, may
> do so soon but who knows.
> The peripherals I have used - some eeprom, RTC, ADC and perhaps
> some I can't think of now have all behaved; of course one has to
> deal with hanged bus situations, I have not seen a part which
> needs repower to get fixed (must have been lucky I guess).
> I have managed to upset the bus, being open drain, routing it
> too close to a flyback convertor switch, the latter doing 100V
> excursions "pretty fast" (tens of ns for the 100V I think).
> Changing the pullups on the I2c from 2k to 1k fixed that
> (still not that much of "too close", some luck again :).
> 
> ======================================================
> Dimiter Popoff, TGI             http://www.tgi-sci.com
> ======================================================
> http://www.flickr.com/photos/didi_tgi/

My experience is that to handle a "stuck" I2C bus, sometimes you need to 
be able to turn "off" the I2C controller and manually "bit-bang" up to 
(generally) 8 I2C clock pulses, until the slave that is stuck lets go of 
the I2C Data line, then you can force a START-STOP code (by pulling the 
data line low then high with the clock high) to get the bus into a 
usable state.

If that doesn't work, then you have a non-conforming device.

I do remember one time working with a slave that if you addressed it too 
soon after power up, it would go into clock streach mode (pulling down 
the clock) but never leave that mode. For that case the only option was 
to power down that device, and then power it back up and wait long enough.

[toc] | [prev] | [next] | [standalone]

#31173

On 08/07/2022 04:22, Richard Damon wrote:
> On 7/7/22 12:49 PM, Dimiter_Popoff wrote:
>> On 7/7/2022 19:19, chris wrote:
>>> On 07/06/22 10:52, David Brown wrote:
>>>> On 06/07/2022 10:27, Stephen Pelc wrote:
>>>>> On 6 Jul 2022 at 09:52:23 CEST, "pozz" <pozzugno@gmail.com> wrote:
>>>>>
>>>>>> I found that I2C peripherals embedded in most of MCUs are very 
>>>>>> complex
>>>>>> and most of the time they aren't reliable.
>>>>>> After some testing, I usually decide to write a bit-banging I2C code.
>>>>>
>>>>> I have to agree here. I2C is conceptually simple, bu it is an edge
>>>>> triggered
>>>>> protocol and is very sensitive to noise unless you use buffer 
>>>>> devices. It
>>>>> is excellent for master devices, but writing the slave software is
>>>>> much more
>>>>> complex to cover all cases.
>>>>>
>>>>
>>>> A key problem for I²C is the multi-drop nature of the lines. The edges
>>>> themselves are not the big problem, it is the weak pull-up that leaves
>>>> the lines very susceptible to noise and interference. SPI has edges, as
>>>> do most protocols with a clock signal, but there the master drives high
>>>> and low, giving a far more "solid" line.
>>>>
>>>> I²C can be fine in simple cases, but there are several less-used
>>>> features that complicate it, especially when used together. That
>>>> includes multi-master, clock stretching, 10-bit addressing, and newer
>>>> faster speeds. Good luck trying to make a microcontroller slave that
>>>> works with all of that!
>>>>
>>>> There is also the possibility of bus hang and invalid states. This can
>>>> hit you during development - if you stop your microcontroller and
>>>> restart it (perhaps with a new program version) in the middle of an I²C
>>>> transaction, you can leave the slaves stuck - they may need a reset or
>>>> power-cycle to recover.
>>>
>>> The original Iic from Philips was for consumer equipment and has
>>> worked well for that sort of application, but it's not robust enough
>>> for professional work imho. I would never use it unless an io
>>> device needed it, such early Teletext devices. As you say spi
>>> is a far better sorted design...
>>>
>>> Chris
>>
>> I basically agree but things are not that bad as long as one
>> does not push things too far. For me the worst part has been dealing
>> with in-built I2C controllers, used two and both worked but each
>> took me *days* to defeat - unlike the first time I used I2C
>> some decades ago, bitbanging it from a HC11, which took me
>> only an hour or two.  Never used an MCU as an I2C slave yet, may
>> do so soon but who knows.
>> The peripherals I have used - some eeprom, RTC, ADC and perhaps
>> some I can't think of now have all behaved; of course one has to
>> deal with hanged bus situations, I have not seen a part which
>> needs repower to get fixed (must have been lucky I guess).
>> I have managed to upset the bus, being open drain, routing it
>> too close to a flyback convertor switch, the latter doing 100V
>> excursions "pretty fast" (tens of ns for the 100V I think).
>> Changing the pullups on the I2c from 2k to 1k fixed that
>> (still not that much of "too close", some luck again :).
>>
>> ======================================================
>> Dimiter Popoff, TGI             http://www.tgi-sci.com
>> ======================================================
>> http://www.flickr.com/photos/didi_tgi/
> 
> My experience is that to handle a "stuck" I2C bus, sometimes you need to 
> be able to turn "off" the I2C controller and manually "bit-bang" up to 
> (generally) 8 I2C clock pulses, until the slave that is stuck lets go of 
> the I2C Data line, then you can force a START-STOP code (by pulling the 
> data line low then high with the clock high) to get the bus into a 
> usable state.
Isn't that why SMBus was invented?

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

[toc] | [prev] | [next] | [standalone]

#31174

On 8/5/22 5:07 PM, Mike Perkins wrote:
> On 08/07/2022 04:22, Richard Damon wrote:
>>
>> My experience is that to handle a "stuck" I2C bus, sometimes you need 
>> to be able to turn "off" the I2C controller and manually "bit-bang" up 
>> to (generally) 8 I2C clock pulses, until the slave that is stuck lets 
>> go of the I2C Data line, then you can force a START-STOP code (by 
>> pulling the data line low then high with the clock high) to get the 
>> bus into a usable state.
> Isn't that why SMBus was invented?
> 

That handles it, but only if ALL your devices support it. The "Stuck 
Device" might be a device that doesn't support SMB bus, and might not 
normally need to, because it is just a simple slave that never clock 
streaches, so shouldn't be able to have a problem on a working bus.

The issue can happen if the controller get aborted mid-read-transfer, so 
the slave is driving the data bus (low) so a master can't assert a Start 
or Stop to reset the devices.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web