Arduino: 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
https://github.com/esp8266/Arduino/issues/1017#issuecomment-156689684.

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

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

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

<<

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

<<

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

<<

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

<<

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 https://github.com/esp8266/Arduino/issues/1017#issuecomment-156712245.

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

[SensorsIot]

I made exactly the same observations as avarachanvc. Also the frequency I discovered was 26 MHz. The behavior sometimes even survived a few power downs. Neither small resistors nor capacitors helped.
I think, the ESP gets into a mode where the GPIO0 is used as and OUTPUT and does not "listen" anymore. This could explain this behavior.
I do not yet understand the circumstances how to get the modules "reliably" in this mode. I think, we should investigatein this direction. If we know hot to put the module in this mode, the guys understanding firmware would be better able to investigate...

[Links2004]

I think this is coming from the boot loader that is hard coded in the silicon.
may the output the Crystal frequency (26 MHz) during boot loader.

the first boot to the sketch is triggert by a command to the boot loader.
https://github.com/igrr/esptool-ck/blob/master/espcomm/espcomm.c#L453

may we need to change the esptool to do a normal reset.

[igrr]

@Links2004 as per @SensorsIot 's comment,

The behavior sometimes even survived a few power downs.

So i don't think this is related to the state in which esptool leaves the chip.

[igrr]

Looking at ESP8266_Pin_List_141105.xls, i see the following comment regarding GPIO0 pin:

after reset, the default is function5 to export the clock

[kapyaar]

I have not seen a case where this behaviour continues after power reset. It is back to normal boot everytime.

[asetyde]

With nodemcu 1.0 and new staging 2.0.x no problem .

Stable Yes but only after flash . No big problem

Sent from my iPhone

On 21 nov 2015, at 14:21, avarachanvc [email protected] wrote:

I have not seen a case where this behaviour continues after power reset. It is back to normal boot everytime.

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

[kapyaar]

Any further thoughts on this? The issue is prevelant between flashing the code and the first power recycle. So, is the reboot after programming different from booting from power?

Test code

void setup() {
  pinMode(2, OUTPUT);     // Initialize the BUILTIN_LED pin as an output
}

void loop() {
  while(!digitalRead(0)){    
              //pulling gpio0 to gnd for few seconds resets the device due to wdt reset.
  }
  digitalWrite(2, LOW);   // Turn the LED on (Note that LOW is the voltage level                                   
  delay(1000);                      // Wait for a second
  digitalWrite(2, HIGH);  // Turn the LED off by making the voltage HIGH
  delay(2000);                      // Wait for two seconds (to demonstrate the active low LED)
}

[Links2004]

yes the "reboot" after flashing is a command send to the bootloader and not a real reboot by reset pin.
https://github.com/igrr/esptool-ck/blob/master/espcomm/espcomm.c#L453

[kapyaar]

Ok. Thinking more about it, it is NOT the reboot after flashing that is in question here, because reboot after flash works just fine. Device boots up, and runs good. It is the

reboot or reset or crash (whatever) AFTER

"reboot after flash" and BEFORE

power recycle

that goes to the stuck mode

[igrr]

There is no reboot after flashing. Flashing leaves the device in a specific
state, which causes an issue during subsequent reset.

On Sun, Nov 22, 2015, 20:55 avarachanvc [email protected] wrote:

Ok. Thinking more about it, it is _NOT_ the reboot after flashing that is
in question here, because reboot after flash works just fine. Device boots
up, and runs good. It is the

reboot or reset or crash (whatever) _AFTER_

"reboot after flash" and _BEFORE_

power recycle

that goes to the stuck mode

—
Reply to this email directly or view it on GitHub
https://github.com/esp8266/Arduino/issues/1017#issuecomment-158781350.

[asetyde]

it seems be ok in 2.0.0 staging but , i think 2.0.0 has many big problem .

On 22/nov/2015, at 16:06, avarachanvc [email protected] wrote:

Any further thoughts on this? The issue is prevelant between flashing the code and the first power recycle. So, is the reboot after programming different from booting from power?

Test code

void setup() {
pinMode(2, OUTPUT); // Initialize the BUILTIN_LED pin as an output
}

void loop() {
while(!digitalRead(0)){
//pulling gpio0 to gnd for few seconds resets the device due to wdt reset.
}
digitalWrite(2, LOW); // Turn the LED on (Note that LOW is the voltage level
delay(1000); // Wait for a second
digitalWrite(2, HIGH); // Turn the LED off by making the voltage HIGH
delay(2000); // Wait for two seconds (to demonstrate the active low LED)
}
If I flash it, and repower, pulling

—
Reply to this email directly or view it on GitHub https://github.com/esp8266/Arduino/issues/1017#issuecomment-158765487.

[ktallevi]

Continuing discussion from #1107.

If I physically power cycle the ESP after flashing a sketch (both OTA and non-OTA), the ESP will restart OK via code ESP.restart();

If using the OTA bootloader, the sketch has to be power cycled before attempting an update... otherwise the following occurs after the update:

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

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

wdt reset

Using Olimex MOD-WIFI-ESP8266-DEV board.

[me-no-dev]

I can also confirm this with NodeMCU and standalone modules.
When you first flash using the serial port, the sketch is uploaded and the bootloader is told to start it.
So when the bootloader is told that after upload and subsequent reset is called, the bootloader just resets itself and not the sketch.
Manual reset does not trigger the bootloader and that is why it's working as expected from then on.
One possible solution I see is esptool to attempt to reset the board after upload and not just ump to the sketch. Second is to live with it and use OTA ;) And third is to find where the reset jump location is and change that to the sketch instead of the bootloader.

[me-no-dev]

https://github.com/igrr/esptool-ck/blob/master/main.c#L71 changing to 1 does not help...

[ktallevi]

I'm ok to live with it for the time being. I'll keep an eye on this thread for any fix.

[asetyde]

i think it is something not set correct , when last week come 2.0.0 rc staging my board reboot correctly but with stable , that work so good not reboot .. something changed

[zenmanenergy]

can someone smarter than me try this...

in eboot.c line 129:

ets_putc('c'); ets_putc('p'); ets_putc(':');
ets_wdt_disable();

change to:

ets_wdt_disable();
ets_putc('c'); ets_putc('p'); ets_putc(':');

I don't know how to debug this file, so I just started guessing. Moving the disable above the putc() methods made it work for me.

[zenmanenergy]

I was getting the error after doing an httpUpdate. Links' mods to the Updater fixed my problems with the updater but I started get WDT errors upon reboot.

[Links2004]

this problem here has noting to do with eboot.
here eboot is never started.

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

the device reboot to the serial bootloader, for some unknown reason.

[asetyde]

someone it test with 2.1.0 rc ? now work on nodemcu v1 ?

[ry60003333]

I seem to be running into the same issue; If I call ESP.restart() after flashing the board over serial or an OTA update, the ESP chip hangs and goes into bootloader mode. Before rebooting I am setting GPIO 0 to HIGH and GPIO15 to LOW.

I am using the Adafruit HUZZAH ESP8266 board.

Any progress on this or an idea of when it will be fixed?

[Links2004]

no progress right now, it is not easy to fix since we have no idea where the info is stored.
the best work around is to reset the ESP over the reset pin once after flashing.

[ry60003333]

Thanks @Links2004; I'll do that for now and keep watch on this issue for a fix.

[hvintik]

Try to put CH_PD pin directly to 3.3v without pull up resistor

[redge76]

Hi,
For those who see this thread because of the whatchdog reset " ets Jan 8 2013,rst cause:4, boot mode:(1,6)" message while doing an OTA, the solution is to use the staging version of esp8266-arduino.
If you use platformio, check this https://github.com/platformio/platformio/issues/401#issuecomment-166958952

[Landixus]

Same with Arduino IDE 1.6.6 and updated libraries:
after reset/ powercycle:

`Exception (0):
epc1=0x4021479d epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: sys
sp: 3ffffd80 end: 3fffffb0 offset: 01a0

stack>>>
3fffff20: 40209126 00000000 00000022 00000000
3fffff30: 4020828d 00000000 4020b519 3ffec6a0
3fffff40: 3fff0a34 40211c77 3ffea7ac 3ffea7b8
3fffff50: 3ffea7b8 0000008c 00000000 00000022
3fffff60: 00000002 0000001a 402070f3 3ffec6a0
3fffff70: 3ffea7ac 3fffdcc0 3ffe8d40 3ffe8d40
3fffff80: 00000080 3ffec6a0 3fffdab0 00000000
3fffff90: 40206a1b 3fffdab0 00000000 402035ef
3fffffa0: 3ffe8d40 40000f49 3fffdab0 40000f49
<<

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

wdt reset
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
Connecting to AP..
`
I use a nodemcu 1.0 with esp8266 12E

with simple sketch:

`#include

include "EIoTCloudRestApi.h"

// EasyIoT Cloud definitions - change EIOT_CLOUD_INSTANCE_PARAM_ID

define EIOT_CLOUD_INSTANCE_PARAM_ID "xxxxxxxxxxxxxxxxxxxxxx"

define INPUT_PIN 4

EIoTCloudRestApi eiotcloud;
bool oldInputState;

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

pinMode(INPUT_PIN, INPUT_PULLUP);

oldInputState = !digitalRead(INPUT_PIN);
// delay(5000);
}

void loop() {
int inputState = digitalRead(INPUT_PIN);;

if (inputState != oldInputState)
{
eiotcloud.sendParameter(EIOT_CLOUD_INSTANCE_PARAM_ID, (inputState == 1));
oldInputState = inputState;
delay(1000);
}
}`

My Hardware setup is to feed the PIR with 3,3Volt from nodeMCU, (PIR have 3,3 volt input).
PIR output is 3,3Volt to GPIO 4 (so i not feed the GPIO 0,2,15).

Powersupply serve 5.1V to USB Port of the NodeMCU and have 2.5A

I test this on 3 NodeMCU also with 3 PIR.
Did not have a solution yet.

[igrr]

@Landixus What you described is not the same as the issue discussed here. The issue discussed here is about ESP.restart() not performing what it should if the chip has not been reset after serial upload.

[Landixus]

@igrr ahh sorry. i experiment much days with the nodeMCU, and i was happy to this first place that looks like "it s my error".
Sorry, i investigate further.

[igrr]

It turns out that the bootloader doesn't sample GPIO pins to determine boot mode at startup. Instead, it reads high 16 bits of GPIO_IN register (0x6000318). In ESP8266_GPIO_Register_141105.xls, these 16 bits are referred to as follows:

GPIO_STRAPPING  [31:16]     The values of the strapping pins.

So it seems that the values of GPIO_IN are copied into GPIO_STRAPPING on physical reset. When we upload the sketch, this register gets loaded with the value indicating GPIO0 low. When any software reset happens (ESP.restart(), watchdog reset, etc), bootloader checks this strapping pin register and goes into UART mode, again. This register appears to be read-only, unfortunately. I didn't find a way to re-load this strapping pin values register.

It seems to me that the only workaround for this issue is to make esptool perform physical reset after uploading the sketch (via DTR/RTS pins).

[davidgraeff]

Awesome finding. Physical reset isn't a solution for over the air updates of course. Have you contacted Espressif regarding GPIO_STRAPPING bits? They provide a cloud based over the air update solution so should face the same problem while soft reseting.

[igrr]

This issue affects the device only immediately after the serial upload. I doubt this is an issue for any real-world application — you will certainly power the device down and up at least once after programming it. After you perform physical reset (e.g. power-on reset), the strapping register will be in correct state, and soft reset will work fine.

Edit: just to clarify: this isn't an issue which happens after an OTA, it is an issue which happens upon first software reset after serial upload.

[dheerajdake]

@igrr Hello. I am able to perform OTA for the ESP8266 using the HttpUpdate. But the ESP-12E module stays in the bootloader mode and doesn't exit out of that mode. If i reset the device manually, it works fine. I am using the ESP8266 as a standalone. How can i do a software reset? Code after the OTA update doesn't execute. So, ESP.restart() doesn't work.

[igrr]

The two comments above actually provide an answer to your question. The only time software reset doesn't work is immediately following a serial upload. If you reset the module physically after serial upload and place it into normal (non-bootloader) mode, software reset will work.

[dheerajdake]

@igrr But i am performing an OTA, i don't have access to the module. I can't press the reset button. How is the module able to reset itself when i do serial upload using the USB cable? I want that functionality in OTA. Is there a way to do it?

[igrr]

Are you following these steps?

• upload initial code into module over serial
• power off the module
• power it back on
• perform OTA

If as result the module hangs in bootloader, you are having some different
issue, unrelated to this ticket. Please open a new one.

This ticket was about the following scenario:

• upload initial code over serial
• without performing physical reset, start OTA
• OTA is finished, module goes into software reset and gets stuck in UART
  bootloader.

On Fri, Jun 3, 2016, 09:00 Dheeraj Dake [email protected] wrote:

@igrr https://github.com/igrr But i am performing an OTA, i don't have
access to the module. I can't press the reset button. How is the module
able to reset itself when i do serial upload using the USB cable? I want
that functionality in OTA. Is there a way to do it?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/1017#issuecomment-223465017,
or mute the thread
https://github.com/notifications/unsubscribe/AEJcerv812CAA-RH1qMuhJI3Baek7Xp9ks5qH3y6gaJpZM4GiUIi
.

[dheerajdake]

Solved. Thanks. I forgot to power off the module.

[EmbeddedFreaks]

Reboot after udp data interchange

Fatal exception 28(LoadProhibitedCause):
epc1=0x40208042, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000004, depc=0x00000000

Exception (28):
epc1=0x40208042 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000004 depc=0x00000000

ctx: cont
sp: 3fff1760 end: 3fff1980 offset: 01a0

stack>>>
3fff1900: 3fff0894 00002000 3fff0894 4020897d
3fff1910: 00000080 3fff0894 3fff0894 40208a78
3fff1920: 00000003 3fff0894 3fff0894 00002000
3fff1930: 3fff0660 3fff0894 3fff04e8 40206ad0
3fff1940: 3ffe9170 0401a8c0 3ffe9170 0301a8c0
3fff1950: 00000000 00000000 00000001 3fff0950
3fff1960: 3fffdad0 00000000 3fff0948 402091c4
3fff1970: feefeffe feefeffe 3fff0960 40100958
<<

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

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

wdt reset

[marvinroger]

Is this solved in 2.3.0-rc2? I don't experience this bug anymore (ESP.restart() works fine even right after a serial upload).

[tablatronix]

same issue here

heres something interesting
upload serial
then do an ota
and it will have issue, possibly lock up , I even saw some 1,7

 ets Jan  8 2013,rst cause:2, boot mode:(1,6)
 ets Jan  8 2013,rst cause:4, boot mode:(1,6)
wdt reset
STUCK doing nothing

do serial upload
reset board
do ota

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

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
vffffffff
@cp:0
ld
SETUP RUNS

[mkeyno]

any success on this issue ?
I faced same result from BasicOTA.ino sketch successful OTA update , I did hard reset(power off/on the module) after each serial and OTA uploading but the following message continue to come out after successful OTA update, and I have to program my module with serial again
hardware setting
ESP-07 set 1M(144KB SPIFF)
FlashChipRealSize: 1.00MB
SketchSize:274.16KB
FreeSketchSpace:584.00KB
FreeHeap:42.66KB
ChipId: 14306800
CpuFreqMHz: 80
SdkVersion: 1.5.4(baaeaebb)
FlashChipSpeed: 40000000

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

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v00000000
~ld

[LyubomyrD]

Hi
So, is there a way to do the following?

if (WTD_reset_happened) //what shall I write here??
     ESP.reset();// or ESP.restart();

[JosephGregg]

Are there workarounds for this issue? It seems to me that OTA is broken if we have to physically reset the power to the device after remote flash. In some instances, these devices aren't easily accessible...

[JZ-SmartThings]

Same problem here, copying from my related post. Basically dying from the same problem on both, generic CP2102 and CH340G chipsets. Both, NodeMCU/brown modules and WeMos D1 Mini clones. After reading the above posts, I'm considering pull-up/pull-down options but very confused as I assumed that integrated modules like the NodeMCU/D1-mini would already do this for me. The other assumption is that the ESP8266 library truly has a bug. My device reboots with the above error every 8 or so hours on its own.

ERROR:

ets Jan 8 2013,rst cause:4, boot mode:(3,6)
wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v60000318
~ld
þ

AND THIS ONE:

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

Notes from related post:
My project (SmartThings generic HTTP driver/Device-Handler controlling 2 relays & more) is much larger than the few concise samples posted above but this error is killing me and made me put in reboot logic, occurring every 8 hours; pathetic solution... posting that reboot sample below for others to reference but it's a crappy workaround and we'd love to get this figured out, please elaborate on the proposed fix.

//SELF-STANDING FUNCTION AT THE TOP OF THE SKETCH OUTSIDE OF SETUP/LOOP
void(* resetFunction) (void) = 0;

//AT TOP OF THE LOOP --- RESET EVERY 8 HOURS
if (millis () >= 28800000) {
resetFunction();
}

[tablatronix]

I get this problem also after programming, If I remove power it fixes it, i wonder if this is a hardware problem or a software problem where one of the lines is kept in an abnormal state after programming. Has anyone checked to see if their dts is stuck or anything ? Oddly enough this only happens with wdt resets, not normal resets.

[ashaheem]

I had the same issue. I was using a While loop. The issue seems to have fixed itself when I inserted a delay() into the loop.
while (currentMillis <= (long)waitTimeMillis){
currentMillis = millis();
delay(10); // This call seemed to have fixed the problem.
This is pure fluke so I can't explain what is happening.
Any insight will be appreciated.

[vlast3k]

Have a look in the watchdogs described here

https://github.com/esp8266/Arduino/blob/master/doc/faq/a02-my-esp-crashes.md

On Thu, Dec 29, 2016 at 08:57 ashaheem [e-mail] wrote:

I had the same issue. I was using a While loop. The issue seems to have
fixed itself when I inserted a delay() into the loop.

while (currentMillis <= (long)waitTimeMillis){

currentMillis = millis();

delay(10); // This call seemed to have fixed the problem.

This is pure fluke so I can't explain what is happening.

Any insight will be appreciated.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/1017#issuecomment-269589764,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAeDp1u1V82Lh6aOpfD2OVvXg15gHvE1ks5rM1m8gaJpZM4GiUIi
.

[JZ-SmartThings]

Thank you for that @vlast3k!!! (Spasibo ogromnoye :)) Most complete that I've seen on reboots/wdt but unfortunate as it says "no stack dump means you gotta rely on Serial.print for debugging" --- which we all know is the pits especially when the code runs successfully for 8 hours and then keels over with the wdt restart minus the stack, which would have been so useful. Either way, I still have something to look into even it Serial.print is all I got. I will also see if my loops are lacking the delay as @ashaheem mentioned. I've seen delays in many examples and they're obviously there for a reason. Thanks for the input everyone!

[vlast3k]

yeah.. during the delay, or yield, the ESP get's access to do some wifi
related stuff and clear the wdt timers.
Have a look also at this comment, which was the origin of this FAQ entry. It looks like it shares a bit more details
https://github.com/esp8266/Arduino/issues/2261#issuecomment-241754253
maybe it is worth checking also the free heap, during those 8 hours. it may
be that there is some memory leak that results in some misbehavior

[JZ-SmartThings]

Got it, I'll output heap size every so often to the serial monitor. I'll use one of these two examples, whichever works :) thanks again for the input!
https://github.com/esp8266/Arduino/issues/81
https://github.com/esp8266/Arduino/issues/230

[sarwadenj]

problem coming after uploading program....

rst cause:4,boot mode(1,6)

GPIO's status after uploading code
CH_PD--VCC
GPIO 15--GND
GPIO 0-Connected to DC MOTOR via N-MOSFET(at uploading connecting to ground)
GPIO 2-Connected to interrupt pin for sensor.....

once MOTOR start rotating after 10sec it throws wdt reset......
previously it is not giving problem with this setup at normal load

after uploading program voltage to ESP12E is getting 3.2v sometime 2.5v and wdt reset fires.........

[tablatronix]

I assume you are using a powered usb hub or separate power ? I have not thought of this being a power issue, but I have had other weird low power issues before when usb powered. hmm

[konstheo]

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

@igrr Has this issue you mentioned in your comment been illuminated?

I have the exact same problem with my nodemcu, and I believe this is what the OP of the original ticket faced. The original ticket was merged with others and I cannot infer if the findings so far apply to the original ticket as well.

[igrr]

Yes — see this comment: https://github.com/esp8266/Arduino/issues/1017#issuecomment-200605576 and a few more comments which follow that one.

[konstheo]

@igrr Powering off the esp after sketch uploading, and then restoring power didn't work: once per 2-3 days the chip still "hung".

I had assumed that it was a wdt reset [couldn't confirm because the esp was not connected to a pc to read serial port messages]. Since you confirm that https://github.com/esp8266/Arduino/issues/1017#issuecomment-200605576 is the explanation for the OP's problem, it appears that my sketch is the cause -- lol, 99% of the cases it's the sketch.

My main suspect is the web sever I put up, which uses polling to handle http requests. I'll switch to the ESP8266WebServer and see the results.

[asetyde]

at now on arduino ide i not see this problem , in visual micro (plugin of visual studio yes , but i not consider an issue ).
i think it can be closed , this issue change too many times its meaning .. it can be ?

[tablatronix]

The issue is still the same, people just went off on tangents, I will check out the arduino ide and see if it changes. Problem could be in esptool or state of serial reset lines, I have hinted at this before.

[igrr]

The problem is that we can't force to latch bootstrapping pins again during software reset. So if the last (hardware) reset was a reset into upload mode, upon next (software) reset will also put the chip into upload mode. The only way to solve this is to perform external reset after uploading the code. The reason why esptool-ck doesn't do this is automatically is because one might still have a jumper on GPIO0 when this post-upload reset is performed.

[tablatronix]

Ahh I was assuming it WAS doing a hardware reset.

But why not do hardware resets if using autoreset?

[danriches]

Couldn't you use a spare GPIO pin pulled high and connected to the reset pin, then in your sketch set it low to reset when needed?

[safari2]

I've faced with similar problem. When my sketch (on ESP wemos d1 mini) send request via http (arest) and server don't answer few seconds (Wi-Fi is too polluted), I get wdt reset which stops the program running.
I came out of the situation as follows:
Add wdt_disable(); in setup().
Add wdt_reset(); before each http_request routines.

Now if I get wdt reset in runtime, it reboots ESP.

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

wdt reset
load 0x4010f000, len 1264, room 16 
tail 0
chksum 0x0f
csum 0x0f
~ld
............
WiFi connected
IP address: 
192.168.74.102
Voice conrtol init completed, waiting for the command
connecting to 192.168.74.1
Requesting Status: 
HTTP/1.1 200 OK
connection: keep-alive
content-type: application/json;charset=utf-8
access-control-allow-origin: *
content-length: 7

["200"]
Requesting URL: /1d2241ad9cb94e76922faa82e9543ae1/update/V1?value=100
HTTP/1.1 200 OK
connection: keep-alive
content-length: 0

[tablatronix]

Sounds like a while loop waiting for result, make sure you have a delay or yield in any loops!

[gugaiz]

I was having the same problem until I found this issue, the problem now is that the board restart (after the first reset) but it never goes into the deep_seep mode. I mean.. the watchdog is triggered and I have some code there to go into deep_sleep but when it happen thought the watchdog that code is not working, but when following the normal flow the same deep_sleep instruction works fine.

[yang550831]

change=> #include
write =>#include
..
.
.
.
.
WiFi.begin(ssid, password); //line befor "while (...)....."
while (WiFi.status() != WL_CONNECTED) {
delay(500);Serial.print(".");
}

[gugaiz]

Hi yang550831, thanks for the answer.. I tried that but didn't work. I am still having the same issue.

[RensMD]

@yang550831 @gugaiz

Before sending your HTTP requests, you don't necesarily need to wait forever for the connection is established.
Personally, I'm using a system which is sending requests at high regularity and without consequences if data is lost. Therefore, if the connection happens to fail, another attempt will be made in the next loop.
I simply changed the while loop with:
_if(WiFi.status() == WL_CONNECTED){
// Send HTTP Request
}_
Ever since, I've not seen the WDT error again.
If however your server is very busy and you require a higher change of succes, I would suggest retrying the connection multiple times within each loop.

[AlexKroll]

Hi everyone.
I had a problem with "rst cause 4" for a long time. Even on an empty sketch (only setup wifi).
I tested different combinations of pullup/down resistors, capacitors and power supply.
Once I assembled the new and flashed Esps (12E) and turned them on. After several minutes they are reseted simultaneously! May be this is the program problem.
I started looking for different combinations of initializing the wifi.
I found the following:

void setup()
{
WiFi.disconnect();
delay(200);
WiFi.mode( WIFI_AP );
WiFi.softAP( ssid, "", 2, 0 );
}

I tested sketch in 2 modes: (empty loop and udp transfer). There were no resets for several hours.
I hope this helps you.

I will investigate the WiFi.softAP( ssid, "", 2, 0 );

[hemangjoshi37a]

does anyone have code to turn wdt off??

[lrmoreno007]

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

[hemangjoshi37a]

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

[mmaxus35]

So, is there any permanent solution for wdt reset ?

[nardev]

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]

@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]

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]

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

[devyte]

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]

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

[hemangjoshi37a]

Very simple solution to this problem is to switch to esp32 from esp8266 as
it has dedicated processor for networking and separate processor for
program execution. So networking is always available even if any kind of
delay you provide in program.

On Fri, Oct 20, 2017, 9:55 AM Ivan Grokhotkov [e-mail]
wrote:

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

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/1017#issuecomment-338102731,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AL0XmU72340cn9BMZSCA7Wa4sX57Bnhmks5suCC-gaJpZM4GiUIi
.

>

Regards,
Hemang Joshi

[amgrays]

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]

@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]

@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]

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]

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]

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]

Awesome man....

On Sat, Dec 16, 2017, 2:16 AM rpsreal [e-mail] wrote:

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.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/1017#issuecomment-352107597,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AL0XmSGxagXYHhyVfnXZHHBGfnyxwZySks5tAtqKgaJpZM4GiUIi
.

>

Regards,
Hemang Joshi

[mmaxus35]

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]

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]

I was having the same problem using the ESP12E, the solution i found was not to use the libary but instead the 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.

-------- Message d'origine --------

De : Shawn A [e-mail]

Date :17/01/2019 18:13 (GMT+01:00)

À : esp8266/Arduino [e-mail]

Cc : jjnoui [e-mail], Comment [e-mail]

Objet : Re: [esp8266/Arduino] Automatic reboot after wdt reset (#1017)

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