W7500p 10Mbit Mode Negotiation Issues

Due to the issue with 100Mbit connections on the current W7500P chips I am trying to negotiate in 10Mbit mode. I am having a weird issue where the device will only negotiate 10Mbit sometimes and will often default to 100Mbit despite calling eth.ethernet_set_link(0,0); which should correspond to 10Mbit half duplex from the Wiznet eth Library

Ethernet setup code is as follows:

EthernetInterface eth;
TCPSocketServer server;
eth.init(SystemConfig.Mac_Addr, SystemConfig.IP_Addr, SystemConfig.Mask, SystemConfig.Gateway); //Use Static

I have also tried calling eth.ethernet_set_link(0,0); after eth.init and eth.connect. This makes no difference. Does anyone have any ideas? Presumably there are people out there successfully running 10Mbit to workaround the bug. Could it be hardware related? Perhaps damage to the PHY from overheating during soldering?

Sorry. W7500P is not to support mbed OS5(EthernetInterface) yet.
If you need to use Ethernet in mbed, you have to use WIZnetinterface library untill now.


Hi I am using Mbed but also using the WIZnetInterface library. Could there be a conflict because of this? This is based on the TCPechoserver example project by Wiznet so I assumed this is ok

I found some bug in WIZnetInterface library with set_link( ) function.
I used a project in the following link.

I changed a platform from WIZwiki-W7500 to WIZwiki-W7500P.
And I used static IP instead of DHCP.

I modified source code of W7500x_toe.cpp file.

//#define CNTL_DUPLEX (0x01ul<< 7)
//#define CNTL_AUTONEGO (0x01ul<<11)
//#define CNTL_SPEED (0x01ul<<12)
#define CNTL_DUPLEX (0x01ul<< 8)
#define CNTL_AUTONEGO (0x01ul<<12)
#define CNTL_SPEED (0x01ul<<13)

And I added eth.set_link( ) function in main( ) function.

WIZnetInterface library will be updated soon.


One more.

  //val = ((CNTL_SPEED&(speed<<11))|(CNTL_DUPLEX&(duplex<<7))); 
  val = ((CNTL_SPEED&(speed<<13))|(CNTL_DUPLEX&(duplex<<8))); 


#include “mbed.h”
#include “EthernetInterface.h”


char ip_addr = “”;
char subnet_mask = “”;
char gateway_addr = “”;

int main (void)
printf(“Wait a second…\r\n”);
uint8_t mac_addr[6] = {0x00, 0x08, 0xDC, 0x01, 0x02, 0x03};
EthernetInterface eth;
//eth.init(mac_addr); //Use DHCP
eth.init(mac_addr, ip_addr, subnet_mask, gateway_addr); //Not Use DHCP
printf(“Server IP Address is %s\r\n”, eth.getIPAddress());


Thanks that does seem to have improved things slightly. Now 95% of the time if the ethernet jack is connected before the device is powered on it will negotiate to 10Mbps. However, if the eth cable is connected AFTER powering up on the device it will default to 100Mbps most of the time.

Does the W7500P default/reset the speed select registers if it fails to negotiate a connection at start up? Or is there something else that would be causing this. Also very occasionally it will also default to 100Mpbs even if the eth cable is connected before powering on. Any idea what would be causing this?

Also, how long until the latest stepping W7500P with the 100Mbps bugfix is released? In another thread we were told beginning of August. This would solve all my problems.

Thank you

How do you judge 100Mbps? If you judge by LED, I think it is not a good judgment criterion. Is the other side set as auto negotiation? please check auto negotiation in opposite side. And please wait for the next release of W7500P.

Please ask the release schedule of W7500P to sales@wiznet.io


So I have tested the latest stepping of the W7500P (1720 marking) and the 100Mbps problem does not appear to be resolved. I’m getting an unacceptable amount of disconnects when connection speed is 100Mbps.

I have tested both through a router and a direct connection to PC. The device is polled every 1s and dropouts were logged over a 24h period. I get approximately 1 disconnect every 3 hours over LAN. Interestingly, with a direct PC connection the disconnects are far more frequent. 1 disconnect every 3 minutes!

Running the same test, forcing 10Mbps speed, resulted in 0 disconnects over a 24h period for both LAN and direct connection. The software and libraries were identical for all tests except for calling eth.set_link(FullDuplex10). Is there an updated ethernet library I should be using in conjunction with the latest stepping to fix the 100Mbps bug?

Also, eth.set_link(FullDuplex10); is definitely not working properly even after the recommended changes to the library. It fails to force 10Mbps negotiation and defaults to 100Mbps far more often than I originally thought. I often have to reboot the device multiple times before it actually connects at 10Mbps. I’m guessing there is some sort of hard-coded timeout where if it fails to connect at a desired speed it defaults or the register that sets link speed is being reset somehow? Link speed has been verified using the W7500P device’s LEDs and in the local area connection settings on the PC. It’s also pretty obvious when it is operating at 100Mbps because of the frequency of disconnects.

Currently all devices in the field are directly connected to a PC. The connection speed is forced to 10Mbps in the PC’s network settings since setting link speed on the W7500P does not work properly. This severely limits our applications since we can only use 1 W7500P device (1 ethernet port on a PC) and have to connect the PC to our LAN via a Wifi adapter.

Hopefully there is a quick fix for this because quite frankly I’m about to give up on Wiznet

Dear finlayg

I heard W7500P(1720) is revision and 100Mbps issue is fixed.
I need more information to investigate your issue in detail.

I have some question.

Do you use WIZwiki-W7500P board? Or have you rebuilt the board with W7500P?
If you are the latter, please send your schematic file and gerber file to support@wiznet.io to check H/W part.
Could you get a pcap file of wireshark in case of problems?
What kind of LAN card(PC) and router(AP) do you use?
What kind of Server program do you use during test?
Where is your location(country)? (To compare similar cases)

Please give details of the test environment so that we can reproduce it.


Do you use WIZwiki-W7500P board? Or have you rebuilt the board with W7500P?
If you are the latter, please send your schematic file and gerber file to support@wiznet.io to check H/W part.

We are using a custom designed board based on the W7500P. I’ve emailed the schematic pdf and gerbers.

Could you get a pcap file of wireshark in case of problems?

In the email I’ve attached pcap and corresponding disconnect log for both a direct connection and switch connection

What kind of LAN card(PC) and router(AP) do you use?

The PC has an Intel 82579LM Gigabit network card. It was also tested through a switch (TP Link TL-SG1024) and router (Netcomm NF4V)

What kind of Server program do you use during test?

The W7500P device is running as a MODBUS TCP server. This uses the Mbed and WiznetInterface libraries. I can give you read access to the Mbed repository if you have an account.

The W7500P server is polled every 1s by a PC acting as a TCP client (in-house custom program). The PC sends a standard MODBUS function 23 read/write request. The W7500P responds in standard MODBUS 23 format. The program stores disconnects to a log file. A disconnect is determined when a request is not acknowledged by the W7500P server after 3 attempts.

Where is your location(country)? (To compare similar cases)

We are located in New Zealand

Please let me know your title of e-mail. I cannot check your e-mail in our ticket system.

Please upload your pcap file into this topic. I will check that.


The email has the same title as this thread “W7500p 10Mbit Mode Negotiation Issues”. I sent it to support@wiznet.io
Do you have a direct email address I can send it to?

For IP protection reasons, I’d prefer not to upload the pcap to this thread if I can avoid it.

Dear finlayg

Please refer to the following e-mail and attach your pcap file.


I checked your pcapng files.
There is no problem during TCP connection.
As you know, Modbus is the application protocol above TCP.
I think it is a Modbus problem about disconnect operation.


It’s not the LAN connect file that I’m worried about so much. The direct connect pcap is the interesting one. It disconnects every 3 minutes. The TCP behaviour is strange and generating duplicate packets

Duplicate ACK is not a problem because TCP data is being sent repeatedly.
The problem is repetitive TCP retransmissions. It seems that Modbus data is not fully analyzed by Wireshark.
I recommend try using delay in the middle of data transfer.
If you use timeout register(RTR, RCR register), please try changing it to an increased value.


Finlayg, did you ever find a solution for this?

Dear Customers,

We fixed this issue on W7500P and have released new one, W7500P R3 in August of this year.
You can distinguish R3 from R2 with the date code on it.
Date code since 1720 is all R3 and you can use it in any operation mode.

Thank you.