WDT_FROM_SLEEP

[collink]

I am getting the above reset cause in a project of mine. The name of this reset cause seems to be total nonsense. The chip I am using (PIC18F25J11) does not reset because of a WDT while sleeping - it wakes up. There is a separate reset cause for an actual WDT timeout. I have specifically disabled the WDT while code is executing (it is disabled immediately after waking up and set immediately before sleeping). The data sheet for this chip does not seem to shed any light on the situation as there doesn't seem to be anything other than a general watchdog reset as a reset reason. This is not a random reset, I can make it happen every time in a certain place in my code. It would seem to be an error in the code but the amount of code to make this happen is too large to post.

I suppose what I really need to know, if someone knows, is what on Earth is WDT_FROM_SLEEP? It is never explained anywhere. I have found multiple people ask this question on the internet and nobody seems to ever really explain it. What causes this reset reason and why does it not even seem to be a valid reset reason according to the chip docs?

EDIT: BTW, this is with the 4.129 compiler

[collink]

Slight follow up: I looked at the ASM list and traced down what it was doing. Upon doing so it became apparent that it really does basically list the actual value of RCON. And, so, I see that a value of 3 for RCON really does mean that it was in sleep mode (PD is set 0) and that the watchdog overflowed (TO is also 0). The question is, why wouldn't this cause a wake up like it is supposed to instead of a reset? I then suspected it was going into deep sleep or otherwise not sleeping quite like I wanted. But, I called sleep() and the ASM code for that function does seem to do the right thing. Now I'm really stumped.

I suppose in my application it really isn't the end of the world that it resets but it annoys me that a reset would happen when I didn't ask it to.

[PCM programmer]

[collink]

I believe I've fixed the program with my program. In my case it seems like maybe I had messed up some coding by accidentally doing some unsafe things in an interrupt handler and also by accidentally mixing up calls to delay_ms and delay_us. Those two functions are orders of magnitude different but only one letter off.

Anyway, I don't have resets any longer. I still find the actual situation odd - the watchdog should never reset the MCU while in sleep mode. It is supposed to wake up the MCU. But, I have to wonder if a mess up related to an interrupt handler might be able to corrupt memory badly enough to cause such a thing to happen.