WIZnet Developer Forum

TCP send issues

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

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

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…

[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.

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.

  1. 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.
  2. 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).
  3. I send the command SEND and wait that the command is completed by checking that CR become clears.
  4. 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 ?

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.

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.


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?

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.

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.

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] unsigned int 0x0000 (Hex) 0x0000043C@Data
[38] unsigned int 0x0000 (Hex) 0x0000043D@Data
[39] unsigned int 0x0000 (Hex) 0x0000043E@Data

PTIMER: [40] unsigned int 0x0028 (Hex) 0x0000043F@Data

PMAGIC: [41] unsigned int 0x0000 (Hex) 0x00000440@Data

INTLEVEL: [42] unsigned int 0x0000 (Hex) 0x00000441@Data
[43] unsigned int 0x0000 (Hex) 0x00000442@Data

Reserved: [44] unsigned int 0x0000 (Hex) 0x00000443@Data
[45] unsigned int 0x0000 (Hex) 0x00000444@Data
[46] unsigned int 0x0000 (Hex) 0x00000445@Data
[47] unsigned int 0x0000 (Hex) 0x00000446@Data
[48] unsigned int 0x0000 (Hex) 0x00000447@Data
[49] unsigned int 0x0000 (Hex) 0x00000448@Data
[50] unsigned int 0x0000 (Hex) 0x00000449@Data

IR2: [51] unsigned int 0x0000 (Hex) 0x0000044A@Data

PHYSTATUS: [52] unsigned int 0x0000 (Hex) 0x0000044B@Data

IMR2: [53] unsigned int 0x0027 (Hex) 0x0000044C@Data

irq union Sn_IR_REG {…} 0x00000416@Data
all unsigned int 0 0x00000416@Data
bit struct Sn_IR_REG_BITS {…} 0x00000416@Data
CON unsigned int : 1 0 0x00000416@Data bit 0
DISCON unsigned int : 1 0 0x00000416@Data bit 1
RECV unsigned int : 1 0 0x00000416@Data bit 2
TIMEOUT unsigned int : 1 0 0x00000416@Data bit 3
SEND_OK unsigned int : 1 0 0x00000416@Data bit 4
PNEXT unsigned int : 1 0 0x00000416@Data bit 5
PFAIL unsigned int : 1 0 0x00000416@Data bit 6
PRECV unsigned int : 1 0 0x00000416@Data bit 7
rsvd unsigned int : 8 0 0x00000416@Data bit 8-15
socket unsigned int 0 0x00000451@Data
tmp unsigned int 0 0x0000044D@Data
tsz unsigned int 62 0x00000450@Data
TxRdRing unsigned int 0x0383 (Hex) 0x0000044F@Data
TxRdRing2 unsigned int 6553 0x0000044E@Data

Ok, thanks.

  1. for TCP mode set bit 5 of the MR, in other words write 0x20 into reg 0.
  2. 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?

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…


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.

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…

Can you make a dump of those registers?

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

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 0x0000 (Hex) 0x00000441@Data
[41] unsigned int 0x0000 (Hex) 0x00000442@Data

RX_WR
[42] unsigned int 0x0000 (Hex) 0x00000443@Data
[43] unsigned int 62 (Decimal) 0x00000444@Data

IMR
[44] unsigned int 0x001F (Hex) 0x00000445@Data

FRAG
[45] unsigned int 0x0040 (Hex) 0x00000446@Data
[46] unsigned int 0x0000 (Hex) 0x00000447@Data

Memory content :
[47] unsigned int 0x0000 (Hex) 0x00000448@Data
[48] unsigned int 0x0000 (Hex) 0x00000449@Data
[49] unsigned int 0x0000 (Hex) 0x0000044A@Data
[50] unsigned int 0x0000 (Hex) 0x0000044B@Data
[51] unsigned int 0x0000 (Hex) 0x0000044C@Data
[52] unsigned int 0x0000 (Hex) 0x0000044D@Data
[53] unsigned int 0x0000 (Hex) 0x0000044E@Data
[54] unsigned int 0x0000 (Hex) 0x0000044F@Data
[55] unsigned int 0x0000 (Hex) 0x00000450@Data
[56] unsigned int 0x0000 (Hex) 0x00000451@Data
[57] unsigned int 0x0000 (Hex) 0x00000452@Data
[58] unsigned int 0x0000 (Hex) 0x00000453@Data
[59] unsigned int 0x0000 (Hex) 0x00000454@Data
[60] unsigned int 0x0000 (Hex) 0x00000455@Data
[61] unsigned int 0x0000 (Hex) 0x00000456@Data
[62] unsigned int 0x0000 (Hex) 0x00000457@Data
[63] unsigned int 0x0000 (Hex) 0x00000458@Data
[64] unsigned int 0x0000 (Hex) 0x00000459@Data
[65] unsigned int 0x0000 (Hex) 0x0000045A@Data
[66] unsigned int 0x0000 (Hex) 0x0000045B@Data
[67] unsigned int 0x0000 (Hex) 0x0000045C@Data
[68] unsigned int 0x0000 (Hex) 0x0000045D@Data
[69] unsigned int 0x0000 (Hex) 0x0000045E@Data
[70] unsigned int 0x0000 (Hex) 0x0000045F@Data
[71] unsigned int 0x0000 (Hex) 0x00000460@Data
[72] unsigned int 0x0000 (Hex) 0x00000461@Data
[73] unsigned int 0x0000 (Hex) 0x00000462@Data
[74] unsigned int 0x0000 (Hex) 0x00000463@Data
[75] unsigned int 0x0000 (Hex) 0x00000464@Data
[76] unsigned int 0x0000 (Hex) 0x00000465@Data
[77] unsigned int 0x0000 (Hex) 0x00000466@Data
[78] unsigned int 0x0000 (Hex) 0x00000467@Data
[79] unsigned int 0x0000 (Hex) 0x00000468@Data
[80] unsigned int 0x0000 (Hex) 0x00000469@Data
[81] unsigned int 0x0000 (Hex) 0x0000046A@Data
[82] unsigned int 0x0000 (Hex) 0x0000046B@Data
[83] unsigned int 0x0000 (Hex) 0x0000046C@Data
[84] unsigned int 0x0000 (Hex) 0x0000046D@Data
[85] unsigned int 0x0000 (Hex) 0x0000046E@Data
[86] unsigned int 0x0000 (Hex) 0x0000046F@Data
[87] unsigned int 0x0000 (Hex) 0x00000470@Data
[88] unsigned int 0x0000 (Hex) 0x00000471@Data
[89] unsigned int 0x0000 (Hex) 0x00000472@Data
[90] unsigned int 0x0000 (Hex) 0x00000473@Data
[91] unsigned int 0x0000 (Hex) 0x00000474@Data
[92] unsigned int 0x0000 (Hex) 0x00000475@Data
[93] unsigned int 0x0000 (Hex) 0x00000476@Data
[94] unsigned int 0x0000 (Hex) 0x00000477@Data
[95] unsigned int 0x0000 (Hex) 0x00000478@Data
[96] unsigned int 0x0000 (Hex) 0x00000479@Data
[97] unsigned int 0x0000 (Hex) 0x0000047A@Data
[98] unsigned int 0x0000 (Hex) 0x0000047B@Data
[99] unsigned int 0x0000 (Hex) 0x0000047C@Data

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 :slight_smile: 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?

Yes.
Yes it is listening to 41681. It is mentioned in wireshark.

Copyright © 2017 WIZnet Co., Ltd. All Rights Reserved.