Problem is that you have to prove that for us... :-)

Why do you belive that WDT is "definitly disabled" ?

And what sign do you see that makes you think that
it actualy *is* waking up from WDT-reset ?

------------------------------------------------------

Yeah, I know, I've been trying to prove it to myself as well
I have the following code in my initialise routine now:
	msg = "Unknown";
	//What caused the reset?
	if(!POR == 0){
		if(!TO == 0)
			msg = "Illegal";
		else if(!PD == 0){
			msg = "Illegal";
		}else{
			msg = "Power On";
		}
	}else{
		if(!BOR == 0){
			msg = "Brown OUT!!";
		}else{
			if		(!TO == 0 && !PD == 1){
				msg = "WDT Reset";
			}else if(!TO == 0 && !PD == 0){
				msg = "WDT Wake up";
			}else if(!TO == 1 && !PD == 0){
				msg = "MCLR wake in slp";
			}else{
				msg = "Guess MCLR Norm";
			}
		}
	}
	lcd_printf(msg);

Now, according to page 134 of the PIC16F88 datasheet, the values above
reflect the different types of restart.

I have specifically set SWDTEN = 0, (as can be seen in
http://www.ug.it.usyd.edu.au/~jgre5893/pic/main.c : line 134)
I have tried SETTING the WDT config code (instead of clearing it) and
this just made things worst. I cleared the code and
Now the config word reads back as 0x3FCA, WDTEN is in bit 2, A = 1010
(as you all know) and so WDTEN = 0.

I don't know how I can prove it better...
My only thought is that in the status bits describing the reset flags
are all active low in the table... Perhaps I've converted
This table incorrectly into code.

Also, the MCLR reset during normal operation reset, doesn't seem to be
distinguishable from the other resets?
So perhaps it is that... But I have also tried clearing the MCLR config
bit, so there is NO MCLR pin to worry about. Still
No luck.

I've also tried using a completely separate chip (incase the chip is
faulty) and I got the same results...

I'm soo confused now 

--Josh


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist