Hi all, Our app tests the watchdog by not servicing the watchdog but also setting a magic flag in RAM to see if the reset was caused by the test or for real. I made a small test app to test watchdog behaviour and when I enter a while(1); I do get a reset but the WDTCON register (containing 0x04) says the reset cause was a software reset, not a watchdog reset (??). It doesn't seem to be a class A or B trap and the TFR status is -not- set. Does anybody have any clue where to find the cause? The (deliberate) reset occurs at the rigt point but doesn't seem to be the right one... I've been staring at this for days now. Could this be caused by a modified linker file or startup file? The whole (rather complex) app works fine when I disable the watchdog so that seems to be the only "wrong-do'er"... Regards, Joost Leeuwesteijn
Minor addition: The comment mentioned that the watchdog-reset-status bit is cleared by the EINIT instruction but according to the manual it is not affected... I guess they meant SRVWDT, which was the whole cause of my problem :-/ Furthermore, why do all reset possibilities -also- set the software-reset-status bit in WDTCON (using a C167)??? That's confusing. Especially when one of the bits get cleared... Why not set just 1 bit in the register? Maybe the XC16x does this differently... Regards, Joost Leeuwesteijn