RTT0.4在LPC17xx下也有TCP传输问题,同时收发时,发送线程挂起在邮箱或信号量的等待中
finsh正常,其他进程都正常,主要问题是邮箱满了后内核线程调度器失效。单独收发都OK,但是双工通信时,发送就由接收驱动了,也就是有接收到数据包才调用发送线程。
我单步跟踪调试,发现邮箱满了后,挂起的进程不再调度。但是系统仍然可以正常进入IDLE进程和其他与TCP/IP协议栈不相关的进程。
采用信号量也有同样的问题。
采样BSP中LPC17XX未作任何修改的源程序编译NETIO进行测试,程序经常一遍都运行不完。而且也是每次都是上次接收完成后,后面的发送过程无法完成。
估计内核调度模块可能哪里有漏洞,或者LWIP的移植有问题。
斑竹可以在LPC17XX的板子上试试NETIO,多运行几次,问题是必现的。 LPC17XX的驱动原来有个BUG,就是连续快速发送多个包,这样只会产生一个中断,因此多个包只释放一次信号量。
现已改用事件来解决这个问题。
SVN中已修正,请与SVN同步一下再测试。 版主这么快回复,赞!
我是从网站下的RTT0.4 RC1的代码,这个有问题么?
还没有用过SVN,试试看,呵呵。
再次感谢! 刚检查了,RC1中还未修正。 谢谢!
正在CHECKOUT中,保险起见把整个工程都弄下来,呵呵。 建议对比SVN与RC1的驱动,然后手动合并到你的项目中去。
而不要直接覆盖,不然你要是做过修改的话,可能会引起些其它问题。 谢谢提醒! 测试结果报告:
1.运行NETIO 5次,没有再挂掉。1K 报文速率为5KBPS左右,2K为1MBPS,2K以上均为20KBPS;
2.TCP服务器仍然会出现之前的情况,独立收发OK,但是收发同时进行时过一段时间发送进程就不再被系统调度,这时邮箱状态是满的。
感觉是收发同时进行时内核调度会局部失效,但是其他与TCPIP无关的进程却不受影响。
而且接受进程也正常运行,与其他模块的通信也正常,就是发送不行。
发送的进程接受邮件周期为8ms,每次发送2304BYTEs。
aozima帮忙想想后面该如何定位? 在发送进程内部调用系统tick函数,发现发送过程没有障碍,就是阻塞在邮箱等待过程中的。
而且这时候邮箱是满的,系统即使调度idle进程也不调度这个发送进程。。。
而且奇怪的是接收到一个报文后可以使发送进程得到调度,但也就运行几次就停了,然后再接受到一个包,又能发几个出去,感觉是被接受进程驱动。 进一步测试结果:
在finsh中用list_sem()发现发送的进程是阻塞在一个叫sem4的信号量上,但是这个信号量并不是我定义的。
于是通过在程序中嵌入list_sem()函数进行进行跟踪,最后定位到lwip_accept()--->netconn_accept()--->sys_arch_mbox_fetch()--->rt_mb_recv()函数上。
当TCP客户机没有发起连接的时候,这个信号量是没有的,accept之后就出现了。
此外,每次断开连接后,这个信号量的ID都不一样,按照sem4,sem5,sem6的规律编号递增。
一旦有接收到报文,一段时间后发送进程就阻塞在这个莫名其妙的信号量上了。
麻烦版主帮忙看看。
我的程序结构就是依照example里的tcpserver,在accept之后建立两个进程,一个发送一个接受,和其他的模块进行通信。我们公司信息安全原因不能贴上代码。。。自己手敲有点太多了,这样应该不妨碍问题分析吧? 问题解决!
采用的8041PHY没有配置为全双工模式。。。 回复【10楼】aureoleday
问题解决!
采用的8041phy没有配置为全双工模式。。。
-----------------------------------------------------------------------
实际产品中,一般都要加上PHY中断,用于处理线路连接状态(有通断需要通知上层)。
以及速率和双工模式的改变。
页:
[1]