>=20
>=20
> > I recently migrated a design from a breadboard to a PCB.  I=20
> forgot to=20
> > remove my "printf" statements (CCS compiler) that I had used during=20
> > debugging.  After many hours of head-scratching, I figured out that=20
> > the printf statements were making the pic go off into la-la land. =20
> > That in itself doesn't make sense, but to make matters=20
> worse, when the=20
> > PIC was in this state, it would not reset.  It took many hours of=20
> > debugging to connect these two events.  I eventually=20
> figured out that=20
> > a big (.33 uF) cap was keeping everything running for a=20
> while.  When I=20
> > discharged it, I could then reset the PIC properly.
>=20
> The power doesn't have to go down to reset a PIC.  This can=20
> be done by bringing MCLR low then high again.
>=20
>=20

Right, that I do know.  However, in my situation bringing MCLR low, then
high wasn't doing anything.  That's what I meant by "reset."  My
hypothesis is that something in the code was preventing it from
accepting the reset, because when I let the big cap drain, it would
accept a reset again.  That's just a guess, though, because I don't know
if it is possible for any code permutation to get a PIC into a state
where it won't accept a reset (MCLR low-high).

I will admit that my reset is done by remporarily bridging the pin
between MCLR and GND (I have a resistor between VCC and MCLR).  This has
worked 100% for me in the past.

Alex

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.