R = 3.3 V / 300mA = 11 Ohms not 1.1 k. Tom Dagostino Teraspeed Consulting Group LLC 503-430-1065 tom@xxxxxxxxxxxxx www.teraspeed.com -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of V S Sent: Monday, May 24, 2004 11:12 AM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: I2C Noise 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 = 3.3 V / 300mA = 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 = 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]=20 > > Sent: Saturday, May 22, 2004 4:31 PM > > To: weirsp@xxxxxxxxxx; > Christopher.Jakubiec@xxxxxxx > > Cc: si-list@xxxxxxxxxxxxx > > Subject: [SI-LIST] Re: I2C Noise > >=20 > >=20 > > =20 > > I^2 requires a 1.6k pullup , does you circuitry > have that? =20 > > Also I would > > like to agree with a x-talk problem with other > lines , check=20 > > you frequency and you coupling to you clock or > data line for=20 > > the i^2C buss....=20 > >=20 > >=20 > >=20 > >=20 > > Keith Kowal 781-593-0199 epd2001usa@xxxxxxxxxxx[1] > [2] =20 > > >From: steve weir > > <weirsp@xxxxxxxxxx> >Reply-To: weirsp@xxxxxxxxxx > >To:=20 > > Christopher.Jakubiec@xxxxxxx >CC: > si-list@xxxxxxxxxxxxx=20 > > >Subject: [SI-LIST] > > Re: I2C Noise >Date: Fri, 21 May 2004 16:53:15 > -0700 >>Chris,=20 > > from your description, it does sound like you are > suffering=20 > > from >crosstalk. I2C devices are supposed to > debounce both=20 > > SCL and SDA in the >100KHz mode, and soeven with a > lot of=20 > > crosstalk, you should not have seen >errors. > Unfortunately,=20 > > there is a lot of silicon that violates the spec. > >Regards, > > >>>Steve >At 03:24 PM 5/21/2004 -0700, Christopher > Jakubiec wrote:=20 > > >>>>>Steve, > > >>>>Thanks for your insight. Yes, I meant to state > 100kHz instead of=20 > > >>>>100mHz. I think that we might be dealing with > item 2 (noise=20 > > >>>>>>coupling) as you > > described below. We have 3 AC/DC power supplies > that each=20 > > >>operate on dual power grids for redundancy > purposes. Each=20 > > power supply has 2 >>sets of I2C wires connected > to it, one=20 > > for each power grid. I believe >>that each >>set > consists of=20 > > SCL, SDA, VDD, VSS. At one point in the system all > 6 sets=20 > > >>of I2C >>wires are bundled together. >>>>On a > system that=20 > > was failing fairly consistently, we >>went in and > seperated=20 > > the cumulative bundle into individual sets by > >>physical=20 > > distance. >>We have not seen the failure replicate > since. I=20 > > don't believe that the >>orginal wire >>routing > included any=20 > > special shielding. I can confirm with a digital > >>scope per your > > >>suggestion. >>>>-Chris >>>>>>steve weir wrote: > >>>>>>Chris,=20 > > >>>>>>I2C=20 > > >>is a > > very high impedance bus, typically 4700 ohms > pull-up. I think=20 > > you >>>mean 100Kbps, the legacy mode. It is easy > to mess I2C=20 > > up with grounding > > >>>issues.The states tha t you are referring to > are probably being=20 > > >>>conveyed via IPMB over I2C or similar. There > are several=20 > > things that=20 > > >>>can go wrong: > > >>>>>>1) Incorrect grounding is fouling basic I2C > signaling.=20 > > >>>2) Noise > > coupling is fouling I2C signaling. >>>3) Voltage > translation=20 > > issues. The original I2C bus was 5V TTL. Mixed > >>>voltages=20 > > can also cause grief, as can hot swap. >>>>>>Check > 1 and 2=20 > > with any of the many I2C analyzers available, or > just put a=20 > > >>>scope on the SCL line in infinite persistance. > >>>>>>4) An=20 > > aberrant device is violating I2C bus negotiation > contending with the > > >>>actual master and fouling SCL, SDA or both.. > >>>>>>5) Your=20 > > >>>misbehaving > > peripheral is a poor implementation of I2C and/or > >>>whatever=20 > > protocol you may be running on top of it. Some > devices do not=20 > > >>>implement the timing as per the spec. This can > be=20 > > particularly true of >>>microcontrollers that do > not include=20 > > dedicated I2C hardware. But even a >>>number that > do violate=20 > > the specs, or rely on careful programming to > comply. >>>>>>I=20 > > would start by looking at the SCL line with a > decent digital=20 > > scope >>>first. If you don't find your problem > there it is=20 > > time to look for mixed >>>voltage and/or hot-swap > issues. If=20 > > you get all that worked out, then I >>>would move > up to the=20 > > link layer and see if you are a victim of some bad > >>>firmware. > > >>>>>>Regards, >>>>>>Steve >>>>>>At 02:04 PM > 5/21/2004 -0700,=20 > > >>>>>>Christopher > > Jakubiec wrote: >>>>All, >>>>>>>>Has anyone > encountered=20 > > problems with EMI/noise issues on I2C wires > and/or=20 > > >>>>busses? We use industry standard I2Cto > interface with our=20 > > bul k 208V/48V >>>>AC/DC power supplies. We are > observing=20 > > instances where control and status >>>>signals > (connected via=20 > > I2C) for the AC/DC power supplies appear to be=20 > > >>>>intermittently >>>>in the wrongstate. I > believe that we=20 > > are currently running the I2C clock >>>>signal at > >>>>100MHz,=20 > > 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=20 > > your membership from a web page, go to:=20 > > >>>>//www.freelists.org/webpage/si-list > >>>>>>>&g t;For=20 > > help: >>>>si-list-request@xxxxxxxxxxxxx with > 'help' in the=20 > > 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=20 > > >>>>>>>>List archives are viewable at:=20 > > >>>>//www.freelists.org/archives/si-list > >>>>or at our=20 > > remote archives:=20 > > >>>>http://groups.yahoo.com/group/si-list/messages > >>>>Old=20 > > (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=20 > > membership from a web pag e, go to:=20 > >//www.freelists.org/webpage/si-list >>For > help: > >si-list-request@xxxxxxxxxxxxx with 'help' in the > Subject field >>List=20 > >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: > === message truncated === __________________________________ Do you Yahoo!? Yahoo! Domains 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: //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: //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: //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: //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