I fixed it just so people know. Problem was due to a routine called inside
a timer0
interupt that talked to an i2c i/o chip to update a LED display. This
interupt was occuring when talking
to the DS1721, and causing much confusion among the i2c chips and the PIC.
Fixed by disabling gie
in each i2c routine.

Tim

At 08:38 PM 6/3/2001 -0500, you wrote:
>Tim,
>
>When you say, "lack of any debugging hardware", do you also mean you don't
>have a pin or two to spare?
>
>I have very often used a single pin, or two pins, to turn LEDs on and off
>at specific points inthe program to see exactly where a routine fails.  On
>a FLASH PIC where you can reprogram quickly and with no UV erase hassle,
>you can narrow things down pretty quickly.  For exmple, turn the LED on at
>the beginning of a section or subroutine, turn it off on exit.  If it's
>off whwn things fail, do it for the next subroutine or section of code.
>Once it fails with the LED on, narrow it down to loops within the
>function, critical sequences, etc.
>
>Works every time for me.
>
>Dale
>--
>A train stops at a train station.  A bus stops at a bus station.
>On my desk I have a workstation...
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways.  See http://www.piclist.com/#archives for details.
>
>
>
>

-
Remember, 'kill' doesn't kill processes, users kill processes.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body