>=20
>=20
> > Right, that I do know.  However, in my situation bringing MCLR low,=20
> > then high wasn't doing anything.  That's what I meant by=20
> "reset."  My=20
> > hypothesis is that something in the code was preventing it from=20
> > accepting the reset,
>=20
> That's silly.  Let's not stoop to voodoo debugging. =20
> Otherwise just get out the dead fish and wait for a full moon.
>=20

Why is that voodoo debugging?  I do X and it fixes Y.  That may have
been a coincidence, but if it is repeatable, then it may be causal.
Olin, you may know that it is impossible for a PIC to get in a code
state where it can't be reset, but I don't know that.

> > because when I let the big cap drain, it would
> > accept a reset again.
>=20
> You still haven't said where exactly this cap is.
>=20

It is a .33 uF Cap, across the VCC and GND on a IrDA module.  It is
about 20 mm away from the PIC.

> > I will admit that my reset is done by remporarily bridging the pin=20
> > between MCLR and GND (I have a resistor between VCC and=20
> MCLR).  This=20
> > has worked 100% for me in the past.
>=20
> Are you holding MCLR low for long enough without any contact=20
> bounces? What size resistor?
>=20

I assume so.  As I said, this technique has worked 100% in the past,
through millions :) of resets.  The resistor is 5K.

> I know you said you have MCLR configured as MCLR, but have=20
> you actually verified this by reading back the configuration=20
> bits from the PIC?
>=20
>=20

Yeah, my programmer does that.  As I mentioned, MCLR does reset fine
after I drain the cap.


Alex

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