system_get_rst_info - reset by pin EXT_RST

[taribo]

It is not clear what the system_get_rst_info() function returns on this type of reset:
- reset by pin EXT_RST (there is no info in the SDK guide about the returned reason on this type of reset)

From my tests, in both these cases: "hardware watch dog reset" and "reset by pin EXT_RST", the reason is 1.
So how can I distinguish these 2 causes of reset: hardware watch dog reset or reset by pin EXT_RST ?

I need to know what caused the reset, because there is a difference between these 2 causes of reset, on internal RTC:
- in case of reset by pin EXT_RST - RTC timer returns to zero
- in case of watch dog reset - RTC timer won't change

[YimingLi]

It is not clear what the system_get_rst_info() function returns on this type of reset:
- reset by pin EXT_RST (there is no info in the SDK guide about the returned reason on this type of reset)

From my tests, in both these cases: "hardware watch dog reset" and "reset by pin EXT_RST", the reason is 1.
So how can I distinguish these 2 causes of reset: hardware watch dog reset or reset by pin EXT_RST ?

I need to know what caused the reset, because there is a difference between these 2 causes of reset, on internal RTC:
- in case of reset by pin EXT_RST - RTC timer returns to zero
- in case of watch dog reset - RTC timer won't change

Hi,

1: reset by power on, including by chip_en pin
2: reset by EXT_RST reset pin
4: reset by software watch dog internally

It seems a bitmap definition as below:
- bit 0 for power on reset
- bit 1 for reset pin reset, and
- bit 2 for software watch dog.

Depends on how you control a reset, you may get different values of reset casue. e.g. if your external hardware wdt output to chip_en, or your deep_sleep wakeup output to chip_en pin, you will always get reset cause = 1.

Hope it will be helpful.

[taribo]

Hi YimingLi,

I don't fully understand your answer.

In SDK doc it says:
enum rst_reason {
REANSON_DEFAULT_RST = 0, // normal startup by power on
REANSON_WDT_RST = 1, // hardware watch dog reset
REANSON_EXCEPTION_RST = 2, // exception reset, GPIO status won’t change
REANSON_SOFT_WDT_RST = 3, // software watch dog reset, GPIO status won’t change
REANSON_SOFT_RESTART = 4, // software restart ,system_restart , GPIO status won’t change
REANSON_DEEP_SLEEP_AWAKE = 5, // wake up from deep-sleep
};

These are the types of reset causes I encountered so far:
a. REANSON_DEFAULT_RST = 0 - this happens on a normal power up. Also happens on a restart by pin CHIP_EN
b. REANSON_WDT_RST = 1 - this happens when the FW is stuck and the watch dog resets the ESP module. Also happens when I reset the module by pin EXT_RST
c. REANSON_EXCEPTION_RST = 2 - this happens when a FW exception has occurred
d. REANSON_SOFT_RESTART = 4 - this happens when I restart the module from API (ex. with AT+RST)

I have not done any test with wake up from deep-sleep yet and I have not encountered the REANSON_SOFT_WDT_RST = 3 (software watch dog reset, GPIO status won’t change) type of reset yet.

My question was:
is this the correct type of reset cause (REANSON_WDT_RST = 1) when I reset the module by pin EXT_RST ?
Because I get the same reset cause (REANSON_WDT_RST = 1) when the FW is stuck and the watch dog resets the ESP module.

[ESP_Faye]

Hi,

We optimized system_get_rst_info in esp_iot_sdk_v1.3.0.

Please have a try, and feel free to let us know if your problem is still unsolved.

Thanks for your interest in ESP8266 !