WIZnet Developer Forum

Chip status after "TCP Send Error"


I get the TCP Send Error message every now and then and according to the Wireshark capture, I can see that some packets are lost and the retransmitted by the chip correctly, but in some cases (probably a buffer issue?) it gives me this TCP Send Error message. I am using 921600@8N1 with hardware flow control (RTS and CTS are connected).

I am trying to diagnose/recover from this error as it only happens on a congested network. Is there a way to recover without disconnecting and attempting a connection again? Right now, the chip seems to send the RST signal a second or two after this happens which of course terminates the stream.


Sorry, the firmware version on chip is

Hi, KS

First al all, I apologize for late reply.

Let me ask some questions.

  1. When you got a ‘TCP Send Error’ message, is it right connected state?(After connect)
    (Usually the error message happened during connecting)

  2. When you did a test, how much the environment was ‘congested’ ?


Hi Tom,

Thanks for your reply. Here are the answers:

  1. The error is after “connected” state. Usually when I am trying to send about 100kB of data. I can get the error at any stage, primarily because the ACKs from the remote system might be a bit delayed as it is also on the Wi-Fi network. Also, I can see that most of the times the problem happens, the packet sent by WizFi chip is either lost or not ACKed by the remote system, and it retransmits, but sometimes, it has gone through far enough (has sent a few packets in spite of them not being ACKed and can’t re transmit when the remote sends an ACK for a much older packet). It usually sends a [TCP Send Error] in that case.

  2. The network I am testing on has about 30 nodes on it most of them on LAN with a couple of servers. The Wireless Access point on this network (to which the WizFi chip connects to) has about 7-10 further devices on it. Traffic is intermittent, but the error rate (“TCP Send Error”) drops considerably when most of the nodes on the network are off.

Hope this helps.

Thanks again,

Hi, KS !

There is a command that extends a TCP Send Error Timeout.
As you said, the error message happens when you didn’t get an ACK message in time.
So, if you extend timeout, i think it can be better.
You can utilize it. (http://wizwiki.net/wiki/doku.php?id=products:wizfi250:wizfi250pg:start#at_fsock)
Also, you can automatically reset a device using this command.

Before you use this command, you should upgrade a firmware version.

Thanks, :slight_smile:

Hi Tom,

Thanks for your reply. I tried working on the firmware and have
tried using the FSOCK option to extend the timeout, and even disable it (I
read it on the forum that setting it to 0 => AT+FSOCK=1,0) but that didn’t
help me much either. Are there other options in the AT+FSOCK which could be
useful? The documentation does not give the details of all the options -
only 1,6 and 8. Resetting the device does sound interesting however. I can
try that too.

Thanks again.

Hi KS !

I thought you did already though, have you tried ‘AT+FSOCK=1,20000’ ?
Also, I suggest you to reduce data packet size, if it is possible.

As you asked, I’ll find the other option.:slight_smile:


Hi Tom,

Thanks! I will give that a go as well. Regarding the packet size - I am
afraid I did try that too. I was sending it in chunks of 1024 bytes with a
10ms delay between packets. I had to go down to packet size of 256 with a
delay of 20 ms between packets before I saw any improvement. Or if I ran
with a lower baud rate of 230400 with packet size of 1024 with no delay.
I must stress, that I don’t think the chip is doing anything wrong and when
I have a couple of nodes everything works very well indeed. There are many
variables in the whole picture - the router and it’s ability to handle
traffic, the remote node (a mobile phone) etc.

I will try the delay of 20000. Thanks again for your help.


Hi KS!!:slight_smile:

I am glad to hear that !!

If you have a trouble, plz let me know!

I’ll try to help you.


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