I have just ported some code from the PIC16C84 to the PIC16F628 and
encountered an odd problem which appears to be due to a difference in
behaviour between the watchdog timers on these two processors.

On the PIC16C84, it was possible to measure the watchdog timer period by
executing a "clrwdt" instruction, entering an "infinite" loop with an
incrementing counter, and reading back the value of the counter when the
watchdog reset occurred.  Periodic measurements enabled a good prediction
to be made of the time taken by a subsequent "sleep" instruction, which
was great for creating compound "sleep" times with much greater precision
than the tolerance of the watchdog timer (7-36ms, 18ms nominal).

However, on the PIC16F628, I found that my "sleep" routines were running
24% slower than on the PIC16C84.  On further investigation, I discovered
that each "sleep" (with the CPU shut down) was taking the nominal 18ms,
but that each *measurement* of the watchdog timer period (with the CPU
active) was only taking 14.5ms.  A similar test with a PIC16F877 gave the
same result.

At this stage, I can only conclude that, on some of the newer PICs, the
watchdog period varies depending on whether the processor is running at
the same time.  Might it be that the silicon resistor in the internal RC
network which provides this timing is thermally coupled to the CPU to a
greater extent, or that the voltage threshold for the end of its timing
period is different with the CPU active versus dormant?

I'd be interested to know whether anyone else has bumped into this, and
in particular if there are any solutions other than incorporating a 24%
"kludge" factor (which probably isn't a constant across the temperature
range) or reverting to the PIC16C84.

Thanks in advance.
--
Ian Chapman
Chapmip Technology, UK

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics