ESP8266 Community Forum

I did wonder if anyone had previously seen something similar, as if someone wanted to pursue this, it would take some time and dedication to the problem to see the symptoms.....(running a PHP script on a web server which responds to the ESP8266, and running the code in its test mode, probably for hours. If you're willing, I'll supply all.

There are no call backs, interrupt service routines etc in the code which would detract from the job in hand... wait for a high to low transition on a pin, connect and send a small GET request to a PHP script on the web server, get the reply, disconnect and back to the top for the next high to low. All buffers are big enough, no memory overruns, and the code performs as expected for days without issue, just that odd delay every so often before the packet hits the wire which I cannot account for, 2-3 seconds, which is a very very long time for something running at 80MHz.

As the problem is with the connect/GET/disconnect cycle, I'll strip the code to the bare necessities and try to reproduce the issue, and supply that should it still be present. More Wiresharking to do.

"...wait for a high to low transition on a pin..." depending on how you do this, I have seen literally dozens of times when that one line will crash an esp8266. Already I have my money on that line of code being the problem.

Show me those one or two line first, and if I'm wrong,an MCVE (minimum, correct, verified example) would certainly help...the smallest anount of could possible to reproduce the problem. What often happens is that in making such a thing, you actually find the problem yourself. If not, I'm happy to look at it.

Do you have any code that messes with the watchdog timer?

The thing is, the issue appears beyond the point of waiting for that high to low transition, I've got the change on the pin, so assemble a packet and send it to the server, then sit in a time limited loop awaiting the server's reply. if (digitalRead(PULSE_PIN) == PULSE_ON) {... wait for pulse to end, move to transmit code..... the pin read is left in the rear view mirror...
No messing with timers, no interrupts, nothing to interfere with the line by line execution of the code. Keeping that in mind, then referring to the Wireshark screen grab, the connection to the server is established, the wifiClnt.print follows, then wait for the reply. Works well repeatedly, until.... that wifiClnt.print is delayed, once in maybe 500 transmissions. I don't think I'm going to get to the bottom of this one, so.....

I've re-coded the software to use UDP and written a UDP server to listen for the incoming data and make the replies. Testing so far reveals 1 packet lost in over 8,800 sent. I know the "limitations" of UDP, but with that loss rate as opposed to the potential loss rate at a faster pulse period when something delays transmissions by up to 3 seconds, well it looks fabulous to me.
I wouldn't have noticed this "issue" at all should I not be needing something which is relatively time critical, so if this hasn't been seen previously, could be a heads up if it should affect someone else.

I did put a timing counter in the loop which waits for the reply to packet "print", and when the issue arises, the counter is huge, indicating the code is indeed in that loop waiting for something to happen.
I've surrendered.....

"then sit in a time limited loop awaiting the server's reply." - is again the exact kind of behaviour that can cause problems, depending on how "tight" the loop is.

Look at the Ticker library for timing functions like this, it has an asynchronous callback, so no loops, delays, fiddling with millis() etc...all of which are "poison" on an ESP8266 if not done properly.