Category: 博客

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交叉，以符合以太網布線規範的要求。 figure-8-w5500-ethernet-wiring 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…