1. 功能板的硬體架構為什麼要一顆ESC加一顆DSP前段時間拿到一塊國產化功能板板子上搭了兩顆關鍵晶片一顆是EtherCAT從站控制器FCE1100另一顆是DSP控制器FCP32C335。這塊板子的目標很明確就是把完整的EtherCAT從站功能跑通並且在接下來的幾個項目裡作為標準硬件平台複用。我需要做的不是簡單點個燈、通個訊而是把從站從上電到OP狀態、再到長時間穩定運行的整個鏈路驗證一遍最終給出一個可以支撐量產的測試結論。在展開完整測試流程之前先把硬件架構說清楚。很多工程師第一次接觸這類平台時容易把FCE1100和FCP32C335的職責搞混後續排查問題時就會走彎路。這部分理解透了整篇測試流程才有落腳點。1.1 FCE1100在板子裡到底扮演什麼角色FCE1100是一顆EtherCAT從站控制器也就是通常說的ESC。它體現在系統裡的作用可以理解成一個「收發室」所有來自主站的EtherCAT報文先由FCE1100處理它會識別報文裡哪些數據是發給這個從站的、哪些需要轉發給下一個從站然後把屬於本從站的數據放到內部寄存器和過程數據存儲區。這裡有個關鍵認知ESC本身不跑應用邏輯它也不負責解釋「這個數據是位置指令還是速度指令」。EtherCAT協議裡複雜的狀態機切換、對象字典管理、PDO映射解析都是外部應用處理器的工作。FCE1100要做的是保證網絡鏈路層的實時性和可靠性。FCE1100內部集成的核心模塊包括EtherCAT幀處理單元、FMMU現場總線內存管理單元、SM同步管理器、SII從站信息接口EEPROM接口、DC分佈式時鐘單元以及PDI過程數據接口。其中PDI是它和外部DSP溝通的通道我這塊板子使用的是SPI從模式DSP作為SPI主機訪問FCE1100的內部寄存器和過程數據內存。也有設計使用8位並行總線但SPI從模式對引腳佔用更少佈局也更簡單在功能板上是比較主流的選擇。需要強調的是FCE1100的寄存器佈局和主流國外ESC芯片基本兼容但並不能簡單地當作「完美替換」來用。實際測試中我發現它對一些保留位的行為、復位時序的要求以及EEPROM加載失敗後的默認狀態都和傳統芯片存在細微差別。這些差別單看寄存器手冊不一定能發現必須通過實測來驗證後面的章節會詳細講。1.2 FCP32C335需要承擔的任務FCP32C335是一顆國產DSP控制器從產品定位上說它和常見的C2000系列DSP比較接近具備定點運算、多路PWM、ADC、QEP正交編碼接口等工業控制常用外設主頻和片上資源也足夠跑EtherCAT從站協議棧。在整塊功能板上FCP32C335承擔的是「應用處理器」的角色。它的任務包括三大部分第一運行EtherCAT從站協議棧。這裡說的是SSC生成的代碼也就是EtherCAT Slave Stack Code。協議棧處理AL狀態機的狀態切換INIT、PREOP、SAFEOP、OP、對象字典讀寫、PDO映射更新、DC同步中斷等。第二響應FCE1100的中斷請求通過SPI接口及時讀寫過程數據。第三執行實際的應用控制邏輯比如採集IO狀態、控制電機驅動器、讀編碼器位置等。這三部分任務在時序上是重疊的所以FCP32C335的中斷優先級規劃特別重要。我在測試中把SPI數據交換中斷設為最高優先級其次是SYNC0同步中斷再往下才是應用控制任務。如果優先級設置不當EtherCAT通信週期一縮短丟幀、同步抖動的問題很快就會暴露。1.3 兩顆芯片的協作關係與數據通路FCE1100和FCP32C335之間的數據通路決定了整個從站的實時性和穩定性。FPGA方案裡ESC IP核可以掛在高速總線上訪問延遲幾乎可以忽略而FCE1100加FCP32C335這種雙芯片方案數據必須經過SPI延遲就變成了一個需要關心的指標。我這塊板子的鏈路是這樣的FCE1100收到主站發來的過程數據後會把數據放到內部DPRAM對應的SM緩衝區中然後拉高一個中斷引腳通知FCP32C335。DSP收到中斷後立刻啟動SPI讀操作把SM緩衝區中的數據搬運到DSP本地內存再執行用戶應用邏輯。反過來DSP需要上報的數據也是通過SPI寫入FCE1100的Tx緩衝區等待下一個EtherCAT幀到來後自動拾取。這條鏈路上的每一步都有測試點。SPI時鐘速率、中斷響應延遲、DSP是否開啟了Cache、是否使用DMA都會影響最終的通信週期抖動。剛開始調試時我不建議把SPI速率直接拉滿先跑10MHz等整個從站狀態機跑通再逐步提高速率並觀察通信質量。我在後續測試中把SPI速率提到了20MHz運行了一個星期整體表現穩定但這不意味著每一塊板子都能直接照搬還是要看具體佈局和信號質量。還有一個很容易忽略的點DSP內存與SPI DMA緩衝區的一致性。如果FCP32C335帶有Cache而SPI DMA直接寫入了內存緩衝區DSP讀到的有可能是Cache中的舊數據。這個問題的表現非常怪異通信彷彿正常但數據偶爾就是不對。測試時務必檢查緩衝區是否做了Cache一致性處理哪怕使用簡單的Cache禁用或手動失效操作也行。2. 測試環境搭建從主站軟件到XML描述文件的準備硬件架構理清之後下一步是搭建測試環境。很多新手拿到從站板子第一件事就是把網線插上打開主站軟件掃描結果發現掃描不到設備然後就開始懷疑硬件。其實大部分掃描失敗都跟環境配置有關提前把主站、XML、網卡、物理層都準備好後面會省非常多時間。2.1 主站方案的選擇EtherCAT主站的選擇很多測試階段我同時用了兩套方案。第一套是TwinCAT 3這幾乎是EtherCAT開發的標配工具安裝方便免費試用即可滿足單從站調試需求。TwinCAT對Intel網卡的支持比較好實測下來Intel 82574和82583系列網卡最穩使用板載Realtek網卡容易出現異常丟幀不建議直接用。第二套是SOEM開源主站跑在工控機的Linux系統上。SOEM的好處是輕量、自動化程度高我可以寫腳本自動執行狀態切換、PDO讀寫和長時間回歸測試不需要人工盯著TwinCAT界面。兩套主站配合使用的好處是調試初期用TwinCAT圖形化界面直觀地看從站狀態、各寄存器值、PDO數據變化後期做壓力測試時用SOEM寫自動化腳本可以24小時無人值守。如果條件有限只裝TwinCAT也夠用但會犧牲一些自動化測試的便利性。還有一個細節Windows下使用TwinCAT時最好把網卡的EtherCAT實時任務時間設置正確否則會出現主站週期不穩定的假象。這個問題表現為從站本身沒問題但誤差數據全部超標排查起來非常誤導人。2.2 XML從站描述文件的生成與檢查EtherCAT主站要識別從站必須加載對應的XML描述文件ESI文件。XML裡定義了從站的廠商ID、產品代碼、通信參數、PDO映射、DC同步配置等關鍵信息。主站掃描總線時會把網上實際讀到的從站信息來自SII EEPROM和XML進行比對兩者不一致就會報錯。FCE1100的XML可以基於SSC工具生成再根據實際板卡的PDO對象做修改。我建議大家不要直接網上找一個現成XML就拿來用因為PDO映射、對象字典索引、同步單元管理這些內容跟實際固件強相關一個索引對不上主站加載時就會報配置錯誤。檢查XML時重點看幾處Vendor ID、Product Code、Revision Number是否與EEPROM裡燒錄的一致。RxPDO和TxPDO的索引、子索引、數據類型是否與固件中的對象字典一致。SyncManager的配置方向輸入輸出的SM編號是否匹配。DC同步單元配置是否正確尤其是同步類型和週期設置。XML裡有個特別容易被忽視的字段是CoE Details裡面勾選了從站是否支持SDO讀寫、是否支持緊急報文等能力。如果主站需要通過SDO配置從站參數而這裡沒有勾選SDO導致通信行為不符合預期排查起來會非常繞。2.3 上電前的檢查順序接好主站環境之後先別急著插網線。硬件上電前我習慣按固定順序做靜態檢查十次裡有八次能把潛在問題提前攔住。先查電源電壓和紋波。FCE1100和FCP32C335的電源域可能不同需要確認各路電壓是否在允許範圍內紋波不能太大。然後確認時鐘是否起振FCE1100需要外部晶振或者由其他芯片提供時鐘如果時鐘頻率不對鏈路層根本沒法工作。接著檢查PHY芯片的復位引腳和FCE1100的復位時序很多從站掃描不到的問題出在復位時間不足PHY還沒有完成初始化主站就開始掃描了。我常用的檢查清單整理成了表格每次測新板之前都會過一遍檢查項預期結果常見異常各路電源電壓在芯片手冊範圍內DSP內核電壓偏低導致啟動失敗電源紋波50mV開關電源干擾大造成通信誤碼時鐘頻率與原理圖一致晶振虛焊時鐘停振PHY復位時序復位脈衝寬度足夠PHY未就緒鏈路無法建立FCE1100復位腳上電後正常釋放復位被拉死寄存器無法訪問SPI引腳電平空閒狀態正確上拉電阻缺失誤觸發中斷這張清單看起來簡單每次都能救場。之前有一塊板子主站怎麼都掃描不到排查了半天發現是PHY復位引腳被一個大電容拖慢了復位時間超過了芯片手冊要求把電容改小之後一次通過。3. 從站識別與SII EEPROM調試測通的第一步從站板卡上電、網線接好、主站軟件打開之後接下來的目標是讓主站掃描到這台從站。如果這一步過不去後面所有功能測試都無從談起。這裡的關鍵不在於主站而在於FCE1100的SII EEPROM配置是否正確以及ESC本身的運行狀態是否正常。3.1 ESC上電掃描不到先查這幾個地方EtherCAT主站掃描不到從站問題一般出在三層物理層、ESC核心狀態、EEPROM配置。物理層比較好排查看PHY的Link指示燈是否點亮用網線測試儀確認線序是否正確。EtherCAT使用標準以太網物理層但線序是百兆的直連方式如果中間經過了不兼容的交換機也會導致掃描失敗。ESC核心狀態可以用主站軟件直接讀寄存器。EtherCAT從站地址默認是0主站會通過配置報文寫入從站地址。如果ESC的數字邏輯不正常寄存器讀寫無響應主站就會把該從站標記為無響應。在掃描階段我強烈建議先用TwinCAT的TMC網卡掃描工具或者直接用命令讀取ESC寄存器0x0000的DL控制寄存器和0x0010的DL狀態寄存器。DL狀態寄存器裡有物理層鏈路狀態、端口0和端口1的Link狀態如果其中一個端口始終為0說明這一側的線路沒有通。如果DL狀態正常但主站仍然無法識別從站類型問題基本就鎖定在EEPROM。FCE1100上電後會嘗試從外部EEPROM加載配置包括設備名、廠商ID、產品代碼、通信配置。EEPROM沒有燒錄、內容損壞或者CRC校驗失敗ESC會退回到默認狀態主站能讀到一個「未知設備」但不是我們想要的設備信息。3.2 SII EEPROM的內容規劃與燒錄SII EEPROM的在線調試有兩種方式一種是直接燒錄物理EEPROM芯片另一種是使用ESC的虛擬SII模式。我建議調試階段先用虛擬SII把所有配置驗證沒問題後再正式燒錄EEPROM。虛擬SII模式的意思是ESC不從外部EEPROM讀取配置而是通過PDI接口也就是SPI直接把配置寫入ESC內部的SII寄存器影子區域。對FCP32C335來說這意味著可以在DSP固件裡維護一份SII配置上電時通過SPI寫入之後ESC就按這份配置運行。好處是改配置不需要反覆擦寫EEPROM調試效率非常高。EEPROM的內容規劃一般分為幾個區域0x0000到0x003F是ESC配置區包括PDI控制、FMMU使能、SM配置、DC配置0x0040到0x007F是廠商信息區包括廠商ID、產品代碼、修訂號再往後是字符串和附加信息。其中ESC配置區的位含義必須逐位核對。舉個例子PDI控制字會決定SPI工作模式、中斷引腳的工作方式、是否允許SDO讀寫等。如果配置字不對DSP可能讀不到中斷或者SPI通信異常表現得很像硬件故障。燒錄EEPROM時使用官方提供的SII工具或者SSC的ConfigTool都可以但我不建議用TwinCAT直接燒寫。TwinCAT的EEPROM寫入功能在緊急情況下可以救場但操作不當可能把ESC配置區寫成一個無法加載的狀態導致後續每次上電都要人工干預。量產階段最好在產線用專用燒錄器把EEPROM固化成一個標準映像文件。3.3 EEPROM裡最容易燒錯的兩個位置第一個是廠商ID和產品代碼。這兩個值如果和XML不一致主站雖然能識別到設備但配置階段會報「Device mismatch」需要手動確認是否繼續。如果是完全沒匹配到則會直接加載失敗。我習慣把廠商ID和產品代碼寫死在固件和XML裡並在測試腳本裡做一致性檢查防止改版時漏改。第二個是ESC配置區中SM通道的緩衝區大小設置。EtherCAT從站在PREOP階段需要把SM通信關係配置好主站會依據XML裡的SM配置來計算過程數據佈局。如果EEPROM裡的SM緩衝區大小和XML不一致SAFEOP切換到OP時就可能發生數據長度溢出或者數據錯位。這個問題的隱蔽之處在於偶爾主站不會直接報錯而是數據內容錯亂第一次遇到的工程師往往會懷疑是PDO映射寫錯了。我個人的做法是在固件裡加一個自檢函數上電時把EEPROM中的SM配置讀出來和編譯期的配置結構體逐一對比不一致就點亮錯誤指示燈並向主站上報一個診斷對象。這樣可以把底層配置問題隔離出來不讓它污染後續功能調試。4. PDO與過程數據通訊軟件功能驗證的重頭戲從站被主站正確識別後功能測試才真正開始。前面所有的硬件、EEPROM、XML工作最終都是為了讓過程數據在OP狀態下穩定跑起來。這一步是整個測試流程裡佔時間最長的環節也是發現問題最多的環節。4.1 從INIT到OP的狀態切換驗證EtherCAT從站有四個狀態INIT、PREOP、SAFEOP、OP。主站會通過AL Control寄存器逐級切換狀態從站則通過AL Status寄存器回應。完整流程是INIT到PREOP進行EEPROM和SDO參數初始化PREOP到SAFEOP激活SM通信過程數據開始交換但輸出保持安全狀態SAFEOP到OP正式激活輸出。測試時不能只看最終能否到OP每一級狀態切換都要確認。比如INIT進PREOP失敗可能是SDO初始化階段某個對象字典條目未被處理PREOP進SAFEOP失敗多數是SM配置或者FMMU配置有問題SAFEOP進OP失敗通常是輸出PDO映射的數據長度、方向與主站不匹配。我在固件裡給每個狀態回執做了調試輸出用串口把AL Status的錯誤寄存器打出來配合主站報文能快速定位是哪一級失敗。如果沒有串口調試條件可以讀取ESC的AL Status Code寄存器把錯誤代碼記錄下來配合手冊查對應原因。比如0x001A表示無效的SM通道配置0x0020表示無效的PDO映射這些信息比憑空猜測靠譜得多。4.2 用環回數據做全鏈路測試狀態機切換到OP之後不要急著接真實外設先用環回數據把通信鏈路測通。環回測試的思路很簡單在RxPDO中定義一個計數器變量主站每個週期發一個遞增數值從站收到後在應用代碼裡把這個值加一放入TxPDO回傳給主站。主站如果連續收到的數值都能按預期遞增說明整條鏈路是通的主站到FCE1100的Rx數據、FCE1100到DSP的SPI搬運、DSP的應用任務、Tx方向的回傳路徑全部正常工作。這裡有一個小技巧環回數據裡除了計數器還可以攜帶一個時間戳字節。DSP在收到SPI數據時記錄當前系統時間連同計數器一起回傳。主站收到回傳後用當前週期時間減去發送時間就可以粗算出從站處理延遲。這對後續優化通信週期非常有價值。環回測試要跑多長時間我的標準是連續跑24小時不丟一幀、計數器不跳變。測試期間可以把通信錯誤計數寄存器加進診斷如果出現過一次WKC錯誤或者CRC錯誤記錄哪怕最終沒有影響通信也必須停下來分析原因。EtherCAT網絡的優勢就是低丟幀任何一幀異常都可能是潛在穩定性的定時炸彈。4.3 通信週期上不去的排查路徑環回數據穩定運行後下一步是縮短通信週期。很多從站板卡在1ms週期下表現良好但一改到500us甚至250us就開始丟幀、進入OP失敗這裡積累了一些排查路徑可以參考。先看主站週期是否真的穩定。有些情況下主站所在工控機的實時驅動沒有安裝好週期本身抖動很大從站是被冤枉的。用TwinCAT的實時診斷窗口可以看到主站週期的實際抖動情況。再看DSP主循環和中斷佔用時間。EtherCAT從站並不需要在每個週期跑完整的協議棧但SPI數據搬運、PDO映射處理、用戶應用計算都需要時間。如果一個通信週期內要做的事情太多超出了週期時間就會積壓響應延遲。我習慣把之前提到的環回時間戳做成直方圖統計直接看在縮短週期後從站處理延遲的均值、最大值是否變大。最後查ESC看門狗配置。ESC內部有PDI看門狗和過程數據看門狗時間設置太短DSP在一段時間內未及時刷新數據ESC就會把輸出置為安全狀態。而且不同的ESC芯片看門狗行為有細微差別FCE1100的看門狗計時器單位需要對照手冊確認不能完全照搬之前用國外芯片時的設置。在250us週期測試時我發現一個奇怪現象單獨的環回測試正常但同時開啟高速採集外設後偶發丟幀。最後定位到是FCP32C335的中斷嵌套高速採集外設的中斷把SPI中斷打斷了一段時間導致ESC側的PDI看門狗超時。解決方案是把SPI中斷優先級提到最高並把採集數據搬運放到低優先級任務中處理。5. DC同步測試分佈式時鐘精度才是EtherCAT的殺手鐧如果只是把過程數據跑通EtherCAT和普通現場總線沒有本質區別。真正讓EtherCAT在多軸運動控制中佔據主導地位的是分佈式時鐘DC機制。DC讓所有從站共享同一個時間基準並能產生高精度的同步中斷確保各從站在同一時刻採集數據或更新輸出。功能板測試如果不覆蓋DC同步其實等於沒測完。5.1 DC同步精度怎麼測才靠譜DC機制要求主站周期性地發送「時鐘同步報文」EtherCAT傳輸過程中的延遲會被每個從站計算並補償最終各從站的系統時間與主站時間偏差控制在亞微秒級別。FCE1100內部帶有DC單元測試目標是驗證它的延遲補償算法是否正常以及SYNC0中斷脈衝的實際抖動能否滿足運動控制需求。如果只用主站寄存器裡的系統時間差數據來評估有時會因為報文時序和計算時機問題測出一個「虛幻」的分數。我推薦直接用示波器量硬件引腳把FCE1100的SYNC0輸出引腳接到示波器連續統計脈衝間隔的抖動。具體做法是配置從站PDO裡的DC同步週期為1ms觸發方式設為SYNC0然後把示波器設置成脈衝寬度觸發統計一萬個脈衝邊沿之間的時間差。理想情況下相鄰兩個SYNC0脈衝間隔應穩定在1ms誤差來源主要是本地時鐘的晶振精度和主站同步算法整體在幾十納秒到幾百納秒之間。實測這塊功能板在常溫下1ms週期的SYNC0脈衝間隔抖動在±120ns以內這個數據對於一款國產從站芯片來說完全夠用。當然這個數值會隨著電源紋波、溫度、主站負載而變化測試結論裡必須寫明測量條件。5.2 SYNC0中斷和DSP控制任務的配合DC的硬件精度再好如果DSP軟件處理不當到了應用層也一樣會產生抖動。FCP32C335通常把SYNC0中斷作為控制任務的觸發源進入中斷後立即讀取輸入數據、執行控制算法、更新輸出數據。中斷裡的操作必須極度精簡任何不必要的計算都可能放大抖動。這裡我需要提醒一個細節SPI讀寫本身是阻塞操作。如果SYNC0中斷裡直接調用SPI讀寫函數讀寫時間會疊加到中斷處理時間中導致SYNC0脈衝雖然準時但控制任務卻被推遲。我測試時碰到過這種情況示波器上SYNC0脈衝間隔看起來很好但實際的電流環週期誤差偏大原因就是DSP在中斷裡耗時太長。解決辦法有兩個方向。一是提前在SYNC0中斷之前通過DMA把上一週期的輸入數據從SPI緩衝區搬到內存SYNC0到來時直接讀內存。二是把控制任務掛到SYNC0中斷的觸發線程中數據交換放在主循環裡用雙緩衝區機制保證數據的新鮮度。第二種方案實現起來稍微複雜一些但效果更好。5.3 實測數據不同週期下同步誤差的表現為了給出一個全面的測試結論我在1ms、500us、250us三個週期下分別測了SYNC0信號抖動每個工況連續運行半小時用示波器的統計功能記錄脈衝間隔的標准差和最大偏差。通信週期SYNC0抖動標準差最大間隔偏差觀察到的異常1ms約40ns±120ns無500us約55ns±180ns偶發1次間隔超差250us約80ns±310ns無持續異常這組數據是在實驗室環境下測得的不能代表芯片極限更多的是驗證測試方法是否有效。從結果看週期縮短之後抖動有所增加但都在可接受範圍內。如果應用需要更高的同步精度一方面可以優化主站DC參數另一方面需要檢查PCB的電源去耦和地平面設計。還有一點想強調DC測試完成後不要立刻結束。一定要做一次「斷網重連後還能重新同步」的驗證。有些DC實現只在冷啟動時正常主站重啟或者從站斷電重新上電後延遲補償值計算會出錯導致同步精度大幅下降。這個問題在我測試其他方案時遇到過FCE1100目前實測下來重啟後能自動恢復同步。6. Wireshark抓包與異常注入把隱性問題變成顯性寄存器、狀態機、PDO數據都正常後並不代表從站已經完美。很多隱性問題比如週期性丟幀、異常長幀、錯誤的WKC只有在報文層面才能看到。Wireshark抓包是EtherCAT調試裡最有效的底層手段關鍵是知道抓什麼、怎麼看。6.1 抓包環境搭建與過濾器設置抓包基本原理是利用網卡的混雜模式讓網卡接收網絡上所有EtherCAT幀並提交給抓包軟件。Windows下安裝Wireshark時會一併安裝Npcap這是抓包的基礎。需要注意的是EtherCAT使用以太網類型0x88A4普通網絡流量和EtherCAT流量混在同一網口時必須用過濾器把EtherCAT幀篩出來。我常用的過濾器是ecatWireshark已經支持EtherCAT協議解析。如果不放心也可以用ethertype 0x88a4確保只看EtherCAT幀。抓包時可以看到幀頭、從站地址區、APDU指令、WKC、數據區等內容。抓包最容易踩的坑是交換機。不要用普通交換機串在鏈路裡交換機會過濾廣播幀、延遲轉發導致抓到的幀不完整或者時序失真。最穩妥的方式是使用帶鏡像功能的工業交換機或者直接在用於EtherCAT通信的網卡上抓包但要注意主站實時驅動可能影響抓包效果。更推薦的方式是在TwinCAT環境下使用「EtherCAT監視器」功能或者用專門的EtherCAT分析儀。但對於功能板單從站測試普通鏡像交換機已經足夠。另一點抓包期間不要同時跑高負載的實時任務否則Wireshark自身處理能力跟不上會造成抓包丟失幹擾判斷。6.2 從WKC和CRC看通信健康度EtherCAT幀的每個APDU都帶有工作計數器WKC主站用它確認從站是否正確處理了報文。比如一個FPRD物理讀命令主站會期望從站返回的WKC等於1如果返回0說明從站沒有正確響應如果等於其他值則說明有額外處理。通信不穩定時WKC錯誤是最常見的表現。Wireshark通過顏色標記可以看出來正常的EtherCAT幀綠色居多出現WKC錯誤或CRC錯誤時會有提示。但實際調試中不能只靠顏色要習慣查看每個APDU的WKC字段並和主站側的錯誤計數做交叉驗證。CRC錯誤要單獨注意。EtherCAT幀的CRC由硬件計算從站收到幀後會做完整性校驗。如果從站返回的幀CRC錯誤問題幾乎可以鎖定在物理層網線過長、PHY芯片供電不足、阻抗匹配不良、地平面干擾等而不是協議棧軟件問題。我看抓包的習慣是先統計一段時間內的幀總數然後按APDU類型分類再看每一類的WKC異常次數。如果發現週期性丟幀就用Wireshark的IO圖表功能看丟幀出現的頻率和週期是否和某個任務相關。有一次測試中丟幀恰好和伺服驅動器的PWM載波頻率呈倍數關係最後排查出是板卡上驅動芯片的開關噪聲耦合到了網口變壓器屬於硬件設計問題靠軟件永遠修不好。6.3 斷網重連與異常幀的實戰測試抓包的另一個重要用途是觀察異常場景下的行為。我設計了一組異常注入測試主站正常運行在OP狀態時人為拔掉網線10秒、30秒、60秒再重新插回觀察從站能否自動恢復通信以及恢復過程需要多少個週期。測試中重點抓幾個時間點的幀斷線瞬間、重連瞬間、狀態切換報文。正常的從站行為是斷線時ESC檢測到link down會觸發中斷通知DSP重連後主站需要重新掃描或讓從站重新進入OP。如果從站固件沒有處理link down事件重連後可能長時間處於未知狀態無法自動恢復。FCE1100實測在這組測試中表現不錯10秒和30秒斷線都能自動恢復OP恢復時間在20ms到50ms之間。60秒斷線後需要手動恢復的概率稍高但這是符合協議預期的行為因為主站可能已經把從站標記為超時下線。異常幀測試則人為構造一些CRC錯誤幀或者長度畸變幀看看從站是否會因此進入異常狀態。EtherCAT從站的設計要求是錯誤幀不能影響正常通信。如果某一次異常幀觸發了看門狗復位或者狀態機跳變測試結論就可以直接判定為不合格。在這一項上FCE1100能正確丟棄錯誤幀沒有出現異常跳變。7. 壓力測試與最終結論功能測試全部通過只代表從站在理想環境下能工作。工業現場往往伴隨高溫、電磁干擾、長時間連續運行等惡劣條件壓力測試就是要模擬這些工況把隱患在量產之前逼迫出來。7.1 高溫環境下的連續運行我測試時把功能板放進恆溫箱溫度設定為65℃連續運行72小時。測試期間保持EtherCAT通信週期500usPDO環回數據持續計數每小時記錄一次通信錯誤計數、從站AL狀態、核心溫度。高溫對從站的影響主要體現在兩個方面一是晶振頻率漂移這會影響DC同步精度二是DSP內部時序余量下降SPI通信可能出現偶發錯誤。實測這塊板子在65℃下SYNC0抖動比常溫略增大但仍在可接受範圍通信錯誤計數為072小時內沒有出現從站掉線情況。恆溫箱測試要注意一個細節測試板最好用延長線引出診斷串口和示波器探頭不然每次查看數據都要打開箱門溫度波動會影響測試有效性。另外電源也要儘量模擬現場的開關電源不要用實驗室的高精度線性電源否則會低估現場的電源噪聲影響。7.2 看門狗與恢復機制測試壓力測試還包括一個容易被忽略的環節死機自恢復。工業從站運行中難免遇到固件跑飛或者DSP死鎖的情況如果看門狗不能正常工作整個產線就要停工等人工復位。這一步的測試方式是運行中通過診斷接口人為觸發DSP死鎖觀察外部看門狗是否復位芯片復位後從站能否重新加載配置、重新進入OP狀態。FCP32C335內部有看門狗定時器建議在固件裡開啟並妥善配置。重點是看門狗的超時週期要大於正常主循環時間但又不能太長否則失去了保護意義。我測試時設置為200ms死鎖後約150ms復位整個恢復過程在500ms以內完成。還有一點系統復位後FCE1100會重新加載EEPROM配置如果EEPROM內容有誤或者加載不穩定就會出現「死鎖恢復後通信失敗」的現象。這個問題在正常運行時發現不了只有在復位測試中才會暴露。我建議在固件啟動流程裡加入一個標誌位如果檢測到異常復位就延長等待時間確保ESC完成EEPROM加載後再開始協議棧初始化。7.3 測試中總結的幾條注意事項整個功能板測試流程走完有一些關於FCE1100和FCP32C335組合搭配的注意事項是數據手冊裡寫得不明顯、但實際調試一定會碰到的。第一FCE1100的SPI從模式對片選信號的時序要求比傳統芯片更嚴。DSP配置SPI時要注意CPOL和CPHA的匹配最好先在示波器上確認時序波形確認數據採樣點沒有落在信號跳變邊沿再進行長時間通信測試。第二FCP32C335作為應用處理器內存資源並非無限豐富。SSC協議棧默認配置開啟了大量功能包括FoE、EoE、CoE等如果項目用不到建議在生成協議棧時關閉能明顯減少內存佔用和中斷處理時間。功能板上我把EoE直接關閉FoE保留用於固件升級CoE完整開啟運行穩定性比默認配置更好。第三國產芯片的寄存器手冊偶爾存在描述不完整的情況遇到無法解釋的寄存器行為時不要想當然地照搬國外芯片的經驗第一時間找原廠FAE確認同時用邏輯分析儀或者SPI抓包工具直接觀察實際讀響應值雙向驗證。第四量產測試不能依賴人工盯着主站界面。我建議搭建一套自動化測試腳本用SOEM或者TwinCAT的PLC程序自動完成狀態切換、PDO環回、錯誤計數統計、結果判定。每一塊板子測完之後產出一個標準化的測試日誌包含固件版本、EEPROM版本、測試時長、丟幀數、最大同步誤差等信息。這樣既能提高效率也方便追溯。最後還想分享一個小技巧在做長時間壓力測試時給主站側的腳本加一個「通信異常自動保存現場」的功能。一旦檢測到連續三個週期WKC錯誤立刻把當前的從站狀態、錯誤寄存器、最近一百個週期的PDO數據全部導出。很多偶發問題之所以查不出來是因為現場信息丟失等工程師去複現的時候條件已經變了。有了這份現場數據問題定位的難度會降低一個數量級。這次功能板測試下來整體印象是FCE1100加FCP32C335的組合作為一個國產化EtherCAT從站方案是站得住腳的。硬件底層的通信處理能力沒有明顯短板DSP側只要把中斷優先級、SPI配置和任務分配處理好完全可以支撐1ms到250us的通信週期。真正的工程量不在芯片本身而在於軟硬件邊界上的那些細節這也正是測試流程的價值所在。