I’ve confirmed through Serial1 debug output that at about 5 seconds into my program TCPServer.available() starts blocking for 20 seconds. At this point it is also 20 seconds between when loop() exists and it get’s called again. The whole spark then goes wonky and unresponsive eventually getting blocking blue and then eventually blinking green.
I’ve commented everything out except the generic TCP loop. I am not even trying to connect, the thing is left idle and server.available() doesnt ever return an active TCPClient either. I have not attached any other interrupts or timers to do anything - just what is called by TCP and Serial1.begin(). I’ve also done the deep update 4/6 and the latest update. Same result on other sparks I have too.
I’ve spent the summer trying to get this working and it’s constantly this or that bug. I am just about ready to throw it in the garbage.
Hootie81: No, it’s correct. It’s calling server.available() and setting client to that return value, then testing the value of client. There is obviously a bool operator on that class returns true if the client object is connected or not.
After some more debugging it seems the spark network routines don’t like much interrupt activity. Usage of Serial1 for my debugging can cause it to block earlier than without debug output yet it doesn’t prevent it. It is the difference between perhaps 5 seconds before block and 5 minutes though.
I had a simple Serial1.print(‘N’); before the client=server.available(). If I add a delay(1); in-between the print() and client=…it doesnt block for a while.
That sounds familiar, I think I’ve seen other instances of the serial buffer getting full and having side effects on tcp client behavior. I passed this thread along to our firmware team.