RT-Thread-packages / wiznet

WIZnet TCP/IP chips (such as W5500/W5100..) SAL framework implement.
Apache License 2.0
49 stars 35 forks source link

执行Ping命令的程序跑飞 #59

Open lenxvp opened 3 years ago

lenxvp commented 3 years ago

我在配置好wiznet组件后,使用命令行测试ping命令时发现ping命令ping完一次就卡住,命令行也无响应,debug后发现报NMI_Handle Snipaste_2021-06-10_16-11-45.png 研究下报错的地方发现是wiz_do_event_changes中的sock没有正常初始化 image.png 导致后续rt_wqueue_wakeup调用的时候程序跑飞 我在所有调用了wiz_do_event_changes添加了调试信息,输出如下: image.png 大概可以判断,wiz_do_event_changes被调用之前socket被关闭了,sock变量也被置零,在调用wiz_do_event_changes之前的wiz_recv_notice_cb函数里,有个释放信号量的地方: image.png rt在执行rt_sem_release的时候会调用rt_schedule重新进行进程调度,而我的shell进程优先级比wiznet接收进程的优先级高: image.png 这导致shell执行的ping命令会抢占,而ping命令执行后会有wiz_closesocket关闭socket,执行完后再回到wiznet的接收线程里执行wiz_do_event_changes就报错,wiz_do_event_changes没有预防socket被关闭的操作,也就容易导致程序跑飞 我参考AT_Socket的方法,在wiz_closesocket加以延时: image.png 让wiz_do_event_changes在socket没被关闭前执行完,再执行ping命令就不报错了,算是简单解决了这个问题,但总感觉指标不治本

这个问题应该只会在shell进程优先级或者其他会执行closesocket的进程优先级大于wiz接收进程优先级的时候发生

zxldsg commented 3 years ago

我这边尝试使用这个出现的是引脚中断回调没有被调用,导致一直接收不到recv的事件,有什么办法解决吗,你们的中断回调在send之后有回调吗