Posted inMicriμm
uC/TCP-IP分析
不管在使用socket的任何时候出现了以下任何一个严重的错误代码，socket必须立即closed()。 NET_SOCK_ERR_NOT_USED NET_SOCK_ERR_INVALID_FAMILY NET_SOCK_ERR_INVALID_PROTOCOL NET_SOCK_ERR_INVALID_TYPE NET_SOCK_ERR_INVALID_STATE NET_SOCK_ERR_FAULT
LPC2366 uC/OS & uC/TCP-IP
最近调试LPC2366+uC/OS+uC/TCPIP，因为是从别人那里拿来的的代码。烧写进去可以ping通。 但是连接远端服务器后不能连续发送，必须要等一段时间（100ms）的延时在发，不然跑着跑着程序会挂掉。 于是埋头google、看源码、调试参数、查文档。依然不行，只能解决到延时10ms发送出错后可以恢复。但是2366发送网络报文依然很慢。 折腾了1个星期。 今天终于试了最后一招（其实还有最最后一招），我们的代码是用git管理的。 git reset --hard OLD_VERSION 测试通过。 心态啊、心态。。。 PS： 最最后一招就是我去PORT Micriμm的2378的TCPIP工程。 最最最后一招就是买ZLG的协议栈。 优秀的开发风格和项目管理是做好项目的第一步。
Posted in一日一记
uC/TCP-IP NetSock_Conn返回超时
由于项目要求需要使用uC/TCP-IP做一个TCP Client端连接服务器。 出现了以下问题，烧写完程序后可以连接服务器，但是MCU复位后执行到NetSock_Conn会返回超时。 交叉编译了tcpdump，查看网络信息后发现出现超时的时候3次握手不完整。 使用netstat -a发现握手截至在FIN_WAIT1。当系统终止掉这次握手或者复位后，MCU总是可以连接到服务器，但是重连总是失败，错误码为超时。 google了基本没有人提到这个错误。初步结论可能是配置有误。但是增加了任务堆栈、调整任务优先级也没有效果。 之前有做过RM9200，于是打开代码发现都是使用的Server端。没有Client端。没办法，分别找了我们使用的MCU和RM9200的官方代码。终于在RM9200的code里面的Conn之前发现这样一条命令： [crayon-68014f9613086523059498/] 看名字就知道是设置连接超时，grep TTCP_CFG_MAX_CONN_TIMEOUT_MS发现为30000。依葫芦画瓢，问题解决。 原因就是系统默认的超时时间太短造成的。