> When the /MClr line is held low, the oscillator is inhibitted; OSCOUT is low,
> and OSCIN is weakly pulled low.  When /MClr is released, OSCOUT will swing
> high quickly; this will start the oscillator.
>
> I don't know whether the PIC hammers the oscillator on a watchdog timeout; if
> it doesn't, it would probably be a good idea for future models to do so.
>
> I don't think MCLR stops the oscillator.  Although I don't program PICs, a
>  design
> I specified recently depended on the oscillator running during a MCLR reset.

Hmm... that differs from my recollection, though the cases where it's been
a problem to me were the times when /MClr was accidentally left unconnected
(it sinks groundward if it is).  It may be that if /MClr is never raised,
that the oscillator won't start until it is (this may improve startup behav-
ior).  So we may both be right... though in different ways.

Perhaps the best behavior would be to have a fuse-settable option for
whether the oscillator should be stopped on reset since there are definite
pros and cons to such an approach (if the oscillator stops on reset, then
power consumption will be minimized; a simple battery-backup approach would
be to connect /MClr to the external VDD and use diodes to power the PIC from
battery or external VDD as appropriate).  Unfortunately, such an approach
would cause the PIC to run continously when VDD went away--even if the PIC
tried to SLEEP.

On the other hand, letting the oscillator run while /MClr is low allows it
to get started faster, and allows the chip to start running code sooner,
than waiting until /MClr rises.  It also helps in applications where the
clock is used for other purposes as well.

Interesting arguments for both sides...