我们从2016年开始零星使用395Q，当时是D版，做服务器时UDP丢包率超过50%(连发5个SNTP包)，网络端不定期失联(SPI端没问题)，大约7天左右会出一次，断电重启才能恢复，基本没法用，反应给贵司后回应可能2端数据处理冲突，正在想办法解决。

2018年又捡起来试验，目前版本F版，做UDP服务器时丢包率大约还有15%，有所改善，凑合能用，期间做了个维修用的设备，MACRAW方式LLC协议只发不收，现场24小时运行3个多月来挺好；

2019年继续测试，这次同时使用socket 0和socket 3.
socket 3使用UDP协议客户端发送SNTP包获取时间，芯片硬复位后第一个发送的包必定丢失，返回超时，抓包软件什么都看不到，后面正常，但是每次收发后都会多一个空中断，就是全局中断0x80套接字中断0x00；
socket 0使用TCP长连接给服务器提供数据，只发现每次收发有空中断。
测试中发现网络端仍然有失联现象，发作时间最短10小时，最长15天，发作后收不到任何东西，恢复方法：1.断电重启 2.RESET脚复位 3.拔一下网线

以上都是实际应用中积累的记录，不是特意建立的试验环境。

国产通用协议栈目前只找到贵司有生产，CH395比较适合我们小数据量使用，希望能完善发现的问题。
贴一些调试期间的状态数据，其中G是全局中断寄存器，S是套接字中断寄存器，S0/S1是套接字状态寄存器。

CH395 Hardware Version = 46
IP = 192.168.1.177
IP Gateway = 192.168.1.1
IP Mask = 255.255.255.0
MAC = 84.C2.E4.F8.34.C1
G=80,S=41,TCP ready, S0=00, S1=00
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 18
TCP send len = 10
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 18
TCP send len = 10
G=10,S=01,G=10,S=00,G=10,S=02,G=80,S=03,G=80,S=04,SNTP receive len = 48G=80,S=00,

收到您的反馈，我们已经安排人员在测试

您好，感谢对问题的耐心分享，帖子中关于芯片可靠性问题，之前并没有客户遇到过，还在复现分析中。

关于芯片复位后，第一包数据无法发送成功问题，应该是PHY复位后，重新初始化没有来得及建立连接造成；

空中断是指“SEND_BUF_FREE”? TCP 发送成功后正常会产生“SEND_BUF_FREE”和SEND_OK”中断。

详细技术问题可否电话沟通下，我的电话025-89692395

客户您好，首先感谢您的反馈。根据您今年运用CH395的场景发现的问题，我将其分析为这四个问题：

1，用SOCKET 3发送sntp包获取时间，第一个sntp请求包必丢;

2，在1中的使用环境下，每次收发会报一个空中断；

3，用SOCKET 0做TCP客户端时，也会有空中断产生；

4，连续使用10小时到15天的时间长度内，CH395会不定时死机；

  针对这几个问题，我使用CH395 socket 3走UDP协议定时一秒一包向国家授时中心服务器发送NTP请求包，并解析回复，以此希望复现出您提出的问题。时间有限我复现出您提出的前三个问题。我们会检查CH395固件并最终解决这些问题。对于第一个必丢包的问题，您可以运用CH395的如下功能：每发出一个包，且成功发送，CH395都会报一个“SINT_STAT_SEND_OK”的SOCKET中断，中断值为0x10，您的sntp运用中第一个必丢的UDP包发送后不会产生这个中断，当前运用时，如果您对UDP的发送成功率有要求，建议您写一个检测“SINT_STAT_SEND_OK”中断的重发机制；针对第二个和第三个问题，确实有值为0x80的全局中断产生，这个值的中断属于误报，请忽视这个值的中断。您提出的第四个问题我们还在测试中。

  希望我的回复对您有帮助。欢迎您继续在此帖中跟进或者直接联系我：邮箱：lq@wch.cn，电话：025-52638373.

换个浏览器就可以回复了。。。。。

CH395的主要问题是2个，第一是网络侧会死机，收不到任何数据，刚开始以为地址之类的数据被破坏，专门写了一段程序

验证，结果一切正常，后发现插拔一次网线也可以恢复到正常状态，期间发送是好的；目前在要求不高的地方做客户端，

加入软件看门狗，若干时间内收不到回答就RESET脚硬复位，重新初始化，这样勉强能够使用。

第二个问题是UDP丢包，CH395做SNTP服务器端，和电脑点对点方式连接，电脑一次连发5个请求包，大约有15%的丢包率。

以上2个问题影响使用，其他作为用户可以忽略，检查固件用的。

第一：

    网络侧死机，先检查硬件网口灯状态是否正常，其次检查CH395能否被ping通，接下来再检查CH395的中断引脚电平状态；如果只是单纯的收不到数据，那么请确认是否是由于中断信号丢失引起的，CH395的中断引脚如果用作单片机的外部中断，那么请将中断触发方式设置为低电平触发，不要设置为边沿触发

第二：

    关于UDP丢包的问题，丢包主要受外部网络环境影响，和通信双方之间的网络构成有关

上星期五通电样机，今早发现Socket 3的UDP失联(SNTP服务器端)，Socket 0的TCP短连接正常，长连接未试(104服务器端)，Socket 2的TCP短连接正常(Telnet 服务器端)，Ping正常。

显然是CH395的固件BUG造成的，如果有内部调试手段的话可以来我这里检测，我也是南京的。

针对您目前的情况，建议您留一下您的公司信息和联系人方式，我们会安排专人和您对接，您反应的情况可能与您的网络测试环境也有关系，如果有必要，我们会派人去现场调试检测。您也可以直接联系我们技术人员：电话025-52638370

用户信息里有

又发现新问题，TCP服务端大部分时间有重发包，偶尔一段时间正常，翻了翻论坛有人早就发生同样问题：

http://wch.cn/bbs/thread-67676-1.html

当时回复把原因归咎于网络延时，但是仔细看看重发包没到200ms就发出来了，我这里都是在100ms-150ms之间。

还有这一篇：

http://wch.cn/bbs/thread-67836-1.html

也许就是我在1楼写的空中断的来源吧。

104_20191008.zip

认真点好么

再写一点，CH395网络侧崩溃是逐步发生的，首先UDP失去响应，若干时间后ping应答逐渐困难，直到无任何响应，此时tcp也无法连通。

如果这时拔掉网线过1分钟再插上，基本可以恢复正常。

期间指示灯和SPI端一直正常

您好，关于您反馈的TCP重传的问题，是TCP协议栈为了保证数据可靠性的机制，重传不会影响正常传输，不会造成重复接收。

空中断是由于CH395正在处理内部中断事物中，还没有完全处理完，所以调用读取中断命令会显示无中断，待内部处理完成后，INT引脚会恢复正常

使用贵公司ch395q，做热插拔测试和服务器通信，拔网线初始化后刚开始一切正常，过几分钟再发数据包就是掉线，然后再初始化正常了

395Q网络侧死机的问题有进展了吗？我们这边也碰到了。。。而且是几十个小时就会出现。目前实验样本还比较少，不能可靠复现，但短期内已经出现2次，没有一直通信，第一次大概隔30多个小时后通信，第二次大概隔60多个小时后通信。PING不通，UDP无法通信。

这芯片问题这么多？