春节测试Wiznet模块发现的问题，请RTT官方确认

发布于 2020-02-10 17:51:07 浏览：2757 订阅该版

* 本帖最后由 Spunky 于 2020-2-10 17:52 编辑 *

春节闲来无事试用了下RTT官方发布的Wiznet软件包，将测试情况列出来：
一、使能DHCP功能后会死机
1. 现象：
使用DHCP功能后，系统在运行接近2小时（准确说是7140秒）就会出现断言，打桩发现是spi1总线（W5500使用SPI1）的互斥量在中断中被调用（soft_timer是开启的）。
![mutex.png](/uploads/202002/10/165213h89slkm8c8mkaat8.png)
2.原因
这个现象非常有规律，就是运行接近2小时发生，找到DHCP的续约租期时间默认的就是7200秒，而查找代码发现名字为"wiz_lsd"的定时器使用的是硬件模式，而wiz_dhcp_restart（）使用SPI总线就是在中断中使用的。
![dhcp1.png](/uploads/202002/10/165107fme7hp0ie7lclcn0.png)
3.正向验证原因
1) 将wizchip_dhcp.c中，将getDHCPLeasetime()函数修改为如下，即续约租期改为120秒：
![check1.png](/uploads/202002/10/170204id0n232nuqpumz1p.png)
2) 运行程序1分钟左右即会发生断言
![mutex.png](/uploads/202002/10/165213h89slkm8c8mkaat8.png)
4. 反向验证原因
将定时器"wiz_lsd"改为软件定时器模式，然后将软件定时器默认的线程堆栈改为2048：
![check2.png](/uploads/202002/10/170747n2jvjio5hhkxzk05.png)

![check3.png](/uploads/202002/10/170817htz9z07wfyvvp8yd.png)
经过3个小时的连续运行，在120秒的续约租期条件下，证明修改的有效性。
5. 总结：
我水平不够，但个人觉得这是RTT团队的笔误或者是其他什么原因。除了这个严重BUG外，还有几个小吐槽：

二、使用wiz_set_mac()函数设置网卡的MAC地址，的确是设置到W5500寄存器里面了，但是使用ifconfig()命令仍然是默认的MAC值：
所以除了调用wiz_set_mac()外还需要设置netdev的数据：
![drv1.png](/uploads/202002/10/171735iws1k6tq1hss9mz4.png)

三、测试ping功能是发现有时会失败或者很卡，毫无规律：
查代码才发现，Wiznet模块使用固定DNS服务器地址：114.114.114.114：
1. 造成ifconfig设置的dns服务器地址就是摆设了；
2. 某些偏远地区使用地址为114.114.114.114的DNS服务器，状态很不友好，比如我所在的重庆。
因此我进行了下修改：
![dns1.png](/uploads/202002/10/172636sql2m2665k8mkqx2.png)
修改后，ping域名地址就很流畅了。

四、发现每次上电启动会出现接收超时错误：
![aa.png](/uploads/202002/10/173323v3rm2r34mcam8rgm.png)
SAL组件在判断是否连接internet的时候，会固定发送一条UDP信息(编译时间和版本号数据)到link.rt-thread.org:8101，收到服务器的回复就判断上网成功。
![bb.png](/uploads/202002/10/174910j4m76ttxsm4qannn.png)

![cc.png](/uploads/202002/10/174910fxaorsb4y64uza4y.png)
但现在是阿里云服务器都连上了，link.rt-thread.org:8101还连不上（也许是春节期间），造成我有些惊慌了，还以为又出了什么问题。因此我提个建议：
1. 将SAL_INTERNET_HOST和SAL_INTERNET_PORT放到ENV中进行设置；
2. check_netdev_internet_up_work()函数设置成weak模式；
开放给大家进行自由修改。

五、adbd模块在使用Wiznet的情况不能够使用
1. Disconvery模式会失败；
2. 使用SHELL会死机；
3. 由于SHELL都用不了，我也没有试文件传输功能；

马上要上班了，要收拾下心情，因此以上问题还没有开始查找，看RTT官方证实下，有没有什么解决方案。

武汉加油，中国加油！！！

![dhcp2.png](https://oss-club.rt-thread.org/uploads/202002/10/165131klom1oh83083y8oo.png)

14 个回答

hyd007 2020-02-10

这家伙很懒，什么也没写！

Spunky 2020-02-11

这家伙很懒，什么也没写！

aozima 2020-02-11

调网络不抓包，调I2C等时序不上逻辑分析仪，就像电工不用万用表！多用整理的好的文字，比截图更省流量，还能在整理过程中思考。

Spunky 2020-02-11

这家伙很懒，什么也没写！

armink 2020-02-12

这家伙很懒，什么也没写！

Cheney_Chen 2020-02-13

这家伙很懒，什么也没写！

Spunky 2020-02-15

这家伙很懒，什么也没写！

>感谢楼主反馈，几个问题我逐一回答一下：
>
>1. 软件定时器的问题已经在最新提交中改动过，参考https://githu ...

---

非常感谢这个帖子收到了官方的详细回复，前几天我发现问题后，只是用比较简单粗暴的方法修改，主要是验证问题。但具体修改肯定要思考下，我把我的思路提出来大家讨论下：

1. DHCP执行定时器死机的结症已经确认：
    1) 改为软件定时器。
    2) 软件定时器堆栈改为2048.

经过先前的验证是没有问题的。但是我认为使用定时器方案不是很好，原因如下：
    1) 使用W5500的单片机系统肯定SRAM是不丰富的，软件定时器堆栈必须在原有基础上（默认512字节）增加1.5K内存。
    2) DHCP功能只是在开机、续租到期或者插拔网线才执行一次，使用软件定时器利用率不高。

我建议使用RTT系统的workqueue模块，在初始化调用一次，将DHCP服务扔给"sys_work"线程去管理，这样就不增加任何多余的内存支出，我已经改好测试完毕，具体如下：
    1) 新增函数wiz_dhcp_work()，执行一次之后就利用workqueue服务自动连续执行:
     [attach]13646[/attach]

2) 修改wiz_network_dhcp()函数，在启动的时候调用一次即可，用于DHCP相关设置、workqueue的初始化和wiz_dhcp_work()的首次调用，开启DHCP的周期服务。
    [attach]13647[/attach]

3) 修改wiz_network_init()函数，增加调用前W5500硬件配置成功标志。
   [attach]13648[/attach]

4) 修改wiz_link_status_thread_entry()函数，用于在重新联网后执行一次DHCP服务
   [attach]13649[/attach]

5) 很多网友都反应上电的时候不插网线就失效。的确是这样，因此我进行下修改，目前测试没有什么问题：
   [attach]13650[/attach]

2. 设置MAC的问题我要说下应用逻辑，按照原作者思路是先搞个默认MAC，然后用户自己重新设置，但用户基本只能在DHCP完成后去设置，这样会存在一些不安的因素。因此我建议使用一个RT_WEAK函数的方法，在系统上电的时候就设置好MAC。具体修改如下：
    1) 增加用户设置MAC接口函数和修改wiz_set_mac()函数
    [attach]13651[/attach]   
   设置MAC接口函数范例：
    [attach]13652[/attach]

2) wiz_set_mac()调用位置调整
    [attach]13653[/attach]

3. 关于你说的DNS问题在wiz_netdev_set_dns_server()中添加，我没有理解：wiz_netdev_set_dns_server()已经设置了芯片和netdev的DNS了。
    [attach]13654[/attach]

我提出的问题是在使用wiz_socket.c文件里面wiz_gethostbyname()函数时固定使用了114.114.114.114的DNS服务器地址，而不是使用netdev或者芯片设置的dns地址，需要将芯片或者netdev的DNS读出来当做参数，然后调用DNS_run()函数。Wiznet包还是使用W5500的底层驱动包，DNS_run()不会自己去读芯片内部的DNS地址的，具体见下图：
   [attach]13655[/attach]

4. 关于check_netdev_internet_up_work()判断是否连接Internet，是向link.rt-thread.org发送一条UDP信息，收到回复后判断为NETDEV_FLAG_INTERNET_UP。
   这样的做法本身没有问题，但在不知情的情况下，心里阴影面比较大。这次如果不是春节期间link.rt-thread.org服务器出了点问题，我都还没有怎么关注这个细节。所以我觉得这块服务开放与不开放都没有问题，但是这个重要细节应该向用户说明下。。。。