Thanks to listmembers for all the comments on this issue in the past week.
I thought I'd let you know how the issue appears to be resolved.

First off, it appears that somewhere in my C initialization, or for some
other reason, the watchdog reset status bit in RCON was being set prior to
the point I was printing it out, so the resets did not appear to be due to
the WDT. Using the ICD-2 watch window and setting a break point at the
start of my code, then forcing a WDT timeout with while(1), I could see
that the RCON bit was properly cleared indicating a WDT timeout at the
start of my code, but magically set (hiding the wdt timeout) by the time I
printed the RCON value. The solution there was to save RCON in a variable
as my first line of code, then refer to that when I went to print.

As has been pointed out, the ICD-2 does not allow you to have the watchdog
timer enabled in the configuration bits. However, you CAN enable it in
your runtime code with:

WDTCONbits.SWDTEN=1;	//enable wdt even if disabled in config bits

This allowed the WDT to time out when I hit the while(1) and verify that
my reset reporting code was working.

Next is WHY was the wdt timing out?

I turned off the WDT and let the system run. After several hours, the
system stopped responding. So, the problem was definitely a crash (most
likely an infinite loop), and not just too short a WDT period.

Unfortunately, the ICD-2 will not do a halt on WDT timeout. So, I started
the program again with the ICD-2 and waited for the system to stop
responding. It eventually did. The program was hung waiting for a byte to
finish transmitting on I2C.

Looking at the I2C clock, I started the system where the byte was to be
transmitted across I2C. Two clock pulses were visible, then the clock line
got stuck about 100mV above ground. What's interesting (and I've seen this
before with SPI also) is that the PIC apparently counts the clocks ON THE
PIN rathern than before the pin driver. (Actually, I guess that make
sense... the same circuitry can be used in slave mode). So, if the pin
gets stuck the clock counter never advances and the BF flag never gets
set. So, that's why the system was hanging.

In this system, the PIC is the only I2C master, so no one else is supposed
to drive the clock. Looking for the easiest thing to pull off the I2C bus,
I found a plug in memory module that is custom made for this product.
Unplugging it, all 8 I2C clocks appear, the system runs, and the WDT has
not yet timed out after several hours of operation.

So, stuff I learned:

1. You CAN run the WDT with the ICD-2. You just have to enable it in your
code instead of the config bits.

2. RCON is useful! Check it early, as something may mess it up later.

3. Reminded that a stuck SPI or I2C clock will keep BF from going true.

Again, thanks for the ideas!

Harold

-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist