logo

关于CH395丢包,网络侧死机等等那些事。。。

我们从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



邮箱:wxf@wch.cn 电话: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


只有登录才能回复,可以选择微信和github账号登录