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
Hi...again... Please read the manual :-) As usual :-) I copied the reset status (WDTCON) before the EINIT instruction, just like the manual and the comment says. But...I added code that serviced the watchdog before WDTCON was saved and the manual does mention that the SRVWDT instruction also clears the watchdog-reset-status bit in WDTCON... So it -was- a watchdog reset afterall but the SRVWDT instruction clears the bit, leaving a software watchdog reset status in WDTCON and that totally confused me. I hope this silly post will save someone else a day or 2 :-) 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