--- title: "W5500 is running ok,but link PC directly the ping timeout is big (20 ms) and the throughout is just 1Mbps" url: "https://maker.wiznet.io/forum/12196" markdown_url: "https://maker.wiznet.io/forum/12196/md" type: "Forum topic" category: "Ethernet Chips" author: "youngtao" created: "2017-03-14T05:40:54+09:00" last_activity: "2017-11-15T09:57:53+09:00" language: "en" views: 5406 replies: 38 source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)" --- # W5500 is running ok,but link PC directly the ping timeout is big (20 ms) and the throughout is just 1Mbps ## Question Asked by youngtao on 2017-03-14 in Ethernet Chips. hi, now we meet an error of network latency/delay by W5500 of spi(50MHz) qcom 8974 AP running Android OS with the direct link to PC, it’s about 20ms and the throughout is low (about 1Mbps)by testing of iperf tool(cmd such as iperf -c 192.168.1.1 -i 10 -t 30).couldyou please help us to check it. tkx. Youngtao ## Replies ### Reply 1 by Eugeny, 2017-03-14 ![](https://avatars.discourse-cdn.com/v4/letter/y/edb3f5/48.png) youngtao: > Android OS with the direct link to PC I recommend you installing Wireshark on the PC to obtain communication log with the device. There could be multiple causes for the issue, like - physical issue like broken cable (causing retransmissions) - your W5500 driver being a bottleneck and too slow in working with TX/RX buffers and control registers - if you use TCP take a look at Sn_MR register bit 5 “No delayed ACK” ensuring it is set when socket is initialized ### Reply 2 by youngtao, 2017-03-15 thank you so much, Eugeny, we will have a try, and give you our reply. BR. youngtao ### Reply 3 by youngtao, 2017-03-15 Eugeny: > [quote=“youngtao”]Android OS with the direct link to PC I recommend you installing Wireshark on the PC to obtain communication log with the device. There could be multiple causes for the issue, like - physical issue like broken cable (causing retransmissions) - your W5500 driver being a bottleneck and too slow in working with TX/RX buffers and control registers - if you use TCP take a look at Sn_MR register bit 5 “No delayed ACK” ensuring it is set when socket is initialized[/quote] hi,Eugeny, today we find that there are no retransmission packets in all which are caught by wireshark tool. and then we open the register function of no delayed ACK, but it doesn’t work to the timeout and throughout. so you told us maybe its the linux w5500 driver bug, now we are checking the driver code, and could you please help us to review our w5500 driver code which is just uploaded? tkx a lot. BR. Youngtao [w5500.zip](https://maker.wiznet.io/forum/legacyFile.asp?path=mu9ZYSjti7m2nsqhjFA5Yjikwsu.zip) (737 KB) ### Reply 4 by Eugeny, 2017-03-15 ![](https://avatars.discourse-cdn.com/v4/letter/y/edb3f5/48.png) youngtao: > could you please help us to review our w5500 driver code Before anything I would like to see wireshark packet trace log to see the timing. Please attach it. Thank you. ### Reply 5 by youngtao, 2017-03-16 hi,Eugeny, the packets of ping and iperf are attached, and the device IP is 192.168.1.2, the PC IP is 192.168.1.100, please check them. thx so much. BR. youngtao [pcap.zip](https://maker.wiznet.io/forum/legacyFile.asp?path=ienmgHPR9CpghBT6m1Czsv4atBA.zip) (117 KB) ### Reply 6 by Eugeny, 2017-03-16 Looking to the ping log I see that W5500 responds within 5-6ms for small packet size and large packet size, for packet size about 1K it responds within a 18 ms (e.g. 1280). From test log I see that you allocated whole space of 16K for one socket. Packet size is 1214, and only two packets are being acknowledged in series (thus most of the allocated 16K buffer is not used). PC acknowledge comes almost immediately, and I see pattern in W5500 operation delaying its packets by ~8ms every time. Here’re things you may need to focus on: 1. You may not need 16K for the socket. I do not know how packet of 1214 bytes appears, it may happen that your testing tool loads data of this size and issues W5500’s SEND command. This is NOT optimized for performance. If you have 16K socket, you can put all 16K data in, and then issue SEND command and then W5500 will select maximal possible packet size for transmission. Remember that smaller packets will take longer time to transmit. Thus you either increase size of data, or decrease buffer size to 2K or 4K. I recommend to go to default 2K size as a test because 2K socket is default for W5500, I do not know how chip will behave for changed buffer size in terms of its socket performance. 2. I still have a suspicion that you need to check setting of no delayed ACK bit. Before sending data in your test (after you opened socket and connection got established), read socket’s mode register and test for bit 5 to ensure it it set to 1 (in general, MR should be 0x21). 3. W5100’s datasheet is having very good explanation of the programming of the socket in chapter 5. Please review it to ensure you perform sockets programming properly. ### Reply 7 by youngtao, 2017-03-17 [quote=“Eugeny”]Looking to the ping log I see that W5500 responds within 5-6ms for small packet size and large packet size, for packet size about 1K it responds within a 18 ms (e.g. 1280). From test log I see that you allocated whole space of 16K for one socket. Packet size is 1214, and only two packets are being acknowledged in series (thus most of the allocated 16K buffer is not used). PC acknowledge comes almost immediately, and I see pattern in W5500 operation delaying its packets by ~8ms every time. Here’re things you may need to focus on: 1. You may not need 16K for the socket. I do not know how packet of 1214 bytes appears, it may happen that your testing tool loads data of this size and issues W5500’s SEND command. This is NOT optimized for performance. If you have 16K socket, you can put all 16K data in, and then issue SEND command and then W5500 will select maximal possible packet size for transmission. Remember that smaller packets will take longer time to transmit. Thus you either increase size of data, or decrease buffer size to 2K or 4K. I recommend to go to default 2K size as a test because 2K socket is default for W5500, I do not know how chip will behave for changed buffer size in terms of its socket performance. 2. I still have a suspicion that you need to check setting of no delayed ACK bit. Before sending data in your test (after you opened socket and connection got established), read socket’s mode register and test for bit 5 to ensure it it set to 1 (in general, MR should be 0x21). 3. W5100’s datasheet is having very good explanation of the programming of the socket in chapter 5. Please review it to ensure you perform sockets programming properly.[/quote] ok,Eugeny,thx a lot, 16k buffer code is from Chinese fae, so we keep it not changed, and now we wanna use the 8socket function for big bandwidth, do you have w5500 linux driver reference code of the 8socket register, because Chinese fae can’t supply it to us. for we are now 1Mbps by 1 socket, maybe use 8 socket it will be about 8Mbps, or 5Mbps is ok. ### Reply 8 by Eugeny, 2017-03-17 ![](https://avatars.discourse-cdn.com/v4/letter/y/edb3f5/48.png) youngtao: > 16k buffer code is from Chinese fae, so we keep it not changed If product you design is for commercial use, then wrong decisions on architecture may cause product sales issues. Do you have TOR (terms of reference) defining who your customer is, and what functionalities this customer may want, and what exactly technical characteristics you should achieve? Seems you do not want to take ownership or control over the architecture, relying on someone’s work - it is easy, but will not help success of your product. Point your Chinese FAE to this thread so that s/he reconsides the architecture of the solution. ![](https://avatars.discourse-cdn.com/v4/letter/y/edb3f5/48.png) youngtao: > maybe use 8 socket it will be about 8Mbps, or 5Mbps is ok This is very questionable assumption. 8 sockets will require more CPU load, and management of the data split between sockets, plus none will guarantee how W5500 will behave in response to your code design. ![](https://avatars.discourse-cdn.com/v4/letter/y/edb3f5/48.png) youngtao: > and now we wanna use the 8socket function for big bandwidth As I said - increase data load size to the buffer, this is first thing to try. ![](https://avatars.discourse-cdn.com/v4/letter/y/edb3f5/48.png) youngtao: > do you have w5500 linux driver reference code of the 8socket register Ask WIZnet, check their software/driver download site. Most porbably you will find some libraries, but you should know that if you need performance (per TOR) standard solution may not be the best to use. ### Reply 9 by youngtao, 2017-03-18 Eugeny: > [quote=“youngtao”]16k buffer code is from Chinese fae, so we keep it not changed If product you design is for commercial use, then wrong decisions on architecture may cause product sales issues. Do you have TOR (terms of reference) defining who your customer is, and what functionalities this customer may want, and what exactly technical characteristics you should achieve? Seems you do not want to take ownership or control over the architecture, relying on someone’s work - it is easy, but will not help success of your product. Point your Chinese FAE to this thread so that s/he reconsides the architecture of the solution. ![](https://avatars.discourse-cdn.com/v4/letter/y/edb3f5/48.png) youngtao: > maybe use 8 socket it will be about 8Mbps, or 5Mbps is ok This is very questionable assumption. 8 sockets will require more CPU load, and management of the data split between sockets, plus none will guarantee how W5500 will behave in response to your code design. ![](https://avatars.discourse-cdn.com/v4/letter/y/edb3f5/48.png) youngtao: > and now we wanna use the 8socket function for big bandwidth As I said - increase data load size to the buffer, this is first thing to try. ![](https://avatars.discourse-cdn.com/v4/letter/y/edb3f5/48.png) youngtao: > do you have w5500 linux driver reference code of the 8socket register Ask WIZnet, check their software/driver download site. Most porbably you will find some libraries, but you should know that if you need performance (per TOR) standard solution may not be the best to use.[/quote] hi,Eugeny, the buffer changing doesn’t work for the bandwidth, maybe the point of the bug is the working socket register NO. and by the way, our device memory is big enough for W5500, for the wifi bandwidth is 18Mbps or more in 5GHz channe. thx a lot, we will work out this bug according to you valuable suggestion. BR. YOUNGTAO ### Reply 10 by Eugeny, 2017-03-18 Youngtao, while I was focusing on the data throughput, I forgot issue related to ping having about 18 ms response. Ping performance has nothing to do with host driver/data performance, thus there really seems to be a problem. I have W5100 custom board, just have run test to ensure that it replies within less than 1 ms to the nearby PC’s ping response. TX/RX buffer size does not affect ping response performance (as far as I see in my test). Thus I decided to take a look onto your driver code, finding out that you use WIZnet standard driver. I also see the following line in dev.c ``` iinchip_outb(REG_TMODE, TMODE_PINGBLOCK | TMODE_NOSIZECHK_RAW); ``` however bit 2 is indicated to be *reserved* in the datasheet, searching for it gave me the following source [github.com/borg42/w5x00/blob/master/dev.c](https://github.com/borg42/w5x00/blob/master/dev.c) saying the following `1483 // TMODE_NOSIZECHK_RAW (0x04) is defined as "reserved" in w5500 as well as w5x00 datasheet! wtf? 1484 iinchip_outb(lp->regs.REG_TMODE, TMODE_PINGBLOCK /*| TMODE_NOSIZECHK_RAW*/);` I would also disable this TMODE_NOSIZECHK_RAW bit setting in your driver (we can see it as being the undocumented functionality). Further, I ask you please perform dump or whole “common register block” (0x0-0x39) after W5500 initialization is finished by the driver (e.g. before the driver goes to establishing/listening mode) - so that we can see which settings all the registers have and try to figure out potential issues. ### Reply 11 by youngtao, 2017-03-20 [quote=“Eugeny”]Youngtao, while I was focusing on the data throughput, I forgot issue related to ping having about 18 ms response. Ping performance has nothing to do with host driver/data performance, thus there really seems to be a problem. I have W5100 custom board, just have run test to ensure that it replies within less than 1 ms to the nearby PC’s ping response. TX/RX buffer size does not affect ping response performance (as far as I see in my test). Thus I decided to take a look onto your driver code, finding out that you use WIZnet standard driver. I also see the following line in dev.c ``` iinchip_outb(REG_TMODE, TMODE_PINGBLOCK | TMODE_NOSIZECHK_RAW); ``` however bit 2 is indicated to be *reserved* in the datasheet, searching for it gave me the following source [github.com/borg42/w5x00/blob/master/dev.c](https://github.com/borg42/w5x00/blob/master/dev.c) saying the following `1483 // TMODE_NOSIZECHK_RAW (0x04) is defined as "reserved" in w5500 as well as w5x00 datasheet! wtf? 1484 iinchip_outb(lp->regs.REG_TMODE, TMODE_PINGBLOCK /*| TMODE_NOSIZECHK_RAW*/);` I would also disable this TMODE_NOSIZECHK_RAW bit setting in your driver (we can see it as being the undocumented functionality). Further, I ask you please perform dump or whole “common register block” (0x0-0x39) after W5500 initialization is finished by the driver (e.g. before the driver goes to establishing/listening mode) - so that we can see which settings all the registers have and try to figure out potential issues.[/quote] tkx so much, Eugeny, i will catch the reg ASAP. ### Reply 12 by youngtao, 2017-03-20 [quote=“Eugeny”]Youngtao, while I was focusing on the data throughput, I forgot issue related to ping having about 18 ms response. Ping performance has nothing to do with host driver/data performance, thus there really seems to be a problem. I have W5100 custom board, just have run test to ensure that it replies within less than 1 ms to the nearby PC’s ping response. TX/RX buffer size does not affect ping response performance (as far as I see in my test). Thus I decided to take a look onto your driver code, finding out that you use WIZnet standard driver. I also see the following line in dev.c ``` iinchip_outb(REG_TMODE, TMODE_PINGBLOCK | TMODE_NOSIZECHK_RAW); ``` however bit 2 is indicated to be *reserved* in the datasheet, searching for it gave me the following source [github.com/borg42/w5x00/blob/master/dev.c](https://github.com/borg42/w5x00/blob/master/dev.c) saying the following `1483 // TMODE_NOSIZECHK_RAW (0x04) is defined as "reserved" in w5500 as well as w5x00 datasheet! wtf? 1484 iinchip_outb(lp->regs.REG_TMODE, TMODE_PINGBLOCK /*| TMODE_NOSIZECHK_RAW*/);` I would also disable this TMODE_NOSIZECHK_RAW bit setting in your driver (we can see it as being the undocumented functionality). Further, I ask you please perform dump or whole “common register block” (0x0-0x39) after W5500 initialization is finished by the driver (e.g. before the driver goes to establishing/listening mode) - so that we can see which settings all the registers have and try to figure out potential issues.[/quote] hi,Eugeny, the all log of device is attached, which include the all common REG value at the last several line just like this: <6>[ 131.559261] *SOCKET NO.:0, COMMON REG (0x000000) VAULE:0x14 [sucomreg.zip](https://maker.wiznet.io/forum/legacyFile.asp?path=uwa2LuzR9NBgF7Nvrcg342VZmUc.zip) (23.9 KB) ### Reply 13 by Eugeny, 2017-03-20 Youngtao, so what we have here… MR (0) = 0x14. As I said in previous post try with bit 2 reset (so that it is 0x10). GAR (1-4) = 0,0,0,0. W5500 uses gateway address to direct specific requests, for example it may perform some ARP queries to gateway. If there’s a gateway, set its address so that W5500’s requests to it would be properly fulfilled. SUBR (5-8) = 0,0,0,0. This setting is ok if there’s no router (in your config GAR=0), thus *I think* GAR and SUBR all zeros, from standard point of view, should be ok, but it is a good question how these values are handled by W5500 internally. I never tried this way, I always had gateway and subnet mask (but I always use internet which requires router, in your case you just connect two devices without “outer world”, right?). Nevertheless, if there’s gateway in your setup, set subnet mask appropriately (as well as GAR). SHAR (9-e) = 0,8,dc,91,97,98, looks like valid MAC address with no special bits set. SIRP (f-12) = 0,0,0,0. From now on I think that you took the dump of the W5500 when it is not configured yet. We need dump of fully configured W5500 when it is expected to answer ping requests. Quickly on other regs: SIMR (18) = 0x1, interrupts from socket 0 are enabled RTR and RCR are default (7d0 and 8 respectively) PHY (2e) = 0xba, configured by pins, all capable, current connection is 100MBit, and link is down! So, in addition to incomplete configuration, chip is disconnected from the LAN. I also see the following: ``` <6>[ 131.566781] sock:0 SOCK_STATUS = 0x42 , Protocol = 0x14 ``` where status of 0x42 is ``` 0x42 / SOCK_MACRAW / This indicates Socket 0 is opened in MACRAW mode (S0_MR(P[3:0]) = ‘0100’)and is valid only in Socket 0. It changes to SOCK_MACRAW when S0_MR(P[3:0] = ‘0100’ and OPEN command is ordered. ``` So you are going to communicate using RAW mode, not TCP and not UDP-with-header modes, right? Also looking at your log output ``` <6>[ 131.559261] *************SOCKET NO.:0, COMMON REG (0x000000) VAULE:0x14 ``` I would say you may confuse socket registers and common registers. Common registers set operating mode of the chip, socket registers set operating mode of the socket. Then I suspect that this is why you initialize socket 0 in MACRAW mode writing the same value 0x14 to S0_MR as well as to MR. Please check carefully and reply with your findings. ### Reply 14 by youngtao, 2017-03-22 [quote=“Eugeny”]Youngtao, so what we have here… MR (0) = 0x14. As I said in previous post try with bit 2 reset (so that it is 0x10). GAR (1-4) = 0,0,0,0. W5500 uses gateway address to direct specific requests, for example it may perform some ARP queries to gateway. If there’s a gateway, set its address so that W5500’s requests to it would be properly fulfilled. SUBR (5-8) = 0,0,0,0. This setting is ok if there’s no router (in your config GAR=0), thus *I think* GAR and SUBR all zeros, from standard point of view, should be ok, but it is a good question how these values are handled by W5500 internally. I never tried this way, I always had gateway and subnet mask (but I always use internet which requires router, in your case you just connect two devices without “outer world”, right?). Nevertheless, if there’s gateway in your setup, set subnet mask appropriately (as well as GAR). SHAR (9-e) = 0,8,dc,91,97,98, looks like valid MAC address with no special bits set. SIRP (f-12) = 0,0,0,0. From now on I think that you took the dump of the W5500 when it is not configured yet. We need dump of fully configured W5500 when it is expected to answer ping requests. Quickly on other regs: SIMR (18) = 0x1, interrupts from socket 0 are enabled RTR and RCR are default (7d0 and 8 respectively) PHY (2e) = 0xba, configured by pins, all capable, current connection is 100MBit, and link is down! So, in addition to incomplete configuration, chip is disconnected from the LAN. I also see the following: ``` <6>[ 131.566781] sock:0 SOCK_STATUS = 0x42 , Protocol = 0x14 ``` where status of 0x42 is ``` 0x42 / SOCK_MACRAW / This indicates Socket 0 is opened in MACRAW mode (S0_MR(P[3:0]) = ‘0100’)and is valid only in Socket 0. It changes to SOCK_MACRAW when S0_MR(P[3:0] = ‘0100’ and OPEN command is ordered. ``` So you are going to communicate using RAW mode, not TCP and not UDP-with-header modes, right? Also looking at your log output ``` <6>[ 131.559261] *************SOCKET NO.:0, COMMON REG (0x000000) VAULE:0x14 ``` I would say you may confuse socket registers and common registers. Common registers set operating mode of the chip, socket registers set operating mode of the socket. Then I suspect that this is why you initialize socket 0 in MACRAW mode writing the same value 0x14 to S0_MR as well as to MR. Please check carefully and reply with your findings.[/quote] hi,Eugeny, we set and dump the common reg again by PC linked directly, and now it doesn’t work to the timeout, in our opinion, there must be something block the ping echo reply packet, maybe it’s some function such as iinchip_mac_rx_tasklet() . and from the “ping block” (0x10)description of DS, it means there is no reply to ping request ? could we disable it by setting 0bit? the 5500 chip have a function of auto reply ping, could we open it to check the 5500 is running ok in our device especially the chip pin is ok. by the way the new common register list is attached, please check it. tkx. BR. YOUNGTAO [reglog.zip](https://maker.wiznet.io/forum/legacyFile.asp?path=pboIxxhhTLl9esyiswRFWyYcokg.zip) (687 Bytes) ### Reply 15 by Eugeny, 2017-03-22 From my perspective log looks fine now. And you have checked it still has 20 ms delay in reply to ping request? I still see ``` <6>[ 83.356338] sock:0 SOCK_STATUS = 0x42 , Protocol = 0x14 ``` You still initialize socket in RAW mode. Please open socket 0 in TCP mode setting S0_MR into 0x21, and then giving command 0x01 (open) to CR, and only then try pinging W5500. If ping still gives long time values, I would change course of action - would designed “dummy” driver for W5500, which would only contain the following: 1. software reset (MR bit 7 set to 0, then waiting till this bit resets); 2. set MR to 0x10; 3. set proper GW IP, mask, MAC address, and own IP address; and that’s all - not changing anything else from the defaults. Then I would try to ping W5500 and see result. If it would have the same 20 ms reply, the issue might be not in the chip OR you may have found issue in the chip. If ping will be ok (1ms), then there’s some issue in your further chip configuration (e.g. it does not handle single 16KB buffer properly) - and it will require further troubleshooting. ### Reply 16 by youngtao, 2017-03-23 [quote=“Eugeny”]From my perspective log looks fine now. And you have checked it still has 20 ms delay in reply to ping request? I still see ``` <6>[ 83.356338] sock:0 SOCK_STATUS = 0x42 , Protocol = 0x14 ``` You still initialize socket in RAW mode. Please open socket 0 in TCP mode setting S0_MR into 0x21, and then giving command 0x01 (open) to CR, and only then try pinging W5500. If ping still gives long time values, I would change course of action - would designed “dummy” driver for W5500, which would only contain the following: 1. software reset (MR bit 7 set to 0, then waiting till this bit resets); 2. set MR to 0x10; 3. set proper GW IP, mask, MAC address, and own IP address; and that’s all - not changing anything else from the defaults. Then I would try to ping W5500 and see result. If it would have the same 20 ms reply, the issue might be not in the chip OR you may have found issue in the chip. If ping will be ok (1ms), then there’s some issue in your further chip configuration (e.g. it does not handle single 16KB buffer properly) - and it will require further troubleshooting.[/quote] hi,Eugeny, we set the socket 0 MR to 0x21 and CR to 0x01, then the network is fail, and the ping is fail too, because that the mac address will not be learned each other, if we use cmd"arp -s x x" to bind the ip and mac by manual, it still doesn’t work.that is why set the raw protocol, and now the common register and protocol status is as following: [protocol status.zip](https://maker.wiznet.io/forum/legacyFile.asp?path=qpaqxTifSS3XY6AAYy9yl9mfFge.zip) (709 Bytes) ### Reply 17 by youngtao, 2017-03-23 hi,Eugeny, the photo is the test result and the tcpdump packet. BR. YOUNGTAO [![](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/e1e71e5ca398087efbe9ac1a3900e46924efe222.jpg) 4608×3456 4.85 MB](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/e1e71e5ca398087efbe9ac1a3900e46924efe222.jpg) ### Reply 18 by Eugeny, 2017-03-23 Youngtao, I am very sorry, I was mistaken about MR value. Datasheet says ``` 4 | PB | Ping Block Mode: 0 : Disable Ping block, 1 : Enable Ping block; If the bit is ‘1’, it blocks the response to a ping request. ``` To be ping-able device should have bit 4 as ZERO, not 1. Thus please, after you software reset the chip with bit 7 (MR ← 0x80), just wait until this bit clears, and no further operation on MR is necessary. When you will have bit 4 of common register “MR” to 0, W5500 will be replying to ping requests. You actually were already saying that in ![](https://avatars.discourse-cdn.com/v4/letter/y/edb3f5/48.png) youngtao: > and from the “ping block” (0x10)description of DS, it means there is no reply to ping request ? could we disable it by setting 0bit? but I did not read it well. Next, ``` <6>[ 74.181856] sock:0 SOCK_STATUS = 0x13 , Protocol = 0x21 ``` you have opened socket (status 0x13) in TCP mode and with no delayed ACK bit set. Good! So now your task is to connect to the PC using CONNECT command (CR ← 0x04), and if connect is successful, status reg will become 0x17. Then you can send and receive data. For successful connect PC should listen to the respective destination port in TCP mode. DP (destination port #) should be set in W5500’s socket registers 0x10-0x11. During connection command execution, you should see packet exchange between W5500 and PC - probably several ARP packets, and TCP SYN/ACK packets. But before proceeding to TCP connect, please check timing of ping to see if it is still 20 ms, or timing has improved. ### Reply 19 by wiznetcannot, 2017-11-13 (in reply to reply 1) hello Eugeny, i am sorry to disturb you .BUT i have met a problem and hope your help. linux 3.18 with w5500 driver , read and write regs are ok . Under macraw model ,but i cannot ping my w5500 wit pc HOpe you help .Thx ### Reply 20 by Eugeny, 2017-11-13 ![](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/48.png) wiznetcannot: > Under macraw model ,but i cannot ping my w5500 wit pc What is the value or MR register in common register block? ### Reply 21 by wiznetcannot, 2017-11-13 it is 0x14 ### Reply 22 by wiznetcannot, 2017-11-13 soc is mt6755(android 6). spi speed is 1Mbps ### Reply 23 by wiznetcannot, 2017-11-13 socket moe reg is 0x94 AND status reg is 0x42. I print this regs after wiznet open operation… ### Reply 24 by Eugeny, 2017-11-13 ![](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/48.png) wiznetcannot: > it is 0x14 Are you taking about MR register in common register block? Bit 2 is said to be “reserved” in it, not sure why it is set in your case. I think your 0x14 is socket’s MR, not common one. Anyway, for W5500 to respond to ping requests bit 4 should be **reset** (as per datasheet “ping block is disabled”), ensure that on chip initialization you write 0x80 to perform software reset, then wait until its bit 7 reset (software reset completion), and do not write anything else in there (ping responding is enabled by default). ### Reply 25 by wiznetcannot, 2017-11-13 i have done as you said , now ,the MR reg is 0x00, but still i cannot ping with my pc… BTW, does spi speed influence ping operation ?? THE green led is always bright and the yellow one is blinked when i connect it with my pc thx ### Reply 26 by Eugeny, 2017-11-13 ![](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/48.png) wiznetcannot: > when i connect it with my pc Do you connect P2P with your PC? How your PC’s network interface is configured? How W5500 is configured? ![](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/48.png) wiznetcannot: > does spi speed influence ping operation ?? I do not think so if W5500 is seen properly from the SPI side. However there’s always a possibility that you configure chip in wrong way. ### Reply 27 by wiznetcannot, 2017-11-13 hello Eugeny i set my pc a fixed ip addr as 192.168.2.55 netmask 255.255.255.0 and gateway 192.168.2.1 AND i set my board ip addr as 192.168.2.32 netmask 255.255.255.0 … when i connect my pc with another pc with a cable, ping operation is ok, however i just cannot ping my board … It seems i cannot upload files now , so pity… thx ### Reply 28 by Eugeny, 2017-11-13 I do not remember exactly, never tried P2P connection, but there’s some rule to follow in this topology. Like setting gateway to 0.0.0.0 because it is not existent in this configuration. It may happen that W5500 tries to reach gateway, and gets stuck as gateway does not respond. You should be able to understand what is going on by looking into Wireshark if you install it on your PC. Most probably you will see that W5500 constantly sends ARP requests to gateway IP address. ### Reply 29 by wiznetcannot, 2017-11-13 yes ,you are right … my pc is always trying arp request to 192.168.2.1. i will have a try tommorrow and give you a reply … thx ### Reply 30 by Eugeny, 2017-11-13 I was talking about W5500 settings, not PC ones. PC’s network driver should be clever enough to understand that there’s no gateway out there, and continue working without gateway. But I am not sure about W5500 - it may get unavailable with incorrect gateway settings. ### Reply 31 by wiznetcannot, 2017-11-14 HI Eugency, when i try to set gateway to 0.0.0.0, it infos me novalid … it seems not work… ### Reply 32 by wiznetcannot, 2017-11-14 hello Eugency, step 1 , hardware reset ; step 2, set gateway, subnet mask,mac-address and ip; step 3 ,read common regs. AND do nothing ,but still cannot ping does it mean it must be hardware problem?? ### Reply 33 by Eugeny, 2017-11-14 Can you please dump the values of all registers in common register set so that we can check the configuration? ### Reply 34 by wiznetcannot, 2017-11-15 [ 7.237739] <5>.(5)[1:swapper/0]0x0 regvalue=0x0 [ 7.238443] <5>.(5)[1:swapper/0]0x100 regvalue=0xc0 [ 7.239184] <5>.(5)[1:swapper/0]0x200 regvalue=0xa8 [ 7.239920] <5>.(5)[1:swapper/0]0x300 regvalue=0x2 [ 7.240646] <5>.(5)[1:swapper/0]0x400 regvalue=0x1 [ 7.241371] <5>.(5)[1:swapper/0]0x500 regvalue=0xff [ 7.242107] <5>.(5)[1:swapper/0]0x600 regvalue=0xff [ 7.242843] <5>.(5)[1:swapper/0]0x700 regvalue=0xff [ 7.243579] <5>.(5)[1:swapper/0]0x800 regvalue=0x0 [ 7.244309] <5>.(5)[1:swapper/0]0x900 regvalue=0x0 [ 7.245033] <5>.(5)[1:swapper/0]0xa00 regvalue=0x8 [ 7.245758] <5>.(5)[1:swapper/0]0xb00 regvalue=0xdc [ 7.246498] <5>.(5)[1:swapper/0]0xc00 regvalue=0x91 [ 7.247269] <5>.(5)[1:swapper/0]0xd00 regvalue=0x97 [ 7.248005] <5>.(5)[1:swapper/0]0xe00 regvalue=0x98 [ 7.248741] <5>.(5)[1:swapper/0]0xf00 regvalue=0xc0 [ 7.249476] <5>.(5)[1:swapper/0]0x1000 regvalue=0xa8 [ 7.250222] <5>.(5)[1:swapper/0]0x1100 regvalue=0x2 [ 7.250957] <5>.(5)[1:swapper/0]0x1200 regvalue=0x20 [ 7.251704] <5>.(5)[1:swapper/0]0x1300 regvalue=0x0 [ 7.252438] <5>.(5)[1:swapper/0]0x1400 regvalue=0x0 [ 7.253174] <5>.(5)[1:swapper/0]0x1500 regvalue=0x0 [ 7.253915] <5>.(5)[1:swapper/0]0x1600 regvalue=0x0 [ 7.254651] <5>.(5)[1:swapper/0]0x1700 regvalue=0x0 [ 7.255388] <5>.(5)[1:swapper/0]0x1800 regvalue=0x0 [ 7.256123] <5>.(5)[1:swapper/0]0x1900 regvalue=0x7 [ 7.256858] <5>.(5)[1:swapper/0]0x1a00 regvalue=0xd0 [ 7.257648] <5>.(5)[1:swapper/0]0x1b00 regvalue=0x8 [ 7.258384] <5>.(5)[1:swapper/0]0x1c00 regvalue=0x28 [ 7.259131] <5>.(5)[1:swapper/0]0x1d00 regvalue=0x0 [ 7.259871] <5>.(5)[1:swapper/0]0x1e00 regvalue=0x0 [ 7.260606] <5>.(5)[1:swapper/0]0x1f00 regvalue=0x0 [ 7.261352] <5>.(5)[1:swapper/0]0x2000 regvalue=0x0 [ 7.262089] <5>.(5)[1:swapper/0]0x2100 regvalue=0x0 [ 7.262824] <5>.(5)[1:swapper/0]0x2200 regvalue=0x0 [ 7.263561] <5>.(5)[1:swapper/0]0x2300 regvalue=0x0 [ 7.264296] <5>.(5)[1:swapper/0]0x2400 regvalue=0x0 [ 7.265037] <5>.(5)[1:swapper/0]0x2500 regvalue=0x0 [ 7.265773] <5>.(5)[1:swapper/0]0x2600 regvalue=0xff [ 7.266520] <5>.(5)[1:swapper/0]0x2700 regvalue=0xff [ 7.267321] <5>.(5)[1:swapper/0]0x2800 regvalue=0x0 [ 7.268057] <5>.(5)[1:swapper/0]0x2900 regvalue=0x0 [ 7.268793] <5>.(5)[1:swapper/0]0x2a00 regvalue=0x0 [ 7.269527] <5>.(5)[1:swapper/0]0x2b00 regvalue=0x0 [ 7.270263] <5>.(5)[1:swapper/0]0x2c00 regvalue=0x0 [ 7.271001] <5>.(5)[1:swapper/0]0x2d00 regvalue=0x0 [ 7.271737] <5>.(5)[1:swapper/0]0x2e00 regvalue=0xbc [ 7.272484] <5>.(5)[1:swapper/0]0x2f00 regvalue=0x0 [ 7.273219] <5>.(5)[1:swapper/0]0x3000 regvalue=0x0 [ 7.273954] <5>.(5)[1:swapper/0]0x3100 regvalue=0x0 [ 7.274690] <5>.(5)[1:swapper/0]0x3200 regvalue=0x0 [ 7.275430] <5>.(5)[1:swapper/0]0x3300 regvalue=0x0 [ 7.276172] <5>.(5)[1:swapper/0]0x3400 regvalue=0x0 [ 7.276907] <5>.(5)[1:swapper/0]0x3500 regvalue=0x0 [ 7.277697] <5>.(5)[1:swapper/0]0x3600 regvalue=0x0 [ 7.278434] <5>.(5)[1:swapper/0]0x3700 regvalue=0x78 [ 7.279180] <5>.(5)[1:swapper/0]0x3800 regvalue=0x25 [ 7.279928] <5>.(5)[1:swapper/0]0x3900 regvalue=0x4 ### Reply 35 by Eugeny, 2017-11-15 Looks fine, the only issue I see that W5500 is thinking its PHY was not connected at the time you took the dump (LNK bit = 0). I would do the following: have board connected to your PC with Wireshark running on it, and see if W5500 sends any packets (it will sometimes) to ensure that it is just alive from the PC’s view. Probably the log you will see in Wireshark will help understand what is going on. ### Reply 36 by wiznetcannot, 2017-11-15 Hello Eugeny, step1, hardware reset, step2 ,set gateway, subnet mask,mac-address and ip, AND now, ping my board with pc is ok… so we think the board design is ok… AND next, I restore my linux driver , and do as followings: step1, adb shell ifconfig eth0 192.168.2.32; step2, ping 192.168.2.32 with my pc… and the ping operation failed ### Reply 37 by wiznetcannot, 2017-11-15 I want to know , if i set spi speed 100kHz, do you think it will fail ping operation?? ### Reply 38 by Eugeny, 2017-11-15 ![](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/48.png) wiznetcannot: > step1, adb shell ifconfig eth0 192.168.2.32; Setting own IP address is not enough, you also must set network mask, e.g. `ifconfig eth0 inet 192.168.2.32 netmask 255.255.255.0` ![](https://avatars.discourse-cdn.com/v4/letter/w/7bcc69/48.png) wiznetcannot: > if i set spi speed 100kHz, do you think it will fail ping operation?? As I remember there’s no minimal value for the SPI speed for W5x00, thus you can use 100 kHz, or even 100 Hz, and it should still work. --- Source: https://maker.wiznet.io/forum/12196