[SI-LIST] Re: I2C Noise
- From: steve weir <weirsp@xxxxxxxxxx>
- To: for_si2003@xxxxxxxxx, si-list@xxxxxxxxxxxxx
- Date: Mon, 24 May 2004 11:27:03 -0700
VK, you slipped a couple of decimal points on the current rating=20
there. The spec is 3.0mA, not 300mA.
More capacitance favors lower resistance, not higher. The minimum=20
resistance and required Tr/Tf ( 250ns in standard mode ) dictate the=20
maximum tolerable capacitance. The only reasons that I know of to use=20
higher value resistors than the minimum allowed are:
1) Reduce power consumption in low power systems.
2) Multiple pull-ups in systems with mixed voltages, and/or FRUs.
Steve.
At 11:12 AM 5/24/2004 -0700, V S wrote:
>I2C specification says that the maximum sink current
>can not exceed 300mA. Assuming 3.3V supply that gives
>a MINIMUM value of pull up resistor to be R =3D 3.3 V /
>300mA =3D 1.1 k.
>
>If you keep R less than 1.1k , you are likely to cause
>current flow more than than the recommended 300mA that
>could possibly damage device.
>
>As far as th,e that quesstion of what exactly should
>be the pull up value, we need to consider the total
>loading capacitance of the Bus. I2C says that the
>total loading capacitance not exceed 400 pf. That
>include trace and the device capacitance. Let us
>design with the worst case loading capacitance of
>400pf , the RC time constant of 400pf x 2k =3D 800ns.
>This figure has to be compared to the CLK period of
>10000 ns for a 100 KHz I2C frequency.
>
> >From the timing point of view, it is better if we have
>a faster rising edge. This means that we should have
>RC as small as possible and that makes us choose low R
>value.
>
>But we also see that 800ns is very small as compared
>to 10000 ns, so we may increase the value of R to 4.7
>k that makes RC to 1680ns for 400 pf capacitive
>loading.
>
>If particular cicuit has very few devices on the bus
>that 400pf is never going to be reached and we get
>faster rising edge.
>
>So the resitor value does not seem to be big deal for
>100kHz , whether we choose 2.0k or 4.7k.
>
>That leaves the I2C bus suspectible to cross talk.
>Since we think that the long traces are not going to
>cause problem, we may tempt to route I2C very-very
>long. This long length tends to create cross talk
>problem, especially if edges near to I2C are steep
>ones. I2C bus is as susceptible to cross talk noise as
>are other bus. So care must be taken to make it immune
>to these cross talk.
>
>
>
>--- Chris McGrath <chris.mcgrath@xxxxxxxx> wrote:
> > IIC does not cite a specific pullup value but rather
> > a range of values
> > that includes 4.7k. We have found that an ideal
> > value depends on the
> > chips that you use, but 4.7k worked fine for us on
> > some designs.
> >
> > > -----Original Message-----
> > > From: k EPD [mailto:epd2001usa@xxxxxxxxxxx]=3D20
> > > Sent: Saturday, May 22, 2004 4:31 PM
> > > To: weirsp@xxxxxxxxxx;
> > Christopher.Jakubiec@xxxxxxx
> > > Cc: si-list@xxxxxxxxxxxxx
> > > Subject: [SI-LIST] Re: I2C Noise
> > >=3D20
> > >=3D20
> > > =3D20
> > > I^2 requires a 1.6k pullup , does you circuitry
> > have that? =3D20
> > > Also I would
> > > like to agree with a x-talk problem with other
> > lines , check=3D20
> > > you frequency and you coupling to you clock or
> > data line for=3D20
> > > the i^2C buss....=3D20
> > >=3D20
> > >=3D20
> > >=3D20
> > >=3D20
> > > Keith Kowal 781-593-0199 epd2001usa@xxxxxxxxxxx[1]
> > [2] =3D20
> > > >From: steve weir
> > > <weirsp@xxxxxxxxxx> >Reply-To: weirsp@xxxxxxxxxx
> > >To:=3D20
> > > Christopher.Jakubiec@xxxxxxx >CC:
> > si-list@xxxxxxxxxxxxx=3D20
> > > >Subject: [SI-LIST]
> > > Re: I2C Noise >Date: Fri, 21 May 2004 16:53:15
> > -0700 >>Chris,=3D20
> > > from your description, it does sound like you are
> > suffering=3D20
> > > from >crosstalk. I2C devices are supposed to
> > debounce both=3D20
> > > SCL and SDA in the >100KHz mode, and soeven with a
> > lot of=3D20
> > > crosstalk, you should not have seen >errors.
> > Unfortunately,=3D20
> > > there is a lot of silicon that violates the spec.
> > >Regards,
> > > >>>Steve >At 03:24 PM 5/21/2004 -0700, Christopher
> > Jakubiec wrote:=3D20
> > > >>>>>Steve,
> > > >>>>Thanks for your insight. Yes, I meant to state
> > 100kHz instead of=3D20
> > > >>>>100mHz. I think that we might be dealing with
> > item 2 (noise=3D20
> > > >>>>>>coupling) as you
> > > described below. We have 3 AC/DC power supplies
> > that each=3D20
> > > >>operate on dual power grids for redundancy
> > purposes. Each=3D20
> > > power supply has 2 >>sets of I2C wires connected
> > to it, one=3D20
> > > for each power grid. I believe >>that each >>set
> > consists of=3D20
> > > SCL, SDA, VDD, VSS. At one point in the system all
> > 6 sets=3D20
> > > >>of I2C >>wires are bundled together. >>>>On a
> > system that=3D20
> > > was failing fairly consistently, we >>went in and
> > seperated=3D20
> > > the cumulative bundle into individual sets by
> > >>physical=3D20
> > > distance. >>We have not seen the failure replicate
> > since. I=3D20
> > > don't believe that the >>orginal wire >>routing
> > included any=3D20
> > > special shielding. I can confirm with a digital
> > >>scope per your
> > > >>suggestion. >>>>-Chris >>>>>>steve weir wrote:
> > >>>>>>Chris,=3D20
> > > >>>>>>I2C=3D20
> > > >>is a
> > > very high impedance bus, typically 4700 ohms
> > pull-up. I think=3D20
> > > you >>>mean 100Kbps, the legacy mode. It is easy
> > to mess I2C=3D20
> > > up with grounding
> > > >>>issues.The states tha t you are referring to
> > are probably being=3D20
> > > >>>conveyed via IPMB over I2C or similar. There
> > are several=3D20
> > > things that=3D20
> > > >>>can go wrong:
> > > >>>>>>1) Incorrect grounding is fouling basic I2C
> > signaling.=3D20
> > > >>>2) Noise
> > > coupling is fouling I2C signaling. >>>3) Voltage
> > translation=3D20
> > > issues. The original I2C bus was 5V TTL. Mixed
> > >>>voltages=3D20
> > > can also cause grief, as can hot swap. >>>>>>Check
> > 1 and 2=3D20
> > > with any of the many I2C analyzers available, or
> > just put a=3D20
> > > >>>scope on the SCL line in infinite persistance.
> > >>>>>>4) An=3D20
> > > aberrant device is violating I2C bus negotiation
> > contending with the
> > > >>>actual master and fouling SCL, SDA or both..
> > >>>>>>5) Your=3D20
> > > >>>misbehaving
> > > peripheral is a poor implementation of I2C and/or
> > >>>whatever=3D20
> > > protocol you may be running on top of it. Some
> > devices do not=3D20
> > > >>>implement the timing as per the spec. This can
> > be=3D20
> > > particularly true of >>>microcontrollers that do
> > not include=3D20
> > > dedicated I2C hardware. But even a >>>number that
> > do violate=3D20
> > > the specs, or rely on careful programming to
> > comply. >>>>>>I=3D20
> > > would start by looking at the SCL line with a
> > decent digital=3D20
> > > scope >>>first. If you don't find your problem
> > there it is=3D20
> > > time to look for mixed >>>voltage and/or hot-swap
> > issues. If=3D20
> > > you get all that worked out, then I >>>would move
> > up to the=3D20
> > > link layer and see if you are a victim of some bad
> > >>>firmware.
> > > >>>>>>Regards, >>>>>>Steve >>>>>>At 02:04 PM
> > 5/21/2004 -0700,=3D20
> > > >>>>>>Christopher
> > > Jakubiec wrote: >>>>All, >>>>>>>>Has anyone
> > encountered=3D20
> > > problems with EMI/noise issues on I2C wires
> > and/or=3D20
> > > >>>>busses? We use industry standard I2Cto
> > interface with our=3D20
> > > bul k 208V/48V >>>>AC/DC power supplies. We are
> > observing=3D20
> > > instances where control and status >>>>signals
> > (connected via=3D20
> > > I2C) for the AC/DC power supplies appear to be=3D20
> > > >>>>intermittently >>>>in the wrongstate. I
> > believe that we=3D20
> > > are currently running the I2C clock >>>>signal at
> > >>>>100MHz,=3D20
> > > and our wire lengths are significant on the order
> > of 2-3ft.
> > > >>>>>>>>Thanks, >>>>>>>>Chris Jakubiec >>>>Sun
> > Microsystems
> > >
> >
> >>>>------------------------------------------------------------------
> > > >>>>Tounsubscribe from si-list:
> > >>>>si-list-request@xxxxxxxxxxxxx with
> > > 'unsubscribe' in the Subject field >>>>>>>>or to
> > administer=3D20
> > > your membership from a web page, go to:=3D20
> > > >>>>http://www.freelists.org/webpage/si-list
> > >>>>>>>&g t;For=3D20
> > > help: >>>>si-list-request@xxxxxxxxxxxxx with
> > 'help' in the=3D20
> > > Subject field >>>>>>>>List FAQ wiki page is
> > located at:
> > > >>>>http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> > >>>>>>>>List technical
> > > documents are available at:
> > >>>>http://www.si-list.org=3D20
> > > >>>>>>>>List archives are viewable at:=3D20
> > > >>>>http://www.freelists.org/archives/si-list
> > >>>>or at our=3D20
> > > remote archives:=3D20
> > > >>>>http://groups.yahoo.com/group/si-list/messages
> > >>>>Old=3D20
> > > (prior to June 6, 2001) list archives are viewable
> > at:
> > > >>>>http://www.qsl.net/wb6tpu
> > >
> >
> >>>>>>>-------------------------------------------------------
> > > ----------
> > > >>>>>>>-
> > > >Tounsubscribe from si-list:
> > >si-list-request@xxxxxxxxxxxxx with
> > > 'unsubscribe' in the Subject field >>or to
> > administer your=3D20
> > > membership from a web pag e, go to:=3D20
> > >http://www.freelists.org/webpage/si-list >>For
> > help:
> > >si-list-request@xxxxxxxxxxxxx with 'help' in the
> > Subject field >>List=3D20
> > >FAQ
> > wiki page is located at:
> > >http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> > >>List technical documents are available at:
> > >http://www.si-list.org
> > >>List archivesare viewable at:
> >
>=3D=3D=3D message truncated =3D=3D=3D
>
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Domains =AD Claim yours for only $14.70/year
>http://smallbusiness.promotions.yahoo.com/offer
>------------------------------------------------------------------
>To unsubscribe from si-list:
>si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
>or to administer your membership from a web page, go to:
>http://www.freelists.org/webpage/si-list
>
>For help:
>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
>List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
>List technical documents are available at:
> http://www.si-list.org
>
>List archives are viewable at:
> http://www.freelists.org/archives/si-list
>or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
>Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
http://www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
- References:
- [SI-LIST] Re: I2C Noise
- From: Chris McGrath
- [SI-LIST] Re: I2C Noise
- From: V S
Other related posts:
- » [SI-LIST] I2C Noise
- » [SI-LIST] Re: I2C Noise
- » [SI-LIST] Re: I2C Noise
- » [SI-LIST] Re: I2C Noise
- » [SI-LIST] Re: I2C Noise
- » [SI-LIST] Re: I2C Noise
- » [SI-LIST] Re: I2C Noise
- » [SI-LIST] Re: I2C Noise
- » [SI-LIST] Re: I2C Noise
- [SI-LIST] Re: I2C Noise
- From: Chris McGrath
- [SI-LIST] Re: I2C Noise
- From: V S