We really need a way to differenciate RESET and Wake Up from Deep Sleep

[gilmic]

Hi all,
I used GPIO16 to reactivate the chip from DeepSleep. Works well!
But I do not have a method to differentiate a DeepSleep awakening compared to a regular reset from a switch. (Both are connected together)
Is there (somewhere in the chip or in the code) a way to know if the chip is back from rebooting? Can be a registry value, or a timer value, or .....
I use Uint32 time_in_us to program the duration of the DeepSleep.
Is the value has decreased over DeepSleep countdown? If so, can you read this value back when the chip reset?
if the value is equal to zero, then we can say that the chip is back with a DeepSleep.
if the value is zero, then we can say that the chip is coming back from RESET (I know that it's not 100% accurancy but it can give us a good feedback)

This problem is recurring in the forum. HELP
Regards
Gilles

[pratik]

Hello Gilles,

Did you try the function system_get_rst_info() yet? It returns a structure with all the relevant parameters and also the reset causes.
If you have not tried this yet, I would suggest you to look this function up in the documentation of the SDK you are using. You will also find the information on the corresponding structure that it returns.

Note that this function and all structures are defined in SDK/include/espressif/esp_system.h and they are very self explanatory.
Please update the thread if this worked for you, it will help others if this is a common issue...

[rudi]

Hello Gilles,

Did you try the function system_get_rst_info() yet? It returns a structure with all the relevant parameters and also the reset causes.
If you have not tried this yet, I would suggest you to look this function up in the documentation of the SDK you are using. You will also find the information on the corresponding structure that it returns.

Note that this function and all structures are defined in SDK/include/espressif/esp_system.h and they are very self explanatory.
Please update the thread if this worked for you, it will help others if this is a common issue...

hi Pratik,
see you joined last days, welcome!
just in time, see your email adress, too.
are you working for espressif or at espressif?
can we use it to send special question or better here in forum?
best wishes
rudi

[pratik]

Hello Rudi,

Yes I have been around for a couple of months now. I am mainly working on application notes and support firmware and will be visiting the forum sometimes. Feel free to leave a mail if you wish to!
But if the answers to the questions will help the community, it is nice to discuss here in forums.

[gilmic]

No, your answer did not answer to my question.
Yes, we use system_get_rst_info()
The problem is still open because this function did not return all the reason of a reset.
Gilles

[YimingLi]

Hi,

You could replace the nRESET with the PD pin for wakeup, and then the nRESET pin will stand alone for free usage.
When wakeup from deep sleep, the GPIO16 will pullow and then release the PD/CH_EN (pulled up by an extern resistance) to perform a reset, just like a powe on reboot other than a reset via reset pin. Hope in this way , you could free the nRESET pin and differentiate the two type of reset.

We have a module of esp8266 doing such. You may find them at http://www.ebay.com/itm/282162857143 or http://www.ebay.com/itm/282162896341, which uses above way to wakeup from deep sleep and verified.

For more detail you could follow this discussion further or drop me a message.

Hope it will be helpful

Yiming

[garyeb]

@gilmic Did you ever get an answer to this question? It's marked as 'solved' but it's not clear to me what the solution is. Your suggestion to check the value of the DeepSleep countdown makes sense if it can be accessed. This is one of the problem with DeepSleep since user events (like pushing a momentary switch) are masked. Thanks for any help you can provide.

Regards,
Gary

[pratik]

Do you mean to say that the reset cause structure is NOT indicating that the reset cause was deep-sleep wakeup even if it actually was?

[garyeb]

Pratik,

The reset cause always returns '5' (deep-sleep wakeup) even if the reset button is pressed on my WeMos D1 Mini. In the latter case, I want it to return '6' (hardware reset) so I know it was a user event and can take the required action. If I comment out the 'deepSleep' line in my code below and never go to sleep, pressing the reset button returns a '6' as expected. The problem appears to be that once 'deepSleep' is entered, a '5' is always returned. This seems to be a common problem for folks trying to develop battery-powered ESP8266 devices using deep-sleep to conserve power. When I enter my program either from deep-sleep wakeup or a hardware reset, I need to determine if it was an external event. I tried checking the value of the RTC and system time counters but they are the same whether hardware reset or deep-sleep wakeup.

All this makes sense if the ESP8266 deep-sleep wakeup code is simply toggling the reset pin which is the same thing as pressing the reset button does. However, it leaves the problem of detecting user events from system events unsolved. Any ideas here would be a great help.

Gary

Code: Select all

#include <Arduino.h>
extern "C"
{
  #include "user_interface.h"
}
void setup()
{
  rst_info *rsti;
  rsti = ESP.getResetInfoPtr();
  Serial.begin(115200);
  Serial.println();
  Serial.println("Starting...");
  Serial.println(String("ResetInfo.reason = ") + rsti->reason);
  Serial.println("Sleeping...");
  ESP.deepSleep(5000000, WAKE_RF_DISABLED);
}
void loop() {}


[garyeb]

Pratik,

I did more research this morning and found an excellent example of a project (http://www.esp8266.com/viewtopic.php?f=13&t=8315) that confirmed my thought that there is no easy way to differentiate between a deep sleep wakeup and an external reset event. In his code, the author acknowledges this and checks for an external event by reading another GPIO pin being driven by additional circuitry from a water sensor. Since my button is just a momentary switch, asserting a signal long enough for the ESP8266 to wake up and start my app (75ms?) requires additional circuitry. It would be much nicer if the SDK had a value that I haven't found that would help but it appears a hardware solution is in order. I need to brush up on my basic electronics skills to build this circuit since I'm a software guy.

Gary