Should WDT be disabled during setup()?
It's quite common situation when setup() executes quite long time.
Yes, I also have this problem. I would like to disable WDT during setup() because setup waits for WiFi connection that is used to deliver settings for further operation.
ets_wdt_disable() is reported as undefined external...
Can you call yield() or delay() in your setup function periodically in the
same way it is done in the sample sketches for the ESP8266WiFi library?
Both will indirectly reset the watchdog.
On Apr 2, 2015 10:36 AM, "tomaja" [email protected] wrote:
Yes, I also have this problem. I would like to disable WDT during setup()
because setup waits for WiFi connection that is used to deliver settings
for further operation.
Reply to this email directly or view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-88795278.
Oh, yes - delay works! Sorry for that, I didn't get that from README :(
Спасибо, Иван!
@Sermus
Maybe adding methods to enable/disable WDT would be sufficient for most cases?
Not sure this is a way out because i got it in a 3rd party library which i tried to use as is. Its initialization tooks long time. In that sense if we want to have one-to-one Arduino library portability we must let them initialize as long as they need. Otherwise i'd have to modify a lib inserting watchdog feeds (if it's possible at all)
I meant something like this:
void setup() {
wdt_disable();
/// some initialization
ThirdPartyLibrary.begin();
/// more stuff
wdt_enable();
}
Would that work?
What exactly is this library doing, by the way? I have added workarounds for some of the common usage patterns like while (!wifiClient.available()){} which detect such blocking loops and call yield() internally.
it's ILI9341 lib and it fills the screen black in quite a longy way.
What is the issue with nesting setup() call in these wdt_disable()/wdt_enable(), except not working WDT itself?
delay() doesn't seem enough. I probably have more than 1s in between two delay calls.
Yes, your proposition looks good (adding wdt_enable and wdt_disable).
Can you add those two functions?
Thanks!
It would also be usefull to have a function to set the wtd reset time!
Thanks!
@igrr Do you think this feature will be added?
void setup() {
wdt_disable();
/// some initialization
ThirdPartyLibrary.begin();
/// more stuff
wdt_enable();
}
@tomaja Added WDT APIs: ESP.wdtEnable(), ESP.wdtDisable(), ESP.wdtFeed().
You can either grab the latest version from git, or download the full .zip when it is ready from https://ci.appveyor.com/project/igrr/Arduino/build/artifacts
Great! Thanks, @igrr !
I just built Mac version from source and I checked that I can use ESP.wdtDisable() - script compiles just fine.
My Prolific USB to Serial stopped working after OSX update this morning so I'm unable to flash the new image to ESP8266 until I resolve that. I'll let you know how it works.
@tomaja I have also installed the Yosemite update today and had to reinstall the FTDI driver to make serial uploads work. I suppose the driver got replaced by Apple's version during the upgrade.
Edit: ignore this, you're using Prolific not FTDI...
Sorry to trigger a notification, but I would like to understand what is the purpose of the watchdog? I can't find any informations. Thanks!
A Watchdog timer is a safeguard against infinite loops or crashed
processors.
You periodically reset the watchdog timer. If you don’t it forces a
reset of the processor.
Crashed processors are usually stuck in a giberish loop of some kind
that is unlikely to have a watchdog reset command in it.
Given that embedded processors are often stuck in the middle of
electrically noisy environments, or placed inaccessibly this is a very
important feature.
Processors can crash for reasons other than poor code. Single event
upsets triggered by background and cosmic radiation are examples. As
well as glitches from electrical noise and RFI and EMI.
The AVR ATmega has one built in but most folk don't actually enable or
use it.
On 15/05/15 08:36, Marvin Roger wrote:
Sorry to trigger a notification, but I would like to understand what
is the purpose of the watchdog? I can't find any informations. Thanks!—
Reply to this email directly or view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-102299731.
Thanks, I thought it was something specific to the ESP8266. So I suppose the watchdog resets at the end of a loop() iteration and on a yield/delay call?
I think the concept should be documented in the README, because as you said it is not enabled by default on official Arduino boards, so newcomers might be lost as I was.
Agreed
The ESP8266 is a bit of an odd ball case.
Consider that the other Arduino/Ethernet/Wifi offerings use an ATmega as
the arduino and a second embedded processor of some type or other to do
the networking bit.
In the ESP's case we are expecting one processor to do it all. there is
a lot going off in the background that we are unaware of. The
pre-written envrionments typical of arduino style coding don’t help with
seeing what is going off behind the scenes. But does get folk into it
quicker by hiding the complexity. Something of a trade off.
Not only do we need to de-schedule to kick or reset the watchdog timer,
but we also need to do the same to let the background networking stuff
do it's thing.
This knowledge is obvious to the guys at the cutting edge doing the
coding but is part of a whole bunch of context that other folk coming to
it new do not have.
Part of the challenge of turning out open source is the wide range of
skill levels that will be encountered.
Some clear statements and maybe an example snippet might be useful to
help with this. Or at least a statement of what the time period for the
WDT defaults to, so folk can deal with it by issuing a specific call to
it at intervals.
Whilst it will be possible to modify the WDT period and even to disable
it all together, my best advice is don't do it. Learn to program with
WDT and de-scheduling if you are planning on working with the ESP.
On 15/05/15 13:18, Marvin Roger wrote:
Thanks, I thought it was something specific to the ESP8266. So I
suppose the watchdog resets at the end of a loop() iteration and on a
yield/delay call?
I think the concept should be documented in the README, because as you
said it is not enabled by default on official Arduino boards, so
newcomers might be lost as I was.—
Reply to this email directly or view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-102384594.
We've got something along these lines in the third paragraph here:
https://github.com/esp8266/Arduino#timing-and-delays
@AndyKirby if you can help to expand/improve this readme section I would really appreciate this.
Yup will do.
What is the default timeout for WDT ??
On 15/05/15 13:56, Ivan Grokhotkov wrote:
We've got something along these lines in the third paragraph here:
https://github.com/esp8266/Arduino#timing-and-delays@AndyKirby https://github.com/AndyKirby if you can help to
expand/improve this readme section I would really appreciate this.—
Reply to this email directly or view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-102391250.
Around 1 second. Unfortunately there is no info at this point how to change that value.
Cool leave it with me.
On 15/05/15 14:52, Ivan Grokhotkov wrote:
Around 1 second. Unfortunately there is no info at this point how to
change that value.—
Reply to this email directly or view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-102404045.
WDT APIs (ESP.wdtEnable(), ESP.wdtDisable(), ESP.wdtFeed()) are now included in the latest release.
ESP.wdtEnable(), ESP.wdtDisable() seem to have no effect?
the SDK allow only to disable the software WDT, so the hardware WDT is still aktive.
try to add some delay.
Thanks, I was experimenting and trying to understand the behavior. What is the difference between the software WDT and hardware one? When would one be triggered or the other?
the software WDT is implemented inside the SDK from espressif, and is using a Timer.
the Hardware WDT is implemented in the silicon of the ESP chip, and is running independent form every software.
the basic mechanic is for both the same if they not reseted before they run out, the chip makes a reboot.
the different from developer view is that the SDK gives us the possibility to manipulate the software WDT but not the hardware WDT.
Software WDT api:
https://github.com/esp8266/Arduino/blob/master/cores/esp8266/Esp.h#L86-L92
Unfortunately we not have any clear documentation what the times for both are.
after around 1sec we get a WDT reset.
Thanks, that makes sense. It did not seem like the timeout changed anything :)
We can manipulate hardware WDT. setting exact timeouts is not clear, but
enabling/disabling is not difficult. I didn't include those functions in
the core because I believe disabling WDT (which many will attempt) is a
lousy idea. I can provide more info on WDT registers though.
On Sat, Nov 14, 2015, 19:32 adrionics [email protected] wrote:
Thanks, that makes sense. It did not seem like the timeout changed
anything :)—
Reply to this email directly or view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-156717754.
@igrr @tomaja @adrionics I tried ESP.wdtDisable() and adding a delay. No effect. It still resets (using ESP-01). Did anyone get a long setup() working reliably?
ESP.wdtDisable() seems no effect. It will still reset the chip if delay takes long.
But ESP.wdtEnable(ms) works fine. It seems that the default time can be rewritten by this function. The following code would not reset the chip:
ESP.wdtEnable(15000); // make the watch dog timeout longer
delay(10000); // long delay
I am using NodeMCU v3 ESP-12E module with Arduino IDE 1.6.7.
wdtEnable(), wdtEnable(time) and wdtDisable()don't seem to be working. Did anyone find a way around this?
Using NodeMCU v2 ESP-12E with Arduino IDE 1.6.7
Connor-F commented 11 days ago
wdtEnable(), wdtEnable(time) and wdtDisable()don't seem to be working. Did anyone find a way around this?Using NodeMCU v2 ESP-12E with Arduino IDE 1.6.7
Same problem here, with Wemos D1 and Wemos D1 Mini,
@igrr Hello, Ivan. can you provide any info about HW WDT registers? we implement a low-power application and need to sleep for a long period of time. It seems that HW wdt resets the CPU, so we have to wakeup and feed the WDT to workaround this.
Hey guys...im also looking for some information about HW WDT.
Same here. I am using the RFM69 library and waiting for RX sets off the WDT reset, its very difficult to debug without knowing HW WDT info.
anyone have found any solution to this problem??
wdtEnable() or wdtDisable() does not work.
I am facing this from a week or so. Please help me.
Thank you.
I facing the same problem using serial.available() in the arduino loop while running an async webserver build. Constant serial input more that 1 second is causing an WDT timeout.
@vwroad87 So have you found any solution??
No I just posted today, hopefully someone can comment on the WDT issue.
On Thu, Jun 8, 2017 at 9:07 PM, Hemang Joshi notifications@github.com
wrote:
@vwroad87 https://github.com/vwroad87 So have you found any solution??
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-307290098, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJjT4xyUfqTd4eSONocYhASyd1WEpfPZks5sCMULgaJpZM4D4_Vi
.
@vwroad87 okay man, but this bug is tough one. Because this issue was opened 2.5 years ago but its still not solved. I also hope someone someday come with solution.
Well I'm gonna try a couple more things, delay(0) for one to see if this
resets the WDT.
I'll post and try to keep the thread alive and perhaps a core dev will take
interest.
On Thu, Jun 8, 2017 at 11:24 PM, Hemang Joshi notifications@github.com
wrote:
@vwroad87 https://github.com/vwroad87 okay man, but this bug is tough
one. Because this issue was opened 2.5 years ago but its still not solved.
I also hope someone someday come with solution.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-307306187, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJjT4yH6WvlRsBEXAyAPdBM8HjkfgFy6ks5sCOUHgaJpZM4D4_Vi
.
Did you try ESP.wdtFeed() ?
With reference to: https://techtutorialsx.com/2017/01/21/esp8266-watchdog-functions/
@freeck I will try that and let you know if it works
Here is my Loop, everything works except when the attached micro controller
sends back a text file to display which could be many lines. It fails at
random lines though, sometimes the first few others after maybe 15-20
lines?
void loop() {
bool led_state ;
uint16_t fade_speed;
// are we in web server call back mode?
if (webCallbackMode){
// NOP
}else{
// we are in websocket mode
// Got one serial char ?
//if (PROP_SERIAL.available()) {
while (PROP_SERIAL.available()) {
ESP.wdtFeed(); //reset watchdog
// Read it and store it in buffer
char inChar = (char)PROP_SERIAL.read();
inputString += inChar;
// New line char ?
if (inChar == '\n') {
// Send to all client
ws.textAll(inputString);
inputString = "";
break; // get out of the loop
}
}
}
// Handle remote Wifi Updates
ArduinoOTA.handle();
//get the current miliseconds
unsigned long currentMillis = millis();
// handle the PSI reading here
//if (currentMillis - previousMillis >= interval) {
// save the last time you read the PSI
//previousMillis = currentMillis;
// read the PSI sensor
//PROP_SERIAL.println(getPSIMA());
//getPSIMA(); // update the psi sensor
//}
}
On Tue, Jun 13, 2017 at 3:32 AM, Hemang Joshi notifications@github.com
wrote:
@freeck https://github.com/freeck I will try that and let you know if
it works—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-308075353, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJjT49IYIcxD0Z8JvIm5zhsNamHVqAqKks5sDmUmgaJpZM4D4_Vi
.
Did you try using yield() instead of wdtFeed()?
@adrionics Thanks man. I will try that and let you know if it works fine.
Not yet, I will and let the list know, I've read using yeild() is more art
when working with asynchronous systems. The other part of this project has
already started an async webserver on top of the async IP stack.
Yield() didn't work but I did fix the problem by putting a 1 ms delay
between each line in the attached micro routine that was sending the lines.
I did keep yield() in the receive routine since a to "pump the queue"
during the receive routing delay from the attached micro.
On Tue, Jun 13, 2017 at 10:55 AM, adrionics notifications@github.com
wrote:
Did you try using yield() instead of wdtFeed()?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-308197429, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJjT4y6dYsgfQZei_Y5YEWiTMv5RWbWAks5sDs0ogaJpZM4D4_Vi
.
@vwroad87 , hey man can you put the code here?? The one that succeeded .
Joshi, like I said the micro (propeller chip) that is attached to the
ESP8266 was flooding the ESP RX buffer or something I guess. What I did on
the micro was to insert a 1 ms delay into each line that was being sent to
the ESP8266 serial port. The code on the micro is FORTH and I don't think
you wanna see that right? So my bug fix was to slow down the data being
sent to the esp8266 and I did keep yield in my receive loop like this:
void loop() {
bool led_state ;
uint16_t fade_speed;
// are we in web server call back mode?
if (webCallbackMode){
// NOP
}else{
// we are in websocket mode
// Got one serial char ?
if (PROP_SERIAL.available()) {
// Read it and store it in buffer
char inChar = (char)PROP_SERIAL.read();
inputString += inChar;
yield(); //let other stuff run
// New line char ?
if (inChar == '\n') { // each line ending in
\n from the propeller chip has a 1 ms delay now coded in the propeller
micro routine
// Send to all client
ws.textAll(inputString);
inputString = "";
}
}
}
// Handle remote Wifi Updates
ArduinoOTA.handle();
}
On Wed, Jun 14, 2017 at 8:42 AM, Hemang Joshi notifications@github.com
wrote:
@vwroad87 https://github.com/vwroad87 , hey man can you put the code
here?? The one that succeeded .—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-308472150, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJjT4yW0gu8-D-IuQ80JcthMl26lyhrMks5sD_9kgaJpZM4D4_Vi
.
I've never had this problem but today I had to fight with it, because the sketch I'm creating uses the Ticker.h library (It have timers inside and i get continous wdt resets).
My sketch needs a very long delays > 60 seconds (It's for SIM900 GSM).
I have solved it by creating the following function:
void delaySeconds(int seconds) {
for (int i = 0; i <= seconds*10; i++){
delay(100);
ESP.wdtFeed();
}
}
And calling her with:
delaySeconds(2); // two seconds
instead of using:
delay(2000); // two seconds
I hope this helps someone.
@lrmoreno007 yo man, you are going to live for 1000 years, you have my blessings, you saved my day....
What else are you doing on the ESP8266?
My problem was/is that I'm using the Async TCP/HTTP stack/server and
receiving RX serial data in the sketch loop was causing WDT resets. I
fixed the problem by having the attached serial sender pause 2 ms between
each line it sent. I tried yield(), ESP.wdtFeed() in the RX loop, slowing
down the baud rate.....but only after the 2 ms delay in the sender did the
system go stable again.
On Wed, Jun 21, 2017 at 12:15 PM, ZaPpInG notifications@github.com wrote:
I've never had this problem but today I had to fight with it, because the
sketch I'm creating uses the Ticker.h library (It have timers inside and i
get continous wdt resets).I have solved it by creating the following function:
void delaySeconds(int seconds) {
for (int i = 0; i <= seconds*10; i++){
delay(100);
ESP.wdtFeed();
}
}And calling her with:
delaySeconds(2); // two seconds
instead of using:
delay(2000); // two seconds
I hope this helps someone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/34#issuecomment-310177640, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJjT4wnoGnFn5Fwf5luCdAszurSVBLb7ks5sGWvRgaJpZM4D4_Vi
.
I have this problem using a dht11 sensor and wemos d1 mini to connect to adafruit io server , The code is
// DHT 11 sensor
// WiFi parameters
// Adafruit IO
// DHT sensor
DHT dht(DHTPIN, DHTTYPE, 15);
// Functions
void connect();
// Create an ESP8266 WiFiClient class to connect to the MQTT server.
WiFiClient client;
// Store the MQTT server, client ID, username, and password in flash memory.
Adafruit_MQTT_Client mqtt(&client, AIO_SERVER, AIO_SERVERPORT, AIO_USERNAME, AIO_KEY);
// Setup feeds for temperature & humidity
Adafruit_MQTT_Publish temperature = Adafruit_MQTT_Publish(&mqtt, AIO_USERNAME "/feeds/temperature");
Adafruit_MQTT_Publish humidity = Adafruit_MQTT_Publish(&mqtt, AIO_USERNAME "/feeds/humidity");
/******** Sketch Code ***********/
void setup() {
// Init sensor
dht.begin();
Serial.begin(115200);
Serial.println(F("Adafruit IO Example"));
// Connect to WiFi access point.
Serial.println(); Serial.println();
delay(10);
Serial.print(F("Connecting to "));
Serial.println(WLAN_SSID);
WiFi.begin(WLAN_SSID, WLAN_PASS);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(F("."));
}
Serial.println();
Serial.println(F("WiFi connected"));
Serial.println(F("IP address: "));
Serial.println(WiFi.localIP());
// connect to adafruit io
connect();
}
void loop() {
// // ping adafruit io a few times to make sure we remain connected
// if(! mqtt.ping(3)) {
// // reconnect to adafruit io
// if(! mqtt.connected())
// connect();
// }
// Grab the current state of the sensor
int humidity_data = (int)dht.readHumidity();
int temperature_data = (int)dht.readTemperature();
// Publish data
if (! temperature.publish(temperature_data))
Serial.println(F("Failed to publish temperature"));
else
Serial.println(F("Temperature published!"));
if (! humidity.publish(humidity_data))
Serial.println(F("Failed to publish humidity"));
else
Serial.println(F("Humidity published!"));
// Repeat every 10 seconds
delay(10000);
}
// connect to adafruit io via MQTT
void connect() {
int8_t ret;
// Stop if already connected.
if (mqtt.connected()) {
return;
}
Serial.print("Connecting to MQTT... ");
uint8_t retries = 3;
while ((ret = mqtt.connect()) != 0) { // connect will return 0 for connected
Serial.println(mqtt.connectErrorString(ret));
Serial.println("Retrying MQTT connection in 5 seconds...");
mqtt.disconnect();
delay(5000); // wait 5 seconds
retries--;
if (retries == 0) {
// basically die and wait for WDT to reset me
while (1);
}
}
Serial.println("MQTT Connected!");
}
It continuously show the following thing : -
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
v3ffe85ec
~ld
@subham9777 you can't use such huge delays on the ESP, the wdt will trigger. This is on purpose, because the wifi stack has to be serviced frequently.
If you need more info, please ask at a forum like esp8266.com or stackoverflow.
Got this issue aswell on my Wemos D1. ESP.wdtDisable(); doesn't seem to do anything.
@Baxtex, that's expected
@devyte is there a document which describes why the wifi stack needs frequent servicing? (and what exactly it does as part of the servicing?)
EDIT:
Sorry, someone was helping answer emails and answered this by mistake. Please to have spurred more in depth discussion though!
@adrionics I'm referring to @devyte 's comment on 24th Sept above.
@adrionics "you can't use such huge delays on the ESP, the wdt will trigger. This is on purpose, because the wifi stack has to be serviced frequently."
@electronicsguy that is not true - all needed methods are called inside delay() so there is no wdt triger if you use delay(). Only delayMicroseconds() is without internal calls to handle watchdog and network stack.
@Pablo2048 what exactly is not true?
@electronicsguy "you can't use such huge delays on the ESP, the wdt will trigger" - you definitely can use delay() with for example 5000 and no wdt will be trigged (and the ESP will respond to icmp requests in delay also) because wdt is feed inside delay() method and wifi stack is serviced also.
@electronicsguy and @Pablo2048 both are right, simple sketches can use large delays and there is usually no problem, but when interruptions or timers are used, it is more complicated. That is why the use of huge delays is discouraged.
The problem here is that the library DHT.h you are using uses interrupts and then the use of delay is even more dangerous.
Try this:
1º Place dht.begin (); as much as possible at the end of setup(), to delay the use of interruptions. In your sketch it is the first instruction executed.
2nd Use this function instead of delay()
void delaySeconds (int seconds) {// Function that feeds the puppy
for (int i = 0; i <= seconds * 10; i ++) {
delay (100);
ESP.wdtFeed ();
}
}
Example of use:
delaySeconds (30); // delay 30 seconds
Regards
Sorry, but I don't think that this make a difference. Before and after dht.begin() can be yield() used to feed the watchdog and your delaySeconds makes no sense - look into core_esp8266_wiring.c how delay() works - it sets os_timer and calls esp_yield()/cont_yield() function so IMHO esp_yield() (or something behind this) feeds the watchdog and handle the wifi stack.
Delay call to yield it's true, but yield don't feed the dog.
How do you know this? Actually yield() is IMHO exactly for this reason (eg. feed the watchdog and handle network stuff). You can also try to run delay(5000) in loop() - if this will not trigger WDT reset, then yield definitely fed the dog :-)
I can attest that yielding momentarily returns execution flow to the underlying scheduler, which feeds the watchdog as part of it's operation :)
My comment from back then was before I learned that there are certain conditions where large delays are ok. It is ok in that sketch (I think).
Also, for those cases where it's not ok, the issue is not that the wdt will trigger, but that the receiving buffers can overrun.
It depends a lot on what you do in your application, which is why large delays are discouraged (you have to know the conditions when it's ok, and keep the whole thing in mind if you ever extend your application).
I think the problem with that sketch was that the the pin for DHT11 was set to GPIO8, which I understand is forbidden on the Wemos D1 mini (used by the flash as SD1 on ESP12).
Many of the above posters have experienced problems trying to read serial in an asynch webserver handler. Writes are no problem. Reads absolutely trigger the watchdog no matter what the timeout is set to. Interestingly using a delay() in an asynch handler does nothing. It doesn't delay because of yield.
Do serial reads yield or does that not make sense? Thanks.
This code works to create a delay within an asynch webserver handler and reading the serial as a stream works:
void onBodySerial(AsyncWebServerRequest *request, uint8_t *data, size_t len, size_t index, size_t total) {
AsyncWebServerResponse *response = request->beginResponse(Serial, "text/plain", 50);
unsigned long startTime = millis();
while (millis() - startTime < SERIAL_TIMEOUT) {
wdt_reset(); // kick the doggie!!
Serial.println(millis() - startTime);
}
response->addHeader("Server","ESP Async Web Server");
request->send(response);
}
But what I really want to do is this:
void onBodySerial(AsyncWebServerRequest *request, uint8_t *data, size_t len, size_t index, size_t total) {
AsyncResponseStream *response = request->beginResponseStream("application/json");
DynamicJsonBuffer jsonBuffer;
unsigned long startTime = millis();
while (millis() - startTime < SERIAL_TIMEOUT) {
wdt_reset(); // kick the doggie!!
Serial.println(millis() - startTime);
if (Serial.available()) {
JsonObject &root = jsonBuffer.parseObject(Serial); // cause watchdog to go off
// Serial.readBytes(char *buffer, size_t length) will also cause a reset
//JsonObject &root = jsonBuffer.parseObject("{\"cmd\":\"success\"}"); // this will work
root["heap"] = ESP.getFreeHeap();
root["ssid"] = WiFi.SSID();
response->setCode(200);
root.printTo(*response);
request->send(response);
return;
}
}
}
I have found out that, if your ESP8266 is pulling its 3.3V from an Arduino or from an USB-TTL converter, depending on the code they won't provide enough current for the ESP8266 to run correctly.
I was running two ESPs separately, one pulling energy from an Arduino Uno and the other from this TTL converter, in different computers. One was the webclient and the other was the webserver, and these WDT resets were happening. After I hooked the ESPs to this external supply, the WDT resets stopped.
Most helpful comment
ESP.wdtEnable(), ESP.wdtDisable() seem to have no effect?