ESP8266 Community Forum

I wish to capture asynchronous serial data by my ESP8266. I am using the Arduino IDE interrupt functions. I enter a while loop and rely on an interrupt from the incoming data to exit the loop. This way I get really accurate timing to see if I am receiving a 1 or a 0.

It works OK to a point. If the sketch spends too much time in the while loop (gaps in the data), the ESP apparently resets itself printing: " ets Jan 8 2013,rst cause:4, boot mode:(3,7) " plus a whole bunch of other stuff. Stuff that looks like the results of an AT-RST command.

You can see this by writing:
void setup(){
Serial.begin(115200); -- found this line is not even necessary as long as serial monitor is set to 115200 baud
while(1);
}
When you run this, you would expect the result to appear like a hung process with nothing printing to the serial monitor - but, every few seconds, it prints what I have indicated above, apparently going into the reset mode.

I also see this phenomenon by using the ESP as a client, connecting to a server and sending it data using WiFi.print("some string") commands.

If I do:
WiFi.print"abc");
WiFi.print("def");
all is OK. If I add a third statement:
WiFi.print("fgh");
maybe OK. But If I have a forth statement:
WiFi.print("ijk");
I always get the apparent reset and the sketch stops.

Can you tell me what is going on here and is there any way around it.

Thanks

I am a novice in this area ... so please understand that if you read on ...

My understanding is that the ESP8266 runs Wifi code as well as user code however you MUST relinquish control back to the Wifi code as often as you can. I could easily imagine that the Wifi code has a timer interrupt in it that asks if it has been "serviced" often enough. If this turns out to be no, then it takes a radical action ... which is to reboot itself. I think the notion here is that this not just another "MCU" that can be used for arbitrary purposes, but rather this is a WiFi device that happens to allow custom programming. If there is truth in that ... and we spend too much time out of necessary WiFi based processing, then it would make sense to reset in the hope of returning to a WiFi processing state.

Moin Kolban,

there is a lot of truth in your answer. The wifi code and the wifi timers need to get control to function properly.
The reset is done by the watchdog timer if your code blocks the main loop for too long.
Using long delays on the esp8266 will typically lead to trouble.

Note that you see it's the watchdog timer resetting the module because "wdt reset" is printed.

Cal

cal wrote:Moin Kolban,
The reset is done by the watchdog timer if your code blocks the main loop for too long.
Using long delays on the esp8266 will typically lead to trouble.

"Delay" might not be the ideal choice of words, as I believe that the delay() function (even delay(0)) allows the Wifi code to run if needed, and resets the watchdog timer. A loop that takes a long time without any calls to delay() (or other methods of feeding the watchdog) will causes a watchdog reset.

Just a little clarification.CMIIAW