> Hello Everyone,
>
>       I am using a PIC 18F2520's MSSP configured as an I2C master.  It is
> interfacing a DAC that takes a 3 byte packet to write to (Address, Data1,
> Data2).  Generally it is working.  I'm generating arbitrary waveforms with
> no problem...  when it works.  What I mean is that if I power cycle the
> unit, it comes up just fine and begins outputting waveforms to the DAC about
> 90% of the time.
>
>      Looking at it one the scope I see two different distinct error
> states.    SCL would normally generate 9 clocks for each of the 3 bytes (8
> bits data, 1 bit ack) and it is all in a packet surround by start and stop
> conditions.  When it is doing this, all is well.  However, during10% of the
> time I see one of 2 things..     either the clock idles low (should be high)
> and then during the first byte it only puts out a clock on the first bit.
> Then when it gets to the second and third bytes it does the full 9 clocks
> each but returns to a low state.  The other part of the time both lines are
> held high and seemingly nothing happens.
>
>       Whichever state I power up in the unit stays in.  Just before anyone
> asks, I have 1K resistors pulling SCL and SDA up.  I have the same circuit
> hooked up on a dev board and it doesn't have any issues like this.  Does
> anyone have any ideas what might be causing this?
>
> Thank you,
>
> Martin
>  

>
> Marty Robertson wrote:
> > Hello Everyone,
> >
> >       I am using a PIC 18F2520's MSSP configured as an I2C master.  It
> is
> > interfacing a DAC that takes a 3 byte packet to write to (Address,
> Data1,
> > Data2).  Generally it is working.  I'm generating arbitrary waveforms
> with
> > no problem...  when it works.  What I mean is that if I power cycle the
> > unit, it comes up just fine and begins outputting waveforms to the DAC
> about
> > 90% of the time.
> >
> >      Looking at it one the scope I see two different distinct error
> > states.    SCL would normally generate 9 clocks for each of the 3 bytes
> (8
> > bits data, 1 bit ack) and it is all in a packet surround by start and
> stop
> > conditions.  When it is doing this, all is well.  However, during10% of
> the
> > time I see one of 2 things..     either the clock idles low (should be
> high)
> > and then during the first byte it only puts out a clock on the first
> bit.
> > Then when it gets to the second and third bytes it does the full 9
> clocks
> > each but returns to a low state.  The other part of the time both lines
> are
> > held high and seemingly nothing happens.
> >
> >       Whichever state I power up in the unit stays in.  Just before
> anyone
> > asks, I have 1K resistors pulling SCL and SDA up.  I have the same
> circuit
> > hooked up on a dev board and it doesn't have any issues like this.  Does
> > anyone have any ideas what might be causing this?
> >
> > Thank you,
> >
> > Martin
> >
> 1K resistors? That seems low, to me. I seem to recall the I2C spec being
> 3.3K resistors...
>
> --Bob

> I'm not certain where your problem is coming from, but here
> are my I2C notes about I2C devices:
>
> 1. I2C devices are simple state machines. But powerup does NOT place
> the device in a known state. In fact, every I2C device on the bus might be
> in a state that seizes the SDA bus. The easiest way to initialize is to
> execute
> clocks until the SDA bus is released. The maximum number needed is 9
> clocks.
> If the SDA cannot be freed after 9 clocks, you either have another master
> driving the bus, or you have a defective i2c device on the bus.
>
> 2. Synchronize the bus by performing a STOP flag, followed by a START
> flag then a final STOP flag. At this point, all I2C devices on the bus are
> initialized and will execute properly from then on.
>
> 3. I never use pullups lower than 3.3K on 5V buses, 2.2K on 3V buses.
> SOME I2C devices can't pull down a heavier resistor.
>
> 4. After a master has finished with the I2C bus on a multi-master system,
> it
> must release (tristate) both pins immediately. This is naturally easy to
> do,
> because the STOP flag causes both pins to be in the '1' state anyway.
>
> 5. I have heard of i2c buses being run  over a meter distance, etc. This
> is not a good idea, because line reflections become a problem . I2C is
> a communication system designed to control TV components using few
> wires, and it works fine as long as the bus stays on the same PCB.
>
> --Bob
>
>
> On 7/15/06, Olin Lathrop <@spam@olin_piclistKILLspamembedinc.com> wrote:
> >
> > Marty Robertson wrote:
> > > I've seen others use anywhere from 1 to 10K, but I'm not sure on the
> > > spec.
> >
> > Then get sure.
> >
> > > I'll try something a little higher and see if that helps.
> >
> > Try waving a dead fish over it during a full moon.
> >
> > ******************************************************************
> > Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
> > consultant in 2004 program year.  http://www.embedinc.com/products
> > --

>
> Marty Robertson wrote:
> > I've seen others use anywhere from 1 to 10K, but I'm not sure on the
> > spec.
>
> Then get sure.
>
> > I'll try something a little higher and see if that helps.
>
> Try waving a dead fish over it during a full moon.
>
> ******************************************************************
> Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
> consultant in 2004 program year.  http://www.embedinc.com/products

>
> I only have canned tuna here, will that work?
>
> > What kind of fish?  Trout didn't work.
> >
> > On 7/15/06, Olin Lathrop <spamBeGoneolin_piclistspamBeGoneembedinc.com> wrote:
> > >
> > > Marty Robertson wrote:
> > > > I've seen others use anywhere from 1 to 10K, but I'm not sure on the
> > > > spec.
> > >
> > > Then get sure.
> > >
> > > > I'll try something a little higher and see if that helps.
> > >
> > > Try waving a dead fish over it during a full moon.
> > >
> > > ******************************************************************
> > > Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
> > > consultant in 2004 program year.  http://www.embedinc.com/products
> > > --