W5500-EVB + ESP32S3 IDF Basic Eth Example not working

TCP/IP Chip W5500
1

Hi, I have been trying to implement the ESP-IDF basic ethernet example with my ESP32S3 dev kit and the W5500-EVB, however I keep getting the error message w5500.mac: emac_w5500_transmit (523): free size (350) < send length (0), and never getting any ip information received.

Currently I my pin configuration to connect to the ESP32S3 is:
D13 for CLK
D12 for MISO
D11 for MOSI
RST for RESET
CS should be tied low as per the datasheet
P0_7 for INT_N
Jumper wires for power (3.3V) and GND as well.

I have referenced this document from WIZnet in determining these pins to use so far: https://docs.wiznet.io/Product/iEthernet/W5500/W5500-EVB/#features

Here is a screenshot of my sdkconfig file > example configuration:
Screenshot 2023-07-13 135027

Any help in determining what’s causing this example to fail would be greatly appreciated.

2

I still haven’t been able to resolve this issue, please let me know if anyone can think of any ideas that might help!

3

I am getting a similar error. I have 5 prototype board and it only occurs on one of them so I am thinking a likely hardware issue with the one board (solder of the chip or failed component).
Looking at the source code for the driver, it asks the chip how much memory it has free and to return 350 bytes is extremely small considering most packets are 1000 - 1500 bytes. This occurs on mine just after link negotiations (which means it passed the duplex link negotiations and can communicate at least partially with the switch. Timing between my failed board and my others is similar so I don’t think there are a bunch of retries (5 seconds for PoE and 2-3 seconds for a link). The first message I get is before I even open a socket so it is probably during the DHCP negotiations (which don’t happen).
The message 350 < 0 is a little strange.but I think they got the order of the values wrong “free size (%d) < send length (%d)”, length, free_size);
I am using IDF version 4.4

4

I found the problem with the board that was giving me the messages. It was a short between one of the pins relating to the SPI interface (don’t know which one specifically, it could have been any one or several). MISO/Clock or Clk/CS or MOSI/MISO.
It may be that if the SPI interface returns zeros, that is the first message the is returned.
I believe the link is established by the chip itself on power on. The first thing that needs to be done is check the version of the chip, write the mac and check the transmit register for space (TX_FSR). It was returning zero in my case.