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]