TCP send issues

Question

So I have looked at the example code and I am able to receive packets correctly and the data that is sent to the W5200 is correct. However, when I attempt to send the data, I notice that the data is being sent is not correct? So just to clarify a few things. Using socket 0 with a size of 2K. The transmit pointer when the socket is first initialized reads 0. However prior to the first transmission, that pointer now reads something other than 0. Is this normal? I take the pointer (0x2B3C), mask it with 0x7FF and this then gets added to the TX base which for socket 0 is 0x8000. This is the address(0x833C) that is now sent in the command to transfer the data. So in my case, I am writing 7 bytes. I then send the send command I than add 7 to the pointer and update it (0x2B43). However the data that is sent does not appear at the other end, I get approximately seven bytes, but not the data I sent. What am I missing here? Regards, Bill

lawrence · Answer

Hello, Bill There is the way to check if the send data is the same with the data in Tx memory with Sn_TX_RD and Sn_TX_WR. When user write a data in Tx, the write pointer increases and user can check it with Sn_TX_WR. When user send the data written in Tx, the send pointer increases until the write pointer and user can check it with Sn_TX_RD. After ‘SEND’ is done, if it is all right, Sn_TX_WR and Sn_TX_RD will have the same pointer value. I recommend you to check both register and compare. If a part of the data sent, it will make a difference between both register. Thank you, lawrence

cedric83 · Answer

I have the exact same problem here… Data is send correctly to W5200 but impossible to send a reply. SEND_OK signal is never set after I call the command SEND… I have the same socket configuration… Bill, did you make any progress on your problem ? UPDATE As recommended, after executing the SEND command, my pointer RD and WR match, but the IRQ is never set and the data is not transmitted on the network…

Eugeny · Answer

[quote=“wbasser”]I take the pointer (0x2B3C), mask it with 0x7FF and this then gets added to the TX base which for socket 0 is 0x8000. This is the address(0x833C) that is now sent in the command to transfer the data. So in my case, I am writing 7 bytes. I then send the send command I than add 7 to the pointer and update it (0x2B43).[/quote] Cedric, That seems to be wrong. You calculate absolute pointer to the data in the chip using WR pointer, then write those bytes you need to send sequentially to the TX buffer using calculated pointer, then increase WR pointer and only then issue SEND command. The reason is that increasing WR pointer you create difference between RD and WR pointers which identify how many bytes to send. If you do not increase pointer (WR=RD before you issue SEND) nothing should be sent.

cedric83 · Answer

Hi Eugeny, First of all thanks for your help. I was doing what you said but with no luck. I have WR and RD pointers are different before sending the command SEND… and actually remain different after calling SEND, which confirms that I never get the irq SEND_OK… Here is a practical case: I use socket 0, socket size 2K. I perform a data reception (62 bytes) from Computer to W5200 using TCP protocol (port 40000). No problem. I get the expected data in the RX buffer. In response, I want to send some data (62 bytes) to Computer. I compute absolute pointer (0x840C) by using WR pointer (0x7C4A). I write the data to the buffer at the absolute pointer address and using 62 bytes as length. For troubleshooting, after that I read my RD pointer (0x7C0C). I send the command SEND and wait that the command is completed by checking that CR become clears. I loop until SEND_OK is set but it never happens. I am monitoring the TCP on wireshark and confirm that nothing is sent. However I manage to get a ping response from W5200. Thoughts ?

Eugeny · Answer

When it happens please perform dump of all the registers (is it possible?) - all main registers and all socket registers. What specifically to check (just first coming to my mind) MAC address you use? And the one which is in effect when it happens? source and remote port numbers when it happens? In general please ensure that during all of your operations no significant registers are being corrupt.

cedric83 · Answer

I use a point to point connection with no router in between both computer and W5200 have static addresses. I have not change the default MAC address of the W5200, should I ? The picture attached show the communication from the computer to W5200. There is no reply back to the computer. 1855×1056 165 KB

Eugeny · Answer

So there’re two directly connected devices: Dell computer with MAC address 18:03:73:4b:b2:52 and IP address 192.168.0.101, port 41452 W5200-based device, with MAC address 00:00:00:00:00:00 and IP address 192.168.0.2, port 40000 Correct? Why W5200 device is having MAC address composed of all 0s? Which source and destination ports does W5200 device use?

cedric83 · Answer

Yes, this is correct. I have changed the address MAC of the W5200 to be non-zero (00:08:dc:01:02:03). Now it shows Wiznet_01:02:03. But same problem persists. The destination address used by the W5200 is 192.168.0.101 and gateway 192.168.0.1. The same gateway address is specified on the computer.

cedric83 · Answer

I have noticed that the time when I get the last message (sa shown in screen capture) correspond to the RTR time value – which means the W5200 timeout right ? To me, it means that the W5200 gets the data but don’t interpret it as a correct TCP frame.

cedric83 · Answer

Hi Eugeny, I have dumped the data of the common register as you suggested. I have dumped from address 0x0000 to 0x0036. dump unsigned int[54] 0x00000417@Data (Hex) 0x00000417@Data MR: [0] unsigned int 0x0000 (Hex) 0x00000417@Data GAR: [1] unsigned int 0x00C0 (Hex) 0x00000418@Data [2] unsigned int 0x00A8 (Hex) 0x00000419@Data [3] unsigned int 0x0000 (Hex) 0x0000041A@Data [4] unsigned int 0x0001 (Hex) 0x0000041B@Data SUBR: [5] unsigned int 0x00FF (Hex) 0x0000041C@Data [6] unsigned int 0x00FF (Hex) 0x0000041D@Data [7] unsigned int 0x00FF (Hex) 0x0000041E@Data [8] unsigned int 0x0000 (Hex) 0x0000041F@Data SHAR: [9] unsigned int 0x0000 (Hex) 0x00000420@Data [10] unsigned int 0x0008 (Hex) 0x00000421@Data [11] unsigned int 0x00DC (Hex) 0x00000422@Data [12] unsigned int 0x0001 (Hex) 0x00000423@Data [13] unsigned int 0x0002 (Hex) 0x00000424@Data [14] unsigned int 0x0003 (Hex) 0x00000425@Data SIPR: [15] unsigned int 0x00C0 (Hex) 0x00000426@Data [16] unsigned int 0x00A8 (Hex) 0x00000427@Data [17] unsigned int 0x0000 (Hex) 0x00000428@Data [18] unsigned int 0x0002 (Hex) 0x00000429@Data IR: [19] unsigned int 0x0000 (Hex) 0x0000042A@Data IMR: [20] unsigned int 0x0000 (Hex) 0x0000042B@Data RTR: [21] unsigned int 0x0000 (Hex) 0x0000042C@Data [22] unsigned int 0x0001 (Hex) 0x0000042D@Data RCR: [23] unsigned int 0x0000 (Hex) 0x0000042E@Data [24] unsigned int 0x000A (Hex) 0x0000042F@Data [25] unsigned int 0x000A (Hex) 0x00000430@Data [26] unsigned int 0x0000 (Hex) 0x00000431@Data PATR: [27] unsigned int 0x0000 (Hex) 0x00000432@Data [28] unsigned int 0x0000 (Hex) 0x00000433@Data PPPALGO: [29] unsigned int 0x0000 (Hex) 0x00000434@Data [30] unsigned int 0x0000 (Hex) 0x00000435@Data VERSIONR: [31] unsigned int 0x0003 (Hex) 0x00000436@Data Reserved: [32] unsigned int 0x0000 (Hex) 0x00000437@Data [33] unsigned int 0x0000 (Hex) 0x00000438@Data [34] unsigned int 0x0000 (Hex) 0x00000439@Data [35] unsigned int 0x0000 (Hex) 0x0000043A@Data [36] unsigned int 0x0000 (Hex) 0x0000043B@Data [37]…

Eugeny · Answer

Ok, thanks. for TCP mode set bit 5 of the MR, in other words write 0x20 into reg 0. RTR seems to be too small = 1? So as RCR? Why not to use default - at least for troubleshooting? Do you have socket registers’ dump? Do you use socket 0?

cedric83 · Answer

I added “no delay ack” after posting my last message but it seems like the TCP protocol does not like it… See in the Info, RST and ACK are set whereas previously (with timeout) SYN and ACK are set. In my application, it results in that my linux function connect() fails on the Dell side (client). I will dump socket 0 also… 1667×933 152 KB

Eugeny · Answer

cedric83: I added “no delay ack” after posting my last message but it seems like the TCP protocol does not like it… No problem, leave it as it was. Just take note to try it in the future again. I recall I was recommended it to increase speed of communication.

cedric83 · Answer

I have checked out the socket 0 register, and everything look as expected. DHAR matches the MAC address of the computer and DPIR and DPORT also match the destination IP and Port… RX WR pointer are correct too and are within the memory range of the socket 0… I am kind of confused what to look for next…

Eugeny · Answer

Can you make a dump of those registers?

cedric83 · Answer

… Will do… on Monday Have a good week-end, thanks for your help.

cedric83 · Answer

MR: [0] unsigned int 0x0001 (Hex) 0x00000419@Data CR: [1] unsigned int 0x0000 (Hex) 0x0000041A@Data IR: [2] unsigned int 0x0000 (Hex) 0x0000041B@Data SR: [3] unsigned int 0x0017 (Hex) 0x0000041C@Data PORT: [4] unsigned int 0x009C (Hex) 0x0000041D@Data [5] unsigned int 0x0040 (Hex) 0x0000041E@Data DHAR [6] unsigned int 0x0018 (Hex) 0x0000041F@Data [7] unsigned int 0x0003 (Hex) 0x00000420@Data [8] unsigned int 0x0073 (Hex) 0x00000421@Data [9] unsigned int 0x004B (Hex) 0x00000422@Data [10] unsigned int 0x00B2 (Hex) 0x00000423@Data [11] unsigned int 0x0052 (Hex) 0x00000424@Data DIPR [12] unsigned int 0x00C0 (Hex) 0x00000425@Data [13] unsigned int 0x00A8 (Hex) 0x00000426@Data [14] unsigned int 0x0000 (Hex) 0x00000427@Data [15] unsigned int 0x0065 (Hex) 0x00000428@Data DPORT [16] unsigned int 0x00A2 (Hex) 0x00000429@Data [17] unsigned int 0x00D1 (Hex) 0x0000042A@Data MSS [18] unsigned int 0x0005 (Hex) 0x0000042B@Data [19] unsigned int 0x00B4 (Hex) 0x0000042C@Data PROTO [20] unsigned int 0x0000 (Hex) 0x0000042D@Data TOS [21] unsigned int 0x0000 (Hex) 0x0000042E@Data TTL [22] unsigned int 0x0080 (Hex) 0x0000042F@Data [23] unsigned int 0x0000 (Hex) 0x00000430@Data [24] unsigned int 0x0000 (Hex) 0x00000431@Data [25] unsigned int 0x0000 (Hex) 0x00000432@Data [26] unsigned int 0x0000 (Hex) 0x00000433@Data [27] unsigned int 0x0000 (Hex) 0x00000434@Data [28] unsigned int 0x0000 (Hex) 0x00000435@Data [29] unsigned int 0x0000 (Hex) 0x00000436@Data RXMEM_SIZE [30] unsigned int 0x0002 (Hex) 0x00000437@Data TXMEM_SIZE [31] unsigned int 0x0002 (Hex) 0x00000438@Data TX_FSR [32] unsigned int 0x0008 (Hex) 0x00000439@Data [33] unsigned int 0x0000 (Hex) 0x0000043A@Data TX_RD [34] unsigned int 0x0052 (Hex) 0x0000043B@Data [35] unsigned int 0x00C9 (Hex) 0x0000043C@Data TX_WR [36] unsigned int 0x0052 (Hex) 0x0000043D@Data [37] unsigned int 0x00C9 (Hex) 0x0000043E@Data RX_RSR [38] unsigned int 0x0000 (Hex) 0x0000043F@Data [39] unsigned int 62 (Decimal) 0x00000440@Data RX_RD [40] unsigned int…

Eugeny · Answer

Cedric, sorry it seems I made a mistake last time - set bit 5 (ND/MC) in socket mode register, and of course not in master mode register Thus it will look like 21, not 01. IR=0 I assume you cleared all bits raised before (receive and connect at least). SR=17 means TCP is in connected state. W5200’s port is 9C40. DHAR and DIPR point to the Dell PC. Dell’s port it is listening at is A2D1 - is it correct? RX/TX mem sizes = default. Thus question to you - is your Dell PC listening @ the port 0xA2D1 (41681) to receive data from W5200?

cedric83 · Answer

I assume you cleared all bits raised before (receive and connect at least) Yes. Yes it is listening to 41681. It is mentioned in wireshark.

cedric83 · Answer

Also I manage to ping the chip with no problem (~0.28s response time), so I assume my connection is setup correctly for outcome/income communications.

cedric83 · Answer

OK found it ! Argh ! … The problem was in my code… The command send was incorrectly masked !! I made a typo, where the command was masked with 0xf instead of 0xff (I am using Uint16 format) … Alright… it works now… Well since this problem I think I know much more about this device ! Thanks Eugeny for your help, have a good one.

Eugeny · Answer

cedric83: OK found it ! Great, thank you for letting know. Get back if you will have further questions.