W5500 chip + Arduino UNO on reference schematic can send/receive UDP messages, but TCP does not seem to work properly


I’m a relatively new user to the W5500, so I apologize if I’m asking a simple question or overlooking something or if this post is not in the convention you prefer. However, here is my situation, hopefully someone can help:

I used the reference schematic provided by Wiznet to craft my own iteration of the interface between an Arduino UNO over SPI to RJ-45/ethernet. I used this to base my own schematic off of. I can provide my own schematic as reference if this is in fact sounds like a hardware problem. I think the hardware might be OK however.

The problem is this: Using the code below (note: this is written in “Arduino C”), I can talk using UDP to the server. Here’s a short dialog referencing that. So this implies to me that the hardware seems to work as intended.

#include <SPI.h>          // needed for Arduino versions later than 0018
#include <Ethernet.h>
#include <EthernetUdp.h>  // UDP library from: bjoern@cs.stanford.edu 12/30/2008

// Enter a MAC address and IP address for your controller below.
// The IP address will be dependent on your local network:
byte mac[] = {  
  0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0x01 };
IPAddress ip(192, 168,0,200);

unsigned int localPort = 8888;              // local port to listen on

// buffers for receiving and sending data
char packetBuffer[UDP_TX_PACKET_MAX_SIZE];  //buffer to hold incoming packet,
char  ReplyBuffer[] = "acknowledged";       // a string to send back

// An EthernetUDP instance to let us send and receive packets over UDP
EthernetUDP Udp;

void setup() {
  // start the Ethernet and UDP:

  Serial.print("Server set up at: ");

void loop() {
  // if there's data available, read a packet
  int packetSize = Udp.parsePacket();
    Serial.print("Received packet of size ");
    Serial.print("From ");
    IPAddress remote = Udp.remoteIP();
    for (int i =0; i < 4; i++)
      Serial.print(remote[i], DEC);
      if (i < 3)
    Serial.print(", port ");

    // read the packet into packetBufffer

    for (int i=0; i<5; i++) {

    // send a reply, to the IP address and port that sent us the packet we received
    Udp.beginPacket(Udp.remoteIP(), Udp.remotePort());

However, when I attempt to use a very similar sketch over TCP, I can’t seem to communicate with the hardware. I can get connection between the two, but cannot send any data without the server (W5500 + Arduino) RST’ing the connection. Here is a wireshark dump of the responses using Hercules by HW-group.com to attempt to talk over a LAN using a HUB (not a SWITCH). So you can see that things are happening, the hardware thinks a client is connected, but whenever I try to send any data, the connection gets closed and I get RST’d. Anyone have any idea what could be causing this?
I’m very happy to provide more or less information. Sorry if this is hard to read or convoluted, I am trying to put as much information as possible into a small compact space.

#include <SPI.h>
#include <Ethernet.h>

// Enter a MAC address and IP address for your controller below.
// The IP address will be dependent on your local network.
// gateway and subnet are optional:
byte mac[] = {
  0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED
IPAddress ip(195, 168, 0, 200);

// telnet defaults to port 23
EthernetServer server(23);

EthernetClient clients[8];

void setup() {
  // You can use Ethernet.init(pin) to configure the CS pin
  //Ethernet.init(10);  // Most Arduino shields
  //Ethernet.init(5);   // MKR ETH shield
  //Ethernet.init(0);   // Teensy 2.0
  //Ethernet.init(20);  // Teensy++ 2.0
  //Ethernet.init(15);  // ESP8266 with Adafruit Featherwing Ethernet
  //Ethernet.init(33);  // ESP32 with Adafruit Featherwing Ethernet

  // initialize the Ethernet device
  Ethernet.begin(mac, ip);

  // Open serial communications and wait for port to open:
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only

  // Check for Ethernet hardware present
//  if (Ethernet.hardwareStatus() == EthernetNoHardware) {
//    Serial.println("Ethernet shield was not found.  Sorry, can't run without hardware. :(");
//    while (true) {
//      delay(1); // do nothing, no point running without Ethernet hardware
//    }
//  }
//  if (Ethernet.linkStatus() == LinkOFF) {
//    Serial.println("Ethernet cable is not connected.");
//  }

  // start listening for clients

  Serial.print("Chat server address:");

void loop() {
  // check for any new client connecting, and say hello (before any incoming data)
  EthernetClient newClient = server.accept();
  if (newClient) {
    for (byte i=0; i < 8; i++) {
      if (!clients[i]) {
        Serial.print("We have a new client #");
        newClient.print("Hello, client number: ");
        // Once we "accept", the client is no longer tracked by EthernetServer
        // so we must store it into our list of clients
        clients[i] = newClient;

  // check for incoming data from all clients
  for (byte i=0; i < 8; i++) {
    if (clients[i] && clients[i].available() > 0) {
      // read bytes from a client
      byte buffer[80];
      int count = clients[i].read(buffer, 80);
      // write the bytes to all other connected clients
      for (byte j=0; j < 8; j++) {
        if (j != i && clients[j].connected()) {
          clients[j].write(buffer, count);

  // stop any clients which disconnect
  for (byte i=0; i < 8; i++) {
    if (clients[i] && !clients[i].connected()) {
      Serial.print("disconnect client #");

EDIT: Uploaded send/responses from successful UDP session

I guess a more precise question would be:

Is there anything in hardware or software that would cause a TCP connection to get RST from server side any time data is received from a client?

If the server is not listening on any socket, the server will send RST in response to any attempt to connect. Note that the port number on which the server is listening must be the same as the one to which the client attempts to connect.

1 Like

Thank you Mxyxixptlick.

Got the circuit to work. Turns out it WAS hardware related. Here is my OLD schematic:

Turns out the inductor/bead that is circled there was “the” problem. Took it out and sure enough I can connect successfully via TCP without being instantly disconnected. Amazing to me that a simple inductor like that could cause such a problem.

Seems like a potential timing or filtering problem if anyone is interested in troubleshooting the root cause.