- If I call machine.reset() and check the cause, I get 4, SOFT_RESET.
- If I ground CHPD and check the reset cause, I get 0, PWRON_RESET.
- If I deep sleep, wait out the sleep period, wake up, and check the reset cause, I get 5, DEEPSLEEP_RESET.
- If I ground RST and check the cause, I get 6, HARD_RESET.
- If I deep sleep but manually override by grounding CHPD, and check the cause, I get 0, PWRON_RESET.
Is this the intended behavior? All other issues aside, I would expect the chip to never believe it awoke from deep sleep if it didn't do so. Whatever other cause state it might take, I wouldn't expect it to take that state in particular.
I want to detect the difference between a timer wake-up and a manual override. That option appears to be available via the CHPD line, but I'm not sure that is the proper way to wake up the device; I kind of thought RST might be the intended method (but maybe it doesn't matter), but RST doesn't work apparently, as I've just described). Why does RST clearly support HARD_RESET, as shown above, yet is misinterpreted as DEEPSLEEP_RESET when that isn't the case?
Actually, I said CHPD would work for me, but actually, the problem is, I get PWRON_RESET with both a CHPD grounding and a plug-in power-up. But I want to be able act differently when (1) USB plug-in at computer for dev work, (2) manual button wake-up in the field, (3) deep sleep wake up in the field. I can't do this if CHPD triggers the same cause as plugging-in and RST triggers the same cause as deep sleep.