Feather Ethernet Overlay Shield will not reconnect


#1

I am using the Particle Ethernet Shield with a Photon along with the NCD Particle Library. I am running a client.

I noticed that once the connection to a server is broken, it can never be reconnected unless the Photon is restarted.

I would appreciate the community’s help on this serious problem and thanks in advance.


#2

Hi Jimmie,

We’d be happy to look into that. Can you share the code you are running? If you wrote the code on particle’s web IDE you can click the share Share this Revision button and just share the link to the code.

Also how is the connection to the server being broken? Is the server forcibly closing the socket, does it go offline or does the Photon application break the connection?


#3

Hello Travis,

Thank you very much for your offer to help. I appreciate it.

When the code starts, it connects to my TCP server. If I stop the server manually, the code senses the loss of connection immediately. But if I restart the server, the client never reconnects again.

If I restart the server application (Windows), the client still does not reconnect. The only way is to recycle power to the Photon to get a fresh connection. BTW, once it connects, the client remains connected. Yesterday, I left it overnight and in the morning the client was still connected…

Here is a link to the code:

https://go.particle.io/shared_apps/5c5da45aecdfdd002068b709

===========================
Update: If the micro-controller starts with the server down, it does connect to the server when the server is up and running. So in summary, the problem is that the client does not reconnect to the server AFTER a successful initial connection.

I hope this helps and thanks again in advance as this issue is a show stopper …


#4

Hello Travis,

Any updates?

I am also having one more problem. On the same board, I have an SD card using SPI_CONFIGURATION == 1 with CS on D5. SCK => D4, MISO => D3, MOSI => D2, SS => D5

I use the SDFat library and start the SD card first followed by your board. When I do that, I can no longer write to the SD card.

What may be causing this behavior?

Thanks in advance for your time.


#5

Hi Jimmie,

It sounds like restarting the server actually does not properly close the TCP socket to the module. This means the module does not actually know the connection closed. This is actually typical in these types of applications but it can be handled. I would recommend checking if the server is available on the other end of the socket on interval. You can do this by having the code on the board send a query to the server, then have the server send back a response. If you do not receive a response from the server then assume it is offline and disconnect the socket, then attempt to connect again.

There is a process that occurs when a socket is properly closed and that is how the module knows the server closed the socket, by restarting the server application this proper closing of the socket is not occurring.

As for the SD card library issue if it is using SPI then that could possibly cause a conflict since the Ethernet interface is also mounted via SPI. Some deep digging would be required for that but it could be that the SD card library is trying to change the pin muxing for the SPI connection.


#6

THANK YOU @Travis.

Adding a single line = client.stop(); solved the problem. It may be a good idea to modify the client example.

=============================

I know very little about SPI so would really appreciate your help in a couple of links to understand what you mean by " … the SD card library is trying to change the pin muxing for the SPI connection " The library configures the card correctly for the second SPI so why should there be a problem ( SCK => D4, MISO => D3, MOSI => D2, SS => D5)? I also tried the library with that SPI setting and it works but the Ethernet shield stops the ability to write …


#7

When in the code do you determine to put in client.stop()? After determining there is not communication with the server?


#8

Yes.

The shield (immediately) detects loss of connection. Code is below:

void loop()
{
    
    iCount ++;
    
    
  display.clearDisplay();
  display.setCursor(0, 0);
  display.println(myConn);
  display.setCursor(0, 25);
  display.println(iCount);
  display.setCursor(0, 50);
  if (client.connected())  
  {
     display.println("Connected");
  }
  else
  {
     display.println("NO CONN");
  }
  display.display();
  delay(50);
    
	if(!client.connected()){
		/*Attempt to connet to TCP server.  The third argument in this client.connect
		will always be 1 which specifies this is not over WiFi*/
		
		if(client.connect(serverIP, serverPort, 1)){
           myConn = "GOOD";
		}
		else
		{
			Serial.println("Could not connect to server");
		//	client.connect(serverIP, serverPort, 1);
			
			iCount2 ++;
			myConn = "Bad - " + String(iCount2);
			client.stop();
			delay(1000);
		}
	}
	//check for message from server and print them to the serial line.  Assuming string messages here.
	if(client.connected() && client.available() > 0){
	    	myConn = "GOOD";
		while(client.available() > 0){
			Serial.print((char)client.read());

		}
		
	}
}