ResetInfo->reason is 6 (REASON_EXT_SYS_RST) even on power up

[Ognian]

Basic Infos

Hardware

Hardware: ESP-12E Core Version: master @ 85078f47 SDK version 2.0.0 (656edbf)

Description

Load the following sketch into a nodemcu v.1.0; After 5 seconds you will see the output

myResetInfo->reason 6 

this is (maybe) correct since after an upload a reset is triggered. BUT disconnect the USB cable, close the serial monitor, connect the USB cable (power on again) and quickly open the serial monitor, you will still see

myResetInfo->reason 6 

but it should be 0 (REASON_DEFAULT_RST) And no, it is not a hardware problem since with the nodemcu firmware (lua) the reason is read correct... I suspect the SDK you are using ESP8266 NONOS SDK V2.0.0 patch 20160809but there is a later one used by nodemcu firmware ESP8266 NONOS SDK V2.0.0 20160810

Do you have a better idea? Please help Thanks Ognian

Settings in IDE

Module: nodemcu v.1.0 Flash Size: 4MB CPU Frequency: 80Mhz Flash Mode: dio? Flash Frequency: 40Mhz Upload Using: SERIAL Reset Method: nodemcu

Sketch

extern "C" {
#include <user_interface.h> // https://github.com/esp8266/Arduino actually tools/sdk/include
}

void checkForResetButtonPressed() {
    rst_info *myResetInfo;
    delay(5000); // slow down so we really can see the reason!!
    myResetInfo = ESP.getResetInfoPtr();
    Serial.printf("myResetInfo->reason %x \n", myResetInfo->reason); // reason is uint32
    Serial.flush();
}

void setup() {
    // put your setup code here, to run once:
    Serial.begin(115200);
    Serial.println("------");

    checkForResetButtonPressed();
}

void loop() {
}

[devyte]

@Ognian could you please try with the latest git and report back here?

[igrr]

Fwiw, I can confirm this, both in master and SDK 2.1.0 update branch. Not sure what is going on here (i.e. i tried debugging it for an hour, but didn't find what exactly is causing this issue in Arduino core).

[tomdeboer]

I was looking into this just today and noticed the same thing. Do you already have some idea @igrr @Ognian? Something I can look into maybe?

[igrr]

As mentioned above, i have tried debugging but couldn't figure out where the issue comes from. If you can spend some debugging this, that would certainly be appreciated.

[Ognian]

I spent also some time with this; as mentioned above if you use Lua then it works correctly. Since meanwhile SDK's advanced, it is also not very probable that the problem is in the SDK. Since the Lua code is just a SDK call and here too, the only difference could be that some kind of "initialisation" is missing ...

[Macci0]

I have this also with String(ESP.getResetReason()) , ARDUINO_ESP8266_GIT_VER 0x09826c6d, ARDUINO_ESP8266_RELEASE_2_3_0

[5chufti]

Hi, maybe it is just a problem of NodeMCU after all?

I used this sketch on an ESP-01 with git master from 2017.10.31

struct rst_info {
  uint32 reason;
  uint32 exccause;
  uint32 epc1;
  uint32 epc2;
  uint32 epc3;
  uint32 excvaddr;
  uint32 depc;
};

void setup() {
  rst_info *xyz;

  xyz = ESP.getResetInfoPtr();
  Serial.begin(74880);
  Serial.println("Reason_fn " + String(ESP.getResetReason()));
  Serial.println("Reason_ptr " + String((*xyz).reason));
}

void loop() {
  Serial.println("in loop(), you may now reset, power off/on or wait 5s for 5s deepsleep");
  delay(5000);
  Serial.println("going into deepsleep");
  ESP.deepSleep(5000000);
  delay(10);  
}

I get "Power on" "0" for power on, "External System" "6" for reset "Deep-Sleep Wake" "5" for wake from deepsleep (others I didn't test)

[max17501b]

I am seeing the same problem, reset reason 6 from cold starts. I'm not using an IDE or Arduino or LUA or NodeMCU -- just an ESP12-S and my code. I obtain the reason code in the first statement in user_init().

I've tested with SDK's downloaded from Espressif versions 2.1.0(116b762) and 2.2.0-dev(9422289) -- both "non-os".

I have the time and motivation to investigate this, but I have no idea how to debug the SDK. If I can help let me know?

Thanks.

[devyte]

@max17501b do you mean you tested with a non-arduino build, or do you mean you replaced this repo's sdk with 2.2(dev)? Did you erase the entire flash before sketch upload? Debugging the sdk itself is unlikely, unless you want to go down an assembler rabbit hole from hell, but debugging down to bare sdk calls should be possible.

[5chufti]

Reading this

I am seeing the same problem, reset reason 6 from cold starts. I'm not using an IDE or Arduino or LUA or NodeMCU -- just an ESP12-S and my code. I obtain the reason code in the first statement in user_init().

I'd say he just used bare sdk and C.

[max17501b]

What I mean is I am programming the ESP12S with the Espressif SDK and my code, dumb editor, GCC and esptool for serial upload. No framework. I mention it here because there was speculation in this thread about the problem being caused by something outside the SDK.

I have erased the entire flash memory, but don't do that routinely. I usually upload OTA using http. I'll erase everything and try a serial upload.

BTW software resets are reported correctly by system_get_rst_info. Don't know about watchdogs and exceptions -- never seen one of those ;).

UPDATE: clearing flash has no effect.

[msraynsford]

I think the usb->serial device resets the controller when it connects to the device. So you think you're power cycling but once the power has come back on again, the PC connection then resets the device and actually gives you a code 6.

You could write some code that turns on the LED if you have reason 6, then reset the device without the PC connection (obviously you'd need some kind of LCD to get the exact number or even a webpage giving you the reason).

I'm just starting out on the same functionality, I'll let you know how I get on.

It is possible to disable the auto reset function too. https://playground.arduino.cc/Main/DisablingAutoResetOnSerialConnection

[titibon]

Hello, After spending some times on this, I think I found a trick. I am using a NodeMCU v1.0 (ESP12E) together with the Arduino IDE.

I was experiencing the same issue as many : always the same restart reason (that is "External System") and especially I was never able to catch a "Power on" reason although I setup several ways to get rid of the USB connectivity (External display or publish to a MQTT thread). msraynsford is right by saying we don't see the real first start of the ESP when we plug the USB in. I finally catch a "power on" reason when I connected GPIO16 (D0) with Reset.

So it seems ESP.getResetReason() works as expected only if both pins are connected.

If people facing the issue can confirm, it would be great.

Cheers

[lrmoreno007]

I don't know if I am misunderstanding the problem, but I think that in the Arduino platform (in general) it is normal that a DTR occurs every time the serial is initialized in the sketch and every time the serial viewer is opened . DTR is connected to RST on most boards.

[max17501b]

titbon, I cannot tie GPIO16 to RESET on my ESP-12S/sdk -- something out of my control is pulling GPIO16 low shortly after startup which triggers a reset loop.

GPIO16 has no effect for me, grounding, pulling it high, or letting it float -- system_get_rst_info() returns 6

The serial connection to all my boards is TX RX and GND. No DTR. No connection to RST. I don't think USP is relevant in my case.

But it got me thinking maybe RESET is bouncing during powerup. Espressif recommends debouncing the reset pin, and the ESP-12S contains a 12K pullup and 1uF debounce cap on the RESET pin. But I'm wondering if 12K is too high for some power supplies.

I just tried jumping RESET to VCC and on my test system system_get_rst_info reports 0 on cold starts. This obviously isn't a fix, but it is encouraging.

The 12S module made me lazy. They include just about all the bypasses and pullups on the module. I've gotten where I don't think about them anymore.

I'll try a resistor in parallel with the module's 12K pullup and report back....

[lrmoreno007]

In my old Nodemcu v.1 I had to replace the RST 10k pullup with a 5k5 pullup, because it had random reboots. Since then it works perfectly, this never happen to others.

I detect this with the blink.ino example in GPIO16 and a oscilloscope in RST. I got small current peaks.

[max17501b]

Well, no joy to report here. I tried resistors down to 300 ohms between RESET and VCC and still got the wrong startup value on cold starts. I hooked up a scope to RESET hoping to see if something was pulling RESET low, but didn't see anything. If there's a glitch faster than my 100MHz scope trigger I can't imagine the ESP could detect it either, at least not 100% of the time.

It appears to me, in my case at least, hardware has something to do with the problem. I have some older modules around, I'll have a play with those.

[5chufti]

But it got me thinking maybe RESET is bouncing during powerup. Espressif recommends debouncing the reset pin, and the ESP-12S contains a 12K pullup and 1uF debounce cap on the RESET pin. But I'm wondering if 12K is too high for some power supplies.

with 12k pullup and 1µF to gnd RESET will be heavily delayed compared to Vdd valid, so no wonder it won't detect "power on" but "ext system".

just try removing the 1µF cap and make sure that PD pin is connected Vdd also.

P.S.: that is why I test every "issue" with good old faithfull blue ESP-01 (no "s" or else)

[msraynsford]

I'm using the wemos D1 mini with the ESP12E on board, it uses a transistor arrangement connected to the DTR line of the USB->Serial chip to put the device into programming mode as shown here

From this discussion, I used a 10μF capacitor between the RESET and GND lines to keep the reset line high.

This didn't appear to work during my testing, whenever I connected the device to the serial monitor I kept getting an 'ext system' reset. I figured it had to be the dtr that was causing a reset. I disconnected the board from the PC and wrote a little sketch to turn on the LED if it detected a 'power on' reset. With the additional capacitor and no PC connection I finally saw the mythical 'power on' reset.

I wrote an additional sketch that threw up a simple web page giving me more text information about the reset and that confirmed my 'success'. The problem being that with the additional capacitor on the reset line I'm no longer able to reprogram the device.

[lrmoreno007]

I upload the first sketch in a NodeMCU v.1 and this sketch in a Arduino Uno:

void setup() {
  Serial.begin(115200);
}

void loop() { // run over and over
  if (Serial.available()) {
    Serial.write(Serial.read());
  }
}

I connect the ArduinoUno--->RX to NodeMCU--->TX and I reveive this when push reset button: myResetInfo->reason 6 OK

and this when power on with and external power: myResetInfo->reason 0 OK (but must be the same as when USB is connected? Lucky?)

If with external battery I plug the USB to the PC, I get nothing ---> No reset event OK

If unplug the external battery and plug the USB to PC, I get this: myResetInfo->reason 6 NOK

On the other hand: if I connect EN to GND a second I get this: myResetInfo->reason 0 OK

if I connect RST to GND a second I get this: myResetInfo->reason 6 OK

Conclusion: In my opinion it is a problem of hardware concept in the ESP8266, when the ESP8266 is plugged into the USB and there is no other external power, RST really goes from low to high and this is checked after the chip has enough current in EN, it seems to arrive sufficiently current before EN to RST. If the concept of reset in the ESP8266 were produced by a low to high peak, this problem would not happen.

I do not know if electronically it can slow down the arrival of current to EN to give RST time to be high or in the software make reset only when RST is falling or check it with a little delay.

[5chufti]

when the ESP8266 is plugged into the USB: NO you can't plug an esp8266 into USB, it has no USB interface

problem of hardware concept in the ESP8266: NO it's the hardwareconcept of nodeMCU that has a problem

use plain ESP-01 with recommended pull-ups/downs and connect serial only, you will see correct ResetInfos

[lrmoreno007]

Ok, ESP8266 has no USB interface, but in this issue we are speaking about boards with USB (like mine or the wemos of @msraynsford ) and other without it, but with the same hardware type, like the board of @max17501b . And in this issue we are speaking about ESP12E and ESP12S.

yes!! estrictly I don't must say ESP8266, but your ESP-01 isn't ESP8266 too... it's ESP8266EX sure.

And yes, everyone read 3 days ago that you don't have problems with your ESP-01. Congratulations.

We need collaborators not checkers.

[5chufti]

this issue tracker is about problems with the arduino esp8266 core. The sdk and the core are to handle the chip as it is inteded to be used. If some board manufacturers hinder the chip to function as it is intended to do, how should the sdk / core correct this faulty design?

And no, even on my ESP-12 I get correct results when used with correct pullups/downs and only serial conected. AGAIN: it is a design fault on the nodemcu/wemos boards.

[lrmoreno007]

My grandfather taught me not to argue with stupid people, because there is a danger of looking like them.

Good luck.

[5chufti]

ha, at least it is keeping you from soliloquy. your arguments are so ... convincing. get a life.

[devyte]

Alright people, let's keep things civil. @5chufti is correct in that this is not a support forum, especially not for odd hardware-related issues or faulty boards. I've seen odd things done on the boards that mount ESP-12 and friends, including odd reset circuits, so it could be that: a faulty board. Having said that, the original issue is reported for a nodemcu v1.0, which is a valid board, and I'm not yet convinced that this issue is due to hardware, which is why I haven't closed it yet. First, the issue needs to be reproduced by a maintainer, and I intend to so some tests of my own at some point. If it can't be reproduced, then the assumption will be of a bad board, or odd design. In the latter case, the board owners should investigate what the oddity is, and figure out if anything can be contributed to this repo to allow compatibility.

[5chufti]

the problem is that the reset circuitry on said boards delays the reset after a power on in a way that esp8266 doesn't recognize it as power on but as ext reset. And of course that can be reproduced with the same kind of board. Same because even nodemcu's Vx.y differ in the usb/ser chips they host and these tribute to the problem in that they behave different at power up and mess with the rst signal.

[lrmoreno007]

I have managed to solve the problem with a capacitor greater than 1uF between EN (CH_PD) and GND. This gives Reset enough time to get high when power on with USB.

On the other hand, I have found that reset needs to be activated for more than 100micro seconds (0.1ms). I don't know if this value can be increased by software or who would evaluate this. http://bbs.espressif.com/viewtopic.php?p=5027#p5027

@devyte , @igrr confirm the problem 4 month ago.

Regards.

[max17501b]

I think brother lrmoreno007 nailed it. In the hardware section of this FAQ is a discussion of the power up sequence and boot mode for the 8266. There is a timing diagram which shows CHIP_EN should be delayed at least 100uS after RESET goes high. The FAQ isn't about the reset reason per se, but I think this is the essence of the problem. (If Espressif mentions this anywhere else in their docs, I missed it.)

My testing shows it doesn't matter how long RESET is delayed on power up. It only matters that CHIP_EN follows RESET. Absolute values don't matter. Could be 1 mS or 1 minute.

Do that and the reset reason is reported correctly 100% of the time. In my case it's simple: make the RC time constant for CHIP_EN bigger than the RC time constant of RESET -- what lrmoreno007 said. (This way I can keep a bypass cap on RESET thank you very much.)

Just to add relevance, I ran Ognian's sketch on an ESP-12F module (no cap on RESET.) With a 2.2uF cap between CHIP_EN and GND the sketch reports reason 0 on cold start and reason 6 when toggling the RESET pin. Without the cap, reason 6 in both cases. It ain't an Arduino issue.

Given the nodemcu v1.0 has that snazzy DTR/RTS latch controlling RESET I won't hazard a guess what state RESET assumes when you power up from USB. A cap on CHIP_EN will help only if RESET is allowed to rise soon as power is applied.

I won't bother you anymore. I'll go back to my rock & chisel "IDE" now. Thanks for the insights.

[bertrandlo]

Dear All, why this issue still be opened ? in the latest stable release, almost bare EPS-12 get correct response boot code. so this should be a board-issue..., right?

[igrr]

Closing, the explanation by @lrmoreno007 and @max17501b appears to be correct.

[SrikanthBala]

Using a Wemos, I get the correct response (confirmed by booting in station mode and displaying a webpage only if power cycled and not on reset). I have used a Schottky diode between GPIO16 and RST with negative side towards GPIO16 as suggested in some other thread

[cziter15]

Just a note from me as I've experienced same issue

Keep in mind that the ESP12-F can differ between them, probably depending on production date. Probably other esp versions too.

https://docs.ai-thinker.com/_media/esp8266/docs/esp-12f_product_specification_en.pdf https://www.elecrow.com/download/ESP-12F.pdf

First datasheet - RC delay circuit present. Second datasheet - RC delay circuit not present.

Respecting guidelines and connecting separate pull up resistors to EN and RST pins, on versions with RC delay circuit at reset pin, will cause reset pin to go high AFTER chip EN pin which means reset reason is going to be 6 (External system).

On the boards without RC delay circuit, you will likely receive proper reset reason (Power on) as the pins go high same time.

If EN pin is pulled up on module, then adding 10uf capacitor at en pin should solve the issue.

[josephernest]

Many posts in this thread ;), can someone make a definitive summary? For NodeMCU

TL;DR: is it possible to get rst_reason == REASON_DEFAULT_RST = 0 when unplugging USB power and then powering it on again with USB?

[cziter15]

Many posts, because each board is a different design. My case is a great example (described above).

When you use esp12-s, you should end up w ith slightly different schematic than for esp12f. This is not properly described in datasheets, but when you use same design on both, you will end with EXT_,RST on esp12s, even if booting normally.

REASON_DEFAULT_RST is a Power On reset, which means that the device started properly. This is expected.

[josephernest]

TL;DR: is there a way for all boards (at least NodeMCU) to have REASON_DEFAULT_RST = 0 when powering the device from USB again (by plugging the cable), after a no-power period?