Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic reboot after wdt reset #1017

Closed
SensorsIot opened this issue Nov 14, 2015 · 129 comments
Closed

Automatic reboot after wdt reset #1017

SensorsIot opened this issue Nov 14, 2015 · 129 comments

Comments

@SensorsIot
Copy link

SensorsIot commented Nov 14, 2015

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Member

igrr commented Nov 14, 2015

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 notifications@github.com 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
Copy link
Author

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
Copy link

asetyde commented Nov 14, 2015

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 notifications@github.com 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
Copy link
Author

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
Copy link

asetyde commented Nov 14, 2015

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 notifications@github.com 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
Copy link
Author

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

@asetyde
Copy link

asetyde commented Nov 14, 2015

ok but loop in a loop ?

On 14 nov 2015, at 16:28, SensorsIOT notifications@github.com 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
Copy link
Author

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
Copy link

drmpf commented Nov 14, 2015

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
Copy link
Member

igrr commented Nov 15, 2015

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

@kapyaar
Copy link

kapyaar commented Nov 20, 2015

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
Copy link
Collaborator

 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
Copy link

kapyaar commented Nov 21, 2015

@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
Copy link

kapyaar commented Nov 21, 2015

@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
Copy link

drmpf commented Nov 21, 2015

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

@kapyaar
Copy link

kapyaar commented Nov 21, 2015

@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
Copy link

drmpf commented Nov 21, 2015

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

@kapyaar
Copy link

kapyaar commented Nov 21, 2015

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
Copy link

drmpf commented Nov 21, 2015

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
Copy link

kapyaar commented Nov 21, 2015

As per scope, 26.0003MHz

@kapyaar
Copy link

kapyaar commented Nov 21, 2015

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

@lukasab
Copy link

lukasab commented Feb 22, 2018

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
Copy link
Collaborator

d-a-v commented Oct 12, 2018

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.

@d-a-v d-a-v closed this as completed Oct 12, 2018
@tablatronix
Copy link
Contributor

tablatronix commented Oct 12, 2018

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
Copy link
Collaborator

devyte commented Dec 4, 2018

@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
Copy link
Contributor

tablatronix commented Dec 4, 2018

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 devyte reopened this Dec 9, 2018
@devyte
Copy link
Collaborator

devyte commented Dec 9, 2018

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.

@devyte devyte modified the milestones: 2.5.0, 2.6.0 Dec 10, 2018
@jjnoui
Copy link

jjnoui commented Jan 17, 2019

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
Copy link
Contributor

@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
Copy link

jjnoui commented Jan 17, 2019 via email

@devyte
Copy link
Collaborator

devyte commented Jan 17, 2019

@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
Copy link

jjnoui commented Jan 17, 2019

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

@devyte
Copy link
Collaborator

devyte commented Jan 17, 2019

@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
Copy link

4 years, no fix?

@tablatronix
Copy link
Contributor

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
Copy link

gcurtis79 commented Oct 12, 2019

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
Copy link
Collaborator

devyte commented Oct 15, 2019

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

@devyte devyte closed this as completed Oct 15, 2019
@gcurtis79
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests