Automatic reboot after wdt reset

[SensorsIot]

My boards crash from time to time and I do not know why. After such crash the wd reset shows up (boot mode:(1,6)), but the board does not restart automatically. How can I make the boards reset/restart automatically after a wdt reset?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Links2004]

mode:(1,6) means bootloader mode, you need to add resistors like here:
https://github.com/esp8266/Arduino/blob/master/doc/boards.md#minimal-hardware-setup-for-bootloading-and-usage

[SensorsIot]

Thank you for this info. I added all these resistors.
After knowing that the ESP sits in the "bootloader" I have to rephrase my question: How can I change its behavior that the board restarts the normal "setup()" routine after the watchdog was initiated? I wrote a recovery routine to my sketch which can handle this situation. When I reset it manually, it works. But this will not be possible if I deployed it ;-)

[Links2004]

if you have added all the resistors, and you call ESP.restart(); the bord will reboot to the "setup".
keep in mind if you connect other sensors / hardware the GPIO0 need to be HIGH and GPIO15 need to be LOW when you call ESP.restart();

[SensorsIot]

Thank you for your fast reply. I was not clear enough: When my board crashes, it shows the message wdt reset mode:(1,6) and does nothing anymore until I reset it manually. With your explanation, this behavior is clear: The bootloader waits for something to happen. In this situation, my sketch has no control over the board anymore and I cannot issue the command ESP.restart(). Only manual intervention (ground the reset pin) helps to restart the sketch. But I would like to avoid this manual reset and do it automatically after the watchdog showed its message.

[Links2004]

ok now i get it,
if the wdt reset is triggert the board reboots,
when it reboots it is checking the state of GPIO0 and GPIO15 and GPIO2

GPIO15	GPIO0	GPIO2	Mode
0V	0V	3.3V	Uart Bootloader
0V	3.3V	3.3V	Boot sketch
3.3V	x	x	SDIO mode (not used for Arduino)

you need to make sure that the pins in the right state when a wtd happens or you call ESP.restart()

better you add some delays to prevent the wtd from triggering.

[igrr]

This requires some investigation. I have noticed that sometimes my nodemcu
enters bootloader after wdt reset. All the pull up resistors are in place,
so not sure what is happening. I'll take a look at this, but not sure when
:)

On Sat, Nov 14, 2015, 14:37 Markus [email protected] wrote:

ok now i get it,
if the wdt reset is triggert the board reboots,
when it reboots it is checking the state of GPIO0 and GPIO15 and GPIO2
GPIO15 GPIO0 GPIO2 Mode 0V 0V 3.3V Uart Bootloader 0V 3.3V 3.3V Boot
sketch 3.3V x x SDIO mode (not used for Arduino)

you need to make sure that the pins in the right state when a wtd happens
or you call ESP.restart()

better you add some delays to prevent the wtd from triggering.

—
Reply to this email directly or view it on GitHub
#1017 (comment).

[SensorsIot]

You were absolutely right! The problem is my GPIO0 pin. I pull it up with an Attiny85. I use this method to generate the necessary timing (together with REST).
I did a very small sketch to generate a WD reset:
void setup() {
Serial.begin(115200);
Serial.println("Begin");
}
void loop() {
while (1 == 1);
}

Always after I do the uploading, GPIO0 starts to oscillate from 3.1 to around 2 volts (with 26 MHz!). And in this state, the ESP goes into bootloader mode and stays there:

Soft WDT reset
ctx: cont
sp: 3ffe96c0 end: 3ffe9890 offset: 01b0

stack>>>
3ffe9870: 00000000 00000000 3ffe98b4 4020186a
3ffe9880: 00000000 00000000 3ffe8870 40100114
<<<stack<<<

ets Jan 8 2013,rst cause:2, boot mode:(1,7)

ets Jan 8 2013,rst cause:4, boot mode:(1,7)

wdt reset

If I do a (manual) hard reset with everything exactly the same as before, this happens repetedly:

Begin

Soft WDT reset

ctx: cont
sp: 3ffe96d0 end: 3ffe9890 offset: 01b0

stack>>>
3ffe9880: 00000000 00000000 3ffe8870 40100114
<<<stack<<<

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld

and GPIO0 does not oscillate at all.

So, I have to invetigate into my uploading logic.
Thank you for your help!

[asetyde]

With mynodemcu 1.0 esp12e after flash system is blocked and I must cut off power . After this every time I do reset system work perfect

Sent from my iPhone

On 14 nov 2015, at 15:38, SensorsIOT [email protected] wrote:

You were absolutely right! The problem is my GPIO0 pin. I pull it up with an Attiny85. I use this method to generate the necessary timing (together with REST).
I did a very small sketch to generate a WD reset:
void setup() {
Serial.begin(115200);
Serial.println("Begin");
}
void loop() {
while (1 == 1);
}

Always after I do the uploading, GPIO0 starts to oscillate from 3.1 to around 2 volts (with 26 MHz!). And in this state, the ESP goes into bootloader mode and stays there:

Soft WDT reset
ctx: cont
sp: 3ffe96c0 end: 3ffe9890 offset: 01b0

stack>>>
3ffe9870: 00000000 00000000 3ffe98b4 4020186a

3ffe9880: 00000000 00000000 3ffe8870 40100114

<<<stack<<<

ets Jan 8 2013,rst cause:2, boot mode:(1,7)

ets Jan 8 2013,rst cause:4, boot mode:(1,7)

wdt reset

If I do a (manual) hard reset with everything exactly the same as before, this happens repetedly:

Begin

Soft WDT reset

ctx: cont
sp: 3ffe96d0 end: 3ffe9890 offset: 01b0

stack>>>
3ffe9880: 00000000 00000000 3ffe8870 40100114

<<<stack<<<

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld

and GPIO0 does not oscillate at all.

So, I have to invetigate into my uploading logic.
Thank you for your help!

—
Reply to this email directly or view it on GitHub.

[SensorsIot]

An additional info: I added a small capacitor to GPIO0 (47nf to GND) and the level of the pin stays now above 3V. The same behavior appears. So, it might have another source. The board is an ESP-7.
After the post of asetyde I checked the same coding with my nodemcu ESP12E board. It behaves correctly and resets repedetly.
Mybe asetyde can check my sketch on his board. Then we would know more.

[asetyde]

At now i can not test , but why use a while(1) in function loop ? It's same

Sent from my iPhone

On 14 nov 2015, at 15:38, SensorsIOT [email protected] wrote:

You were absolutely right! The problem is my GPIO0 pin. I pull it up with an Attiny85. I use this method to generate the necessary timing (together with REST).
I did a very small sketch to generate a WD reset:
void setup() {
Serial.begin(115200);
Serial.println("Begin");
}
void loop() {
while (1 == 1);
}

Always after I do the uploading, GPIO0 starts to oscillate from 3.1 to around 2 volts (with 26 MHz!). And in this state, the ESP goes into bootloader mode and stays there:

Soft WDT reset
ctx: cont
sp: 3ffe96c0 end: 3ffe9890 offset: 01b0

stack>>>
3ffe9870: 00000000 00000000 3ffe98b4 4020186a

3ffe9880: 00000000 00000000 3ffe8870 40100114

<<<stack<<<

ets Jan 8 2013,rst cause:2, boot mode:(1,7)

ets Jan 8 2013,rst cause:4, boot mode:(1,7)

wdt reset

If I do a (manual) hard reset with everything exactly the same as before, this happens repetedly:

Begin

Soft WDT reset

ctx: cont
sp: 3ffe96d0 end: 3ffe9890 offset: 01b0

stack>>>
3ffe9880: 00000000 00000000 3ffe8870 40100114

<<<stack<<<

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld

and GPIO0 does not oscillate at all.

So, I have to invetigate into my uploading logic.
Thank you for your help!

—
Reply to this email directly or view it on GitHub.

[SensorsIot]

You can use while (1) . You are right. It is the same.

[asetyde]

ok but loop in a loop ?

On 14 nov 2015, at 16:28, SensorsIOT [email protected] wrote:

You can use while (1) . You are right. It is the same.

—
Reply to this email directly or view it on GitHub #1017 (comment).

[SensorsIot]

without the while loop the ESP does not crash, at least not in my case. And I wanted to see if the module restarts into the setup() after a crash or if it stays in the bootloader loop (see descriptions above).

[drmpf]

I added a small capacitor to GPIO0 (47nf to GND) and the level of the pin stays now above 3V
Since you are trying to keep GPIO0 high, try a 47nf or higher to 3.3v instead. Actually from GPIO0 to chip 3V3 pin.
This will make the pull up look like a short circuit at high freq.
May react differently from cap to GND due to board traces and internal chip tracks.

[igrr]

Linking #793, which is pretty much the same issue.

[kapyaar]

I have the same issue (ESP.reset() causes wdt reset and hangs). Here are my test findings. I am using nodemcu board. GPIO0,GPIO0 are pulled up, and GPIO15 is pulled down. Test code

void setup() {
  Serial.begin(115200);
  Serial.println("");
  delay(1000);
  //wdt_disable(); No difference with this line active or not.

}

void loop() {
  Serial.print("Start");
  delay(3000);
  //ESP.reset();
  ESP.restart();//Same results as ESP.reset()
}

First time run:

 Start
 ets Jan  8 2013,rst cause:2, boot mode:(1,6)


 ets Jan  8 2013,rst cause:4, boot mode:(1,6)

wdt reset

And is stuck here.

If I repower the device, then Every run then on shows

 Start
 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1264, room 16 
tail 0
chksum 0x42
csum 0x42
~ld

And resets, reboots successfully. So, something is happening after the first repowering? Because, after that it runs smooth. as expected.

[Links2004]

 ets Jan  8 2013,rst cause:2, boot mode:(1,6) <-- reboot by reset pin  - Mode Uart
 ets Jan  8 2013,rst cause:4, boot mode:(1,6) <-- reboot by watchdog   - Mode Uart

 ets Jan  8 2013,rst cause:2, boot mode:(3,7) <--  reboot by reset pin - Mode Flash (boot the sketch)

more info about the boot messages see here:
https://github.com/esp8266/Arduino/blob/master/doc/boards.md#boot-messages-and-modes

the boot mode looks wrong in the first case, check the GPIO0 its is at 0V to get mode 1, you need mode 3 to boot to the sketch.

[kapyaar]

@Links2004 given GPIO0 is pulled up to 3.3V on my board and the fact that I need to press a button (from GPIO0 to GND) under normal circumstances to program it, any clue why this is happening? I tried with different power supplies, but this behaviour persists.

[kapyaar]

@Links2004 I did some additional digging with a scope to see what is happening.
I have attached pictures. please take a look.
@SensorsIot I confirm same findings as you did. Even the simple while loop. Also, same findings as @asetyde after power cycle. resets without any issues then on.

ESP WDT RESET and GPIO0 states on first run.pdf

A sample Serial debug output below.

Soft WDT reset

ctx: cont 
sp: 3ffee0a0 end: 3ffee2a0 offset: 01b0

>>>stack>>>
3ffee250:  3ffea958 00000000 0000b7d6 4020e2f8  
3ffee260:  00000000 00000000 00000016 3ffee2cc  
3ffee270:  3fffdc20 00000000 3ffee2c4 40210af4  
3ffee280:  3fffdc20 00000000 3ffee2c4 40201d06  
3ffee290:  00000000 00000000 3ffed280 40100398  
<<<stack<<<

 ets Jan  8 2013,rst cause:2, boot mode:(1,6)


 ets Jan  8 2013,rst cause:4, boot mode:(1,6)

wdt reset

[drmpf]

I use 3K3 pullups, does lower values reduce the sine wave?

[kapyaar]

@drmpf I did not change the resistor, but I tried multiple caps from GPIO0 to GND (ie, across the switch as a simple debouncer), and that did bring the oscillation value down considerably. I tried 1uf, and 10pf.

[drmpf]

Also a 0.1uF from VCC to GND, close to the ESP supply pins (actually mine is not that close)

[kapyaar]

Yes, thats there (10uF||0.1uF). Also, I just tried a 3.3k pullup on GPIO0, no difference. Are you having this WDT reset issues too? Also, Is there any way to set a call back when this silly WDT reset happens? apparently it is printing wdt reset, so wondering if we can do a call back from there.

[drmpf]

I am not have a problem, I think. Occasionally I don't get a clean power up, but not often.
Another possibility is a local ham radio transmitter getting into the leads. What is the frequency of the oscillation?

[kapyaar]

As per scope, 26.0003MHz

[kapyaar]

I am using the staging version. I think I should try the stable version and see if this goes away.

[lukasab]

I was having the same problem using the ESP12E, the solution i found was not to use the <WiFi.h> libary but instead the <ESP8266WiFi.h> libary, hope it helps.

[d-a-v]

My bad - got confused between threads. This issue ONLY applies after reflash over SERIAL. After reflash over OTA, soft reboot works fine. A bit surprised that this is still an issue though.
Yes - did consider external reset just now - doesn't help the devices already installed :) - 10uF cap to reset driven from I/O line seems to do the trick.

Closing. Soft reset is not supported after serial flashing.

[tablatronix]

If esptool is doing hard reset should this not be a problem ?

according to esptool reset hard is an option and ( default ) --after

https://github.com/espressif/esptool/wiki/Advanced-Options

I think this is -cr in .exe

Which is in the builder already, so it is not working ?

$(SILENT)$(ESPTOOL) $(UPLOAD_VERBOSE_FLAG) -cp $(UPLOAD_PORT) -cd $(UPLOAD_BOARD) -cr

That should do a hard reset and allow soft resets no ?

I see it missing in platformio builder, not sure about arduino.

[devyte]

@tablatronix thanks, that seems to work, at least with the boards at hand.
To be specific, with #5433 the board is no longer being soft-reset after flashing. Instead, it's now hard-reset. Hence, after flashing over serial, if a soft reset/restart is done, a double WDT is no longer observed.
It is still the responsibility of the user to check that his board actually does hard-reset after flashing. If for whatever reason that does not happen, it must be physically reset with the button or by power cycling.

[tablatronix]

wow thanks for testing it, i have not had to time to look into it to see if I was right,
seems like it will help alot when testing ota etc., and hopefully doesn't break anything...

( I was looking into that as a way to add a reset button to my ide , which I thought would be useful also )

[devyte]

The -cr addition was working when I tested it above, including no more double WDT when doing a soft restart after reflashing, but for some reason it isn't working now. After flashing is done I now see an error message in the console. I've reverted #5433 with #5460 until we figure out what's going on.

[jjnoui]

Hi!
I think I have a solution to avoid the problem of the first reboot after downloading the program.
Just have a free pin to connect to the RST pin.
The rest is a small software.

Sorry for my mistakes, my mother tongue is not English.

firstboot.txt

[tablatronix]

@devyte care to share what the error was? If I have time I will try to pull that commit back in and test, but I probably wont have time for awhile

[jjnoui]

Is this message for devyte or jjnoui? Envoyé depuis un mobile Samsung. <div>-------- Message d'origine --------</div><div>De : Shawn A <[email protected]> </div><div>Date :17/01/2019 18:13 (GMT+01:00) </div><div>À : esp8266/Arduino <[email protected]> </div><div>Cc : jjnoui <[email protected]>, Comment <[email protected]> </div><div>Objet : Re: [esp8266/Arduino] Automatic reboot after wdt reset (#1017) </div><div> </div>@devyte care to share what the error was? If I have time I will try to pull that commit back in and test, but I probably wont have time for awhile — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[devyte]

@jjnoui it was for me. Thank you for your idea, but your workaround can't be adopted here given that it requires an additional pin. Instead, we need to find a solution to the underlying problem.

[jjnoui]

@devyte Ok! It was a workaround only for those have a free pin.

[devyte]

@tablatronix I'd have to retest and try to get the error message again. I don't know why it worked at first, and then 5 days later it didn't.
The change is trivial, it's just another option on the esptool command line. Testing is also trivial, just flash e.g.: Blink, and observe on the serial monitor whether the ESP gets hard-reset after flashing or not.
My testing was with ESP12f-based boards (wemos d1 r2, nodemcu, wittycloud)

[gcurtis79]

4 years, no fix?

[tablatronix]

I have to take a look at this soon, I am doing alot of development over ota, So i should have some time to at least test

[gcurtis79]

My only trouble so far is in using an MCP23017 I/O expander on I2C and the bus will not restart after a flash. OTA and direct flash have same effect.

I've tried a few of the slave reset tricks, but none of them worked. It always fails to find devices until I GND the reset pin on the ESP, or power-cycle it.

Does anyone know if the ESP32 has the same problem? I might just have to ditch my 8266's if that's the case.

[devyte]

Currently esptool.py is resetting via RTS, so I think this is done. Closing.

[gcurtis79]

Only during a connected flash on more robust hardware. OTA doesn't receive this, nor do the ESP-01(s) modules.