下面是測試記錄
1、 根據閱讀資料的體會，進行一些嘗試性的測試，有一些結果。方法如下。
2、 現在的操作流程是，網線一端連線pc，一端連線板子，板子不上電。此時要把工作列本地連線圖示設定為顯示在工作列狀態，給板子上電，網線插緊。然後，在板子的乙太網口初始化之後，工作列本地連線圖示會變成下圖所示。如果是硬體上沒連線好，那麼就是紅叉叉。
開接收中斷，可以進入中斷服務程式。但是從中斷返回後，就進入faultisr，原因不明。
測試到這，作相關說明：上面的過程，按我的理解是這樣的。乙太網初始化之後，都是在全雙工模式下，pc機與板子互相發一些帶有資料報的快速鏈路脈衝來進行自協商，所以板子能進入接收中斷，也能看到資料。一直到自協商成功之後不再發資料，而只是定時的發快速鏈路脈衝，相當於心跳檢測，從此乙太網mac層連線成功，可以進行底層資料收發。
檢視乙太網資料波形，測量結果如下圖：
測試疑問：
1、 對這個資料波形不太理解。
2、 由於不知道pc機向板子發的資料是什麼，無法對資料進行檢查，目前只知道有資料可以進來。
3、 板子底層向pc機發的資料無法在pc機上識別，pc機的網路除錯助手軟體是帶協議棧的，如果不符合協議棧格式的資料報可能會丟棄。如果想知道底層的資料對不對，可以拿兩塊板子互連測試。
7月1日上午
1、 有了上面的基礎，再次測試udp工程，看看協議棧是不是一次可以連通。
2、 這次udp_bind，和udp_connect都返回成功，開接收中斷，進入while(1)迴圈。此時應該已經建立了udp連線，中斷裡加斷點，用pc機軟體向板子發資料，可以進入中斷。但是，中斷處理裡，底層的low_level_receive中，從fifo中讀取資料時，程式對資料的解析有問題。第一次讀出來的數是目標ip位址，但是程式裡認為第一次讀出來的數的低16位是packet的長度len。導致後面為收到的packet分配緩衝區失敗。分配緩衝區失敗，那麼就要清空rxfifo，即按照剛才錯誤的長度，把rxfifo裡的數全部讀出來。在把fifo中數讀出來的過程中，我沒有發現有我發的資料。
3、 檢視晶元資料，從rxfifo的組成來看，程式的解析是沒錯的。那就是資料錯誤。但是資料的第乙個字是目的位址，判斷資料不對的原因應該不是資料錯位，而可能是協議上的問題。
7月1日下午
1、 在可以正確進接收終端的情況下，將fifo中的數讀出來。結果是，接收fifo中並沒有pc機發出去的數值，而只是週期性的未知資料。100個位元組1個迴圈。見下圖
總結：到此為止，基本可以確定硬體沒有問題，因為在資料中已經看到了ip位址的正確報文，此時就需要去了解整個的報文互動過程，另外在除錯方法上，帶作業系統的除錯方法和不帶作業系統的除錯方法有略有區別，需要增加除錯經驗。
注意點：
在iar中開啟暫存器視窗時，在讀乙太網fifo時會出現單步執行fifo指標跳躍情形，這是由於程式在讀fifo，iar工具暫存器視窗也在讀fifo，導致的單步一次其實讀了兩次fifo。
確認中斷後，中斷裡的斷點就可以去掉了，否則由於tcp協議有重發機制，後續的單步除錯會被新來的報文所打斷，干擾除錯。
乙太網協議
乙太網協議 用於10mbps的乙太網，作者以下所說的乙太網均指10m乙太網，而不是100m，1000m的乙太網 乙太網協議有兩種，一種是ieee802.2 ieee802.3，還有一種是乙太網的封裝格式。現代的作業系統均能同時支援這兩種型別的協議格式。因此對我們來說只需要了解其中的一種就夠了，特別是...
TCP IP協議棧 乙太網 VLAN
1.tcp ip分層和tcp ip協議棧 osi七層模型注重的是模型本身，這個模型對討論和研究計算機網路是非常有益的。但是，大家更喜歡用tcp ip協議來分層，它注重的是協議。tcp ip分層後，將各種協議對應到這些分層，那麼就稱tcp ip協議棧。osi七層協議 tcp ip分層和tcp ip協議...
一 乙太網協議
乙太網協議 用於10mbps的乙太網，作者以下所說的乙太網均指10m乙太網，而不是100m，1000m的乙太網 乙太網協議有兩種，一種是ieee802.2 ieee802.3，還有一種是乙太網的封裝格式。現代的作業系統均能同時支援這兩種型別的協議格式。因此對我們來說只需要了解其中的一種就夠了，特別是...