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

Open
SensorsIot opened this Issue Nov 14, 2015 · 113 comments

Comments

Projects
None yet
@SensorsIot

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

This comment has been minimized.

Show comment
Hide comment
@Links2004

Links2004 Nov 14, 2015

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

Collaborator

Links2004 commented Nov 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@SensorsIot

SensorsIot Nov 14, 2015

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 ;-)

SensorsIot commented Nov 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Links2004

Links2004 Nov 14, 2015

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();

Collaborator

Links2004 commented Nov 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@SensorsIot

SensorsIot Nov 14, 2015

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.

SensorsIot commented Nov 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Links2004

Links2004 Nov 14, 2015

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.

Collaborator

Links2004 commented Nov 14, 2015

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 comment has been minimized.

Show comment
Hide comment
@igrr

igrr Nov 14, 2015

Member

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).

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

This comment has been minimized.

Show comment
Hide comment
@SensorsIot

SensorsIot Nov 14, 2015

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!

SensorsIot commented Nov 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@asetyde

asetyde 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.

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

This comment has been minimized.

Show comment
Hide comment
@SensorsIot

SensorsIot Nov 14, 2015

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.

SensorsIot commented Nov 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@asetyde

asetyde 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.

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

This comment has been minimized.

Show comment
Hide comment
@SensorsIot

SensorsIot Nov 14, 2015

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

SensorsIot commented Nov 14, 2015

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

@asetyde

This comment has been minimized.

Show comment
Hide comment
@asetyde

asetyde 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).

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

This comment has been minimized.

Show comment
Hide comment
@SensorsIot

SensorsIot Nov 14, 2015

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).

SensorsIot commented Nov 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@drmpf

drmpf 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.

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

This comment has been minimized.

Show comment
Hide comment
@igrr

igrr Nov 15, 2015

Member

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

Member

igrr commented Nov 15, 2015

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

@igrr igrr added this to the 2.1.0 milestone Nov 15, 2015

@kapyaar

This comment has been minimized.

Show comment
Hide comment
@kapyaar

kapyaar 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.

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

This comment has been minimized.

Show comment
Hide comment
@Links2004

Links2004 Nov 20, 2015

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.

Collaborator

Links2004 commented Nov 20, 2015

 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

This comment has been minimized.

Show comment
Hide comment
@kapyaar

kapyaar 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 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

This comment has been minimized.

Show comment
Hide comment
@kapyaar

kapyaar 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

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

This comment has been minimized.

Show comment
Hide comment
@drmpf

drmpf Nov 21, 2015

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

drmpf commented Nov 21, 2015

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

@kapyaar

This comment has been minimized.

Show comment
Hide comment
@kapyaar

kapyaar 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.

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

This comment has been minimized.

Show comment
Hide comment
@drmpf

drmpf Nov 21, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@kapyaar

kapyaar 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.

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

This comment has been minimized.

Show comment
Hide comment
@drmpf

drmpf 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?

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

This comment has been minimized.

Show comment
Hide comment
@kapyaar

kapyaar Nov 21, 2015

As per scope, 26.0003MHz

kapyaar commented Nov 21, 2015

As per scope, 26.0003MHz

@kapyaar

This comment has been minimized.

Show comment
Hide comment
@kapyaar

kapyaar Nov 21, 2015

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

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.

@lrmoreno007

This comment has been minimized.

Show comment
Hide comment
@lrmoreno007

lrmoreno007 Jun 6, 2017

Contributor

On google enter "esp8266 turn wdt off" and click on "I feel lucky"

Contributor

lrmoreno007 commented Jun 6, 2017

On google enter "esp8266 turn wdt off" and click on "I feel lucky"

@hemangjoshi37a

This comment has been minimized.

Show comment
Hide comment
@hemangjoshi37a

hemangjoshi37a Jun 7, 2017

@lrmoreno007 exaclty I did the same and it opened this page. How funny is that??

hemangjoshi37a commented Jun 7, 2017

@lrmoreno007 exaclty I did the same and it opened this page. How funny is that??

@mmaxus35

This comment has been minimized.

Show comment
Hide comment
@mmaxus35

mmaxus35 Jun 17, 2017

So, is there any permanent solution for wdt reset ?

mmaxus35 commented Jun 17, 2017

So, is there any permanent solution for wdt reset ?

@nardev

This comment has been minimized.

Show comment
Hide comment
@nardev

nardev Sep 2, 2017

This issue happens to me only and only if i have serial monitor running. Other than that, ESP reboots fine.

Perhaps NodeMCU or simple serial programmer, when hooked doesn't let it boot while connected.

nardev commented Sep 2, 2017

This issue happens to me only and only if i have serial monitor running. Other than that, ESP reboots fine.

Perhaps NodeMCU or simple serial programmer, when hooked doesn't let it boot while connected.

@mmaxus35

This comment has been minimized.

Show comment
Hide comment
@mmaxus35

mmaxus35 Sep 2, 2017

@nardev i did not face with that problem on nodemcu version 1.0 board. But if serial monitor is open that means rx tx pins are busy. You cannot flash the chip. It gives error. If you dont want to wdt reset. You must manually press start button once you programmed the chip.

mmaxus35 commented Sep 2, 2017

@nardev i did not face with that problem on nodemcu version 1.0 board. But if serial monitor is open that means rx tx pins are busy. You cannot flash the chip. It gives error. If you dont want to wdt reset. You must manually press start button once you programmed the chip.

@nardev

This comment has been minimized.

Show comment
Hide comment
@nardev

nardev Sep 2, 2017

Mmm.. i have nmcu 0.9

The reset i was talking about was the ESP.reset() which if triggered from the code, while Serial monitor is on, freezes the ESP.

nardev commented Sep 2, 2017

Mmm.. i have nmcu 0.9

The reset i was talking about was the ESP.reset() which if triggered from the code, while Serial monitor is on, freezes the ESP.

@tablatronix

This comment has been minimized.

Show comment
Hide comment
@tablatronix

tablatronix Sep 2, 2017

Contributor

Esp reset does not work after programming. Reboot then test again

Contributor

tablatronix commented Sep 2, 2017

Esp reset does not work after programming. Reboot then test again

@devyte

This comment has been minimized.

Show comment
Hide comment
@devyte

devyte Oct 19, 2017

Collaborator

This seems to be a known issue: the module must be physically reset after a serial upload in order to ensure subsequent software resets work correctly.
@igrr I don't see a viable fix in the above discussion. If you agree, I'd like to close this.

Collaborator

devyte commented Oct 19, 2017

This seems to be a known issue: the module must be physically reset after a serial upload in order to ensure subsequent software resets work correctly.
@igrr I don't see a viable fix in the above discussion. If you agree, I'd like to close this.

@igrr

This comment has been minimized.

Show comment
Hide comment
@igrr

igrr Oct 20, 2017

Member

Re-labeled as a documentation issue (we should mention this somewhere in OTA docs).

Member

igrr commented Oct 20, 2017

Re-labeled as a documentation issue (we should mention this somewhere in OTA docs).

@hemangjoshi37a

This comment has been minimized.

Show comment
Hide comment
@hemangjoshi37a

hemangjoshi37a Oct 20, 2017

hemangjoshi37a commented Oct 20, 2017

@amgrays

This comment has been minimized.

Show comment
Hide comment
@amgrays

amgrays Oct 31, 2017

This is a VERY serious issue. I have just updated the core to the latest and find this lockup now happening EVERY time. Basically remote OTA is useless because I can't do a subsequent restart on the device without locking it up. So I have to arrange to get someone in another country to go and recycle the power !!! And the best solution is to change to ESP32 - WHAT!!!

amgrays commented Oct 31, 2017

This is a VERY serious issue. I have just updated the core to the latest and find this lockup now happening EVERY time. Basically remote OTA is useless because I can't do a subsequent restart on the device without locking it up. So I have to arrange to get someone in another country to go and recycle the power !!! And the best solution is to change to ESP32 - WHAT!!!

@igrr

This comment has been minimized.

Show comment
Hide comment
@igrr

igrr Oct 31, 2017

Member

@amgrays could you please open a new issue if you have a problem with latest code please? Describing what you tried and what doesn't work. Thanks.

Member

igrr commented Oct 31, 2017

@amgrays could you please open a new issue if you have a problem with latest code please? Describing what you tried and what doesn't work. Thanks.

@devyte

This comment has been minimized.

Show comment
Hide comment
@devyte

devyte Oct 31, 2017

Collaborator

@amgrays this issue covers a wdt lockup if a software restart is done following a serial flash over usb, without first physically resetting the board. OTA is affected only because it does a software restart, so flashing over serial and then testing OTA without first doing a physical reset hits this issue. There is currently no fix for that.
You seem to be encountering a wdt lockup after OTA in a remote location, which would make it a completely different issue.

Collaborator

devyte commented Oct 31, 2017

@amgrays this issue covers a wdt lockup if a software restart is done following a serial flash over usb, without first physically resetting the board. OTA is affected only because it does a software restart, so flashing over serial and then testing OTA without first doing a physical reset hits this issue. There is currently no fix for that.
You seem to be encountering a wdt lockup after OTA in a remote location, which would make it a completely different issue.

@Fernando-Checa

This comment has been minimized.

Show comment
Hide comment
@Fernando-Checa

Fernando-Checa Oct 31, 2017

Have you considered the use of an external hardware WD?
This could reset the module if not responding after a period of time.

I'm using a similar approach in one of my projects...
https://www.superhouse.tv/15-watchdog-timers-for-arduino-home-automation/

Fernando-Checa commented Oct 31, 2017

Have you considered the use of an external hardware WD?
This could reset the module if not responding after a period of time.

I'm using a similar approach in one of my projects...
https://www.superhouse.tv/15-watchdog-timers-for-arduino-home-automation/

@amgrays

This comment has been minimized.

Show comment
Hide comment
@amgrays

amgrays Oct 31, 2017

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.

amgrays commented Oct 31, 2017

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.

@rpsreal

This comment has been minimized.

Show comment
Hide comment
@rpsreal

rpsreal Dec 15, 2017

My reset problem solved with a delay(0). I found in a code from a library for an ADC the following comment:
delay (0); // delay (0) causes a yeild for ESP8266
And I decided to try and that solve it, I have not had any problems with resets yet.

rpsreal commented Dec 15, 2017

My reset problem solved with a delay(0). I found in a code from a library for an ADC the following comment:
delay (0); // delay (0) causes a yeild for ESP8266
And I decided to try and that solve it, I have not had any problems with resets yet.

@hemangjoshi37a

This comment has been minimized.

Show comment
Hide comment
@hemangjoshi37a

hemangjoshi37a Dec 16, 2017

hemangjoshi37a commented Dec 16, 2017

@mmaxus35

This comment has been minimized.

Show comment
Hide comment
@mmaxus35

mmaxus35 Dec 16, 2017

My reset problem solved with a delay(0). I found in a code from a library for an ADC the following comment:
delay (0); // delay (0) causes a yeild for ESP8266
And I decided to try and that solve it, I have not had any problems with resets yet.

What was the critical part in your code?

mmaxus35 commented Dec 16, 2017

My reset problem solved with a delay(0). I found in a code from a library for an ADC the following comment:
delay (0); // delay (0) causes a yeild for ESP8266
And I decided to try and that solve it, I have not had any problems with resets yet.

What was the critical part in your code?

@rpsreal

This comment has been minimized.

Show comment
Hide comment
@rpsreal

rpsreal Dec 18, 2017

I had an interruption that established the I2C communication and requested information from an IC. At this interruption there was a delaymicrosecond(20), putting the delay (0) before that line solved the problem.

rpsreal commented Dec 18, 2017

I had an interruption that established the I2C communication and requested information from an IC. At this interruption there was a delaymicrosecond(20), putting the delay (0) before that line solved the problem.

@lukasab

This comment has been minimized.

Show comment
Hide comment
@lukasab

lukasab 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.

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.

@ammuller ammuller referenced this issue Mar 23, 2018

Open

Quite Stable #66

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