Category: Uncategorized

Q1: 在芯片处于TCP_Server模式下，在交换机/路由器网络中无法ping通也无法通讯。 R: WIZnet芯片是硬件协议栈芯片，有别于软件协议栈，如果芯片不主动往网络中发包，在TCP_Server模式下是不会有任何数据包发送的，这样会造成路由ARP表中无法形成IP和MAC设备的对应关系。 A:解决方案: 在芯片上电时往任意IP发送一个UDP数据包，从而更新路由的ARP表，形成匹配关系，后续通讯就正常了。 Q2: 芯片在TCP_Client模式下，断电重启之后无法立即连接到服务器。 R:这是由于客户端没有主动发送断开请求，造成服务器并不知道Socket已发生异常断开; 重新上电之后，芯片以相同的IP和端口连接服务器，而服务器还认为此Socket链接存在，所以拒绝芯片的立即连接。 A:解决方案： 在芯片使用KEEP_ALIVE机制，一段时间内发送呼吸包，如果芯片没有给服务器回复，服务器则判断链接已断开，并释放Socket资源，这时就可以成功连接。如果对客户端的本地端口没有要求的话，也可以在初始化Socket的部分让端口自动+1处理。两种方式根据具体应用分析采用。 注: 有的场景不能采用端口自动+1的方式，比如电力104规约，只允许采用2404端口连接。 Q3: 网线异常断开，服务器的Socket已经断开，但是芯片不知道Socket已经断开，并没有重建链接，此时怎么处理？ A:解决方案： 可以在主循环中加入判断PHYCFGR状态的处理流程，如果PHY状态发生异常，释放所有的socket资源，并重新初始化socket。相关寄存器如下： Q4:如果芯片作为TCP_Server，最多可以链接几个Client，应该如何操作？ A:解决方案： 芯片作为TCP_Server，最多可以与8个客户端建立连接。不能初始一个Socket对应多个连接。可以将芯片的8个socket全部初始化，这样就可以与8个不同的TCP_Client建立通讯链接。 Q5: 在芯片处于TCP_Client模式下，无法连接到服务器。 R: 在TCP_Client模式下，WIZnet芯片无法连接到服务器。 A: 遇到这个问题，有一个排查的步骤： 检查IP层是否可以PING通； 检查服务器的目标端口是否处于侦听状态，否则会收到RST数据包； WIZnet芯片在连接服务器时，首先会发送ARP请求，请确认ARP得到正确回复； 检查客户端-服务器间的3步握手是否完成； Q6:W5200进入Power Down模式后，长时间以后唤醒不能恢复正常，如何解决？ A: 解决方案： W5200的Power Down模式是通过在一定时间内关闭W5200的内置PHY电路的工作来实现的，但是有一定几率PHY在休眠之后无法唤醒，需要在软件上做处理来唤醒芯片。经过测试验证发现，W5200芯片在3s极限值内快速唤醒一次再进入Power Down，当芯片需要唤醒正常工作时就不会出现以上问题。 Q7:WIZnet芯片进行公网通讯或者芯片间通讯的话怎么抓包? A: 解决方案： 芯片和PC通讯的话可以直接通过Wireshark抓包，如果芯片和公网直接通讯或者通讯是发生在芯片之间，则没有办法直接抓包，这需要借助于“可以抓包的交换机”，这种交换机多数是二手产品，而且是10M的网络，比如TP-LINK TL-HP5MU。把芯片和抓包计算机的网线分别插上交换机就可以运行抓包工具抓包。 Q8: W5300 TCP连接以后，Socket0数据收发正常，其它Socket有数据丢失是什么问题？ A:解决方案： W5300是总线方式操作，在确保地址总线和数据总线连接正确的情况下，还有一个很重要的问题，就是保持总线时序统一，经过验证MCU总线地址保持时间至少是W5300总线操作时间的2倍以上，否则可能会导致W5300来不及处理数据而导致数据丢失。如下图介绍。 Q9: W5500的硬件设计和以往的以太网设计有不同的地方，可否使用客户原有的以太网经验电路？ A:解决方案： 不能使用以往的经验电路，请严格按照WIZnet给出的参考设计进行硬件设计。 有的客户反馈在使用原有的经验电路也可以正常通讯，但是有可能发生在实验室正常，而客户现场连接不上的情况，所以统一建议客户使用官方的参考设计。 Q10:W5500的以太网电路，正常线序连接的话可能必须做过孔交叉线序，能否在线路上做交叉处理？ A: 解决方案： W5500的以太网接口的四根线，按照正常的线序连接，必须通过过孔交叉线序; 按照以太网布局规范，需要等长差分走线。而且需要尽量少的过孔，可以适当做P-N交叉，既TXP-TXN交叉，RXP-RXN交叉，以符合以太网布线规范的要求。 Q11: Wake On Line（WOL）功能如何使用？ A:解决方案： WIZnet芯片打开WOL功能只需要置位MR寄存器的WOL位，不需要外部设定。唤醒方法为向WIZnet芯片的UDP端口发送Magic数据包(0xffffffffffff+16个目的MAC地址)，设备唤醒后IR寄存器的WOL位会置1，通过检测该位获取WIZnet芯片的状态。（注意WOL功能不能和掉电模式（Power down mode）同时打开） Q12: 如何使用UDP组播功能？ A:解决方案： 使用WIZnet芯片的UDP组播功能有几点需要注意： 1，需要在打开Socket之前，先指定目标MAC地址为组播MAC地址，定义规则如下： 2，打开一个支持多播UDP的Socket，目标IP为组播地址； 3，然后就可以进行UDP组播传输。 注意：如果没有定时发送“维持UDP组播”的数据包 的话就会被清出组播组，可以定时执行打开步骤2的打开Socket的指令，因为打开和维持UDP组播的数据包是完全一样的。 Q13: 运行HTTP_Server程序在不同的浏览器下显示效果不同，有的动态效果显示不出来？ R: 这个是HTML代码和浏览器的兼容性问题，因为HTML5的很多标签和CSS样式表在低版本或者不同的浏览器内核下的排版和兼容性都不同。 A: 在HTML开发的时候使用JavaScript可以判断浏览器的内核和版本，可以针对不同的浏览器开发不同的执行代码和CSS样式表，或者建议客户使用推荐用户使用chrome系列或者chromium内核的浏览器，因为其对HTML5/CSS3支持是比较完善的。 Q14: MAC地址定义有什么特殊要求？ A:解决方案： MAC地址要求不严格的话可以自定义，因为只要在一个子网内没有重复的MAC地址就不会造成MAC地址冲突的问题，因为如果进行公网通讯，网关会通过NAT功能将网关的MAC和IP对数据包中的MAC和IP进行替换然后再和公网通讯，所以不会造成公网中的MAC冲突的问题。但是如果要求比较严格，则需要从IEEE基金会申请全球唯一的MAC地址，申请地址如下： https://standards.ieee.org/products-services/regauth/oui36/index.html 进入该页面后点击Log in or create an account(新用户需注册)，登陆后即可购买。 Q15: WIZnet芯片PING不通其它设备。 A:根据ICMP协议，request包的大小为128byte，reply包比request包大8byte，为136byte。 客户可以分别定义两个Buffer[128]和Buffer[136]分别对应request包和reply包，也可以共用一个Buffer[136]，但是不能发送接收使用同一个128byte的Buffer，否则会造成接收数据不全，无法解析。 Q16: 使用中断方式，回环测试时无法清除中断 R: W5500收到数据后会产生RECV中断，当回环测试时，正常清掉RECV中断后，由于采用的回环测试方式，W5500又将同一包数据发送了出去，所以又会产生SEND_OK中断。 A: 此时需要再次清SEND_OK中断，或者改用单向测试方式即可。 Q17: 为何使用STM32F103无法完全发挥W5500的性能 A: STM32F103的主频最大72MHz，但是SPI接口的最高频率限制为18MHz 而W5500的SPI时钟最高可达80MHz,所以以 STM32   驱动W5500的话，无法满足W5500对最高时钟的需求。 而如果使用STM40x处理器，SPI时钟使用42Mhz，使用DMA方式，可以达到回环测试17Mbps的速率（收+发），单独发送可以达到13Mbps的速率 Q18: 如何使用PHY-PHY电路？ A: 经常有需要使用PHY-PHY电路的场景，比如使用WIZnet做内部数据通讯，比如需要使用板载的Switch电路等等，PHY-PHY电路的要点就是使用耦合电容隔离两端的PHY，并加入两个PHY各自的偏置电路。类似于如下的设计： Q19: 以太网如何级联？ A: 在特殊的应用场景下，客户需要用网线将所有的节点按照这种方式“A-B-C-D-E”线状级联在一起。这种应用需要使用Switch芯片，比如IP175G等芯片，按如下图示链接： Q20: 无法通过“以太网物理层一致性测试”中的眼图测试 A: 眼图是表现网络信号是否稳定的测试，眼图混乱有可能导致同一批次的设备有的无法正常通信，造成原因是： 1，没有按照以太网的布局标准来设计硬件电路， 2，采用的可能是不合格的网络变压器器件。 下图为使用W5500和HRW5500RE的眼图测试结果。 Q21: 使用WIZnet芯片无法通过低温测试 R: 通不过低温测试通常表现为低温-40℃不启动，原因是电路上除了WIZnet 的芯片外，还有晶振以及网络变压器等周边器件，造成结果通常是由采用的周边器件不是工业级温度的器件。症状如下：…