今年年初老客戶那邊反饋設(shè)備在項目現(xiàn)場偶發(fā)網(wǎng)絡(luò)中斷而且部分設(shè)備重啟之后能恢復另一部分怎么重啟都連不上。這批設(shè)備的主控是 STM32F207跑著 FreeRTOS 加 lwIP以太網(wǎng)驅(qū)動還是當年從 ST 官網(wǎng)直接扒下來的 stm32f2x7_eth_driver配套標準外設(shè)庫一用就是五六年。借著這個契機我把 STM32F2x7 的 Ethernet 驅(qū)動鏈路完整更新了一遍順手解決了 PHY 換型后識別不了、大流量吞吐跑不滿兩個積壓已久的問題。整個過程踩了不少坑也把驅(qū)動從標準庫平滑挪到了 HAL 庫風格并重新梳理了與 FreeRTOS 的配合方式。這篇就從頭到尾把這個驅(qū)動更新的思路、關(guān)鍵差異和實測數(shù)據(jù)寫透給正在折騰 STM32F2x7 以太網(wǎng)的朋友一個可以直接抄的作業(yè)。1. 為什么舊驅(qū)動扛不住了性能瓶頸和新 PHY 的不兼容1.1 現(xiàn)場問題的三個典型表現(xiàn)先說最直觀的現(xiàn)場癥狀。老代碼在主控剛上電時一切正常能通過 DHCP 拿到地址也能和上位機保持 TCP 長連接但設(shè)備運行一兩天后偶爾會出現(xiàn) TCP 連接斷開且無法重連的情況。抓日志發(fā)現(xiàn)lwIP 的鏈路回調(diào)一直報 link down但 PHY 寄存器讀回來又顯示 link up兩個狀態(tài)互相矛盾。另一個硬件同事反饋因為原型號 PHY 停產(chǎn)采購把 PHY 換成了另一家的兼容型號結(jié)果 MDIO 讀不到芯片 ID驅(qū)動里基于原廠 PHY 的初始化邏輯完全失效。第三個問題更煩設(shè)備做 100M 以太網(wǎng)大文件傳輸測試時實際速度一直在 4 到 6 MB/s 徘徊和標稱 100Mbps 差了一大截。這三個問題表面看是不同故障實際都指向同一個根因舊版 stm32f2x7_eth_driver 太老了它是以 ST 早期的評估板驅(qū)動為藍本寫的對 PHY 的假設(shè)非常強輪詢方式也太粗糙。1.2 舊驅(qū)動在架構(gòu)上的硬傷我后來重新翻了舊驅(qū)動的代碼問題很清楚。它把以太網(wǎng) DMA 的收發(fā)邏輯放在一個 while 循環(huán)里輪詢DMA 描述符的 ownership 位靠 CPU 反復讀取判斷這本身體現(xiàn)不出來問題但當系統(tǒng)里同時跑著 FreeRTOS 的多個任務(wù)時輪詢以太網(wǎng)驅(qū)動會持續(xù)占用 CPU導致其他任務(wù)被餓死。而且舊驅(qū)動對 PHY 的寄存器初始化是寫死的它默認 PHY 的中斷引腳、復位引腳和 MDIO 地址都是評估板上的接法碰到實際產(chǎn)品里 PHY 引腳改過、PHY 換型號的情況第一步就卡住了。另外一個隱藏很深的坑是描述符結(jié)構(gòu)體。舊驅(qū)動把 ST 官方標準庫里的大結(jié)構(gòu)體直接暴露給應(yīng)用層如果應(yīng)用層代碼稍微改了幾個字段或者編譯器對齊方式不同DMA 描述符內(nèi)存布局就亂了。這類問題不會在編譯時報錯只會在運行一段時間后莫名其妙收不到數(shù)據(jù)。1.3 判斷你的項目是否也該做驅(qū)動更新不是所有項目都需要折騰驅(qū)動更新但如果命中下面幾條我建議盡早動手需要支持新的 PHY 芯片而當前驅(qū)動里沒有對應(yīng)初始化代碼網(wǎng)絡(luò)吞吐長期達不到理論帶寬的 80% 以上設(shè)備在長時間運行后出現(xiàn)網(wǎng)絡(luò)假死、連接斷開無法恢復ST 官方已經(jīng)停止維護你手里的標準外設(shè)庫版本新的 CubeMX 工具鏈無法直接生成兼容代碼想把網(wǎng)絡(luò)收發(fā)邏輯從裸機輪詢改成中斷驅(qū)動并更好地和 FreeRTOS 調(diào)度配合我當時項目四條全占這不做更新不行了。2. 更新前的資源盤點芯片絲印、PHY 芯片和 50MHz 時鐘鏈路2.1 先確認你手里的芯片具體是哪個型號STM32F2x7 是一個系列的說法具體到芯片常見的有 STM32F207VCT6、STM32F207VGT6、STM32F217VGT6。F207 和 F217 在以太網(wǎng)外設(shè)上完全一致區(qū)別主要在 Flash 大小、加密模塊和部分封裝引腳。真正要區(qū)分的是同一個封裝下 F205/215 和 F207/217 的差別前者沒有以太網(wǎng) MAC后者才有。網(wǎng)上很多教程直接寫 STM32F2x7 驅(qū)動默認都是帶以太網(wǎng)的型號。我這次手上的板子是 STM32F207VGT6100 引腳 LQFP內(nèi)部有 1MB Flash主頻跑 120MHz以太網(wǎng) MAC 支持 10M/100M帶獨立的 DMA 控制器。只有確認了具體絲印和參考手冊才敢照著寄存器手冊去改驅(qū)動否則后面一步錯步步錯。2.2 看原理圖明確 PHY 芯片型號與接口模式STM32F2x7 內(nèi)置以太網(wǎng) MAC 要接外部 PHY 芯片才能干活。PHY 和 MAC 之間的接口有兩種MII 和 RMII。MII 需要 16 根數(shù)據(jù)/控制線信號多但時序要求相對寬松RMII 只需要 7 根線但要求 PHY 提供 50MHz 的 REF_CLK 時鐘。我這次產(chǎn)品板子上用的是 RMII 接法PHY 是 Microchip 的 LAN8720A地址默認是 0也可以通過外部引腳拉成 1。原理圖上 PHY 的 REF_CLK 是從 STM32F207 的 MCO 引腳引過去的 50MHz。這種接法在低成本產(chǎn)品里非常常見但更新驅(qū)動時必須要確認 PHY 實際的 MDIO 地址和時鐘來源不要照抄評估板的配置。2.3 時鐘鏈路是這次更新里最容易踩的坑STM32F2x7 的以太網(wǎng) MAC 需要兩個時鐘源一個是系統(tǒng) AHB 總線時鐘用于 MAC 內(nèi)核寄存器訪問另一個是 RMII 模式下 PHY 提供的 50MHz REF_CLK。這里的坑在于lwIP 的 BSP 里面通常直接把 MAC 內(nèi)核時鐘頻率寫進 HAL_ETH_Init 的 pInit 結(jié)構(gòu)體里。如果系統(tǒng)主頻是 120MHzAHB 分頻后給 ETH 的是 60MHz 或 120MHz那么初始化以太網(wǎng) MAC 時必須把EthInitStructure.ClockRange或 HAL 對應(yīng)字段設(shè)置為匹配的值。我看到過有人把老驅(qū)動里的 25MHz 參數(shù)原樣拷到新板子上導致 MAC 收發(fā)數(shù)據(jù)包時偶發(fā)錯位表現(xiàn)就是 ping 大包總丟小包沒問題。這種問題用示波器查不到只能從配置參數(shù)上排查。2.4 復位引腳和中斷引腳不能省PHY 的復位引腳通常接到 MCU 的 GPIO有的產(chǎn)品直接接 RC 上電復位?？梢杂?GPIO 控制復位的話驅(qū)動初始化前先拉低再拉高確保 PHY 處于確定狀態(tài)。中斷引腳可選但我強烈建議留出來接到 MCU 的外部中斷上這樣 PHY 檢測到鏈路變化時可以主動通知 MCU而不必靠輪詢。舊驅(qū)動里如果沒接這個引腳程序只能靠周期讀 PHY 狀態(tài)寄存器判斷鏈路實時性差還容易漏事件。3. 新驅(qū)動文件落地從標準庫到 HAL 的關(guān)鍵差異與寄存器對照3.1 新舊驅(qū)動的文件結(jié)構(gòu)對比老項目用的是 ST 標準外設(shè)庫風格驅(qū)動文件是 stm32f2x7_eth.c 和 stm32f2x7_eth.h再加上應(yīng)用層的 ethernetif.c。新版驅(qū)動換成 HAL 庫形式后核心文件是 stm32f2xx_hal_eth.c、stm32f2xx_hal_eth.h底層仍然依賴 stm32f2xx_hal_rcc.c 和 stm32f2xx_hal_gpio.c。兩者名字看上去都是 ETH但 API 設(shè)計完全不同不能直接改名替換。對比項舊驅(qū)動標準外設(shè)庫新驅(qū)動HAL 庫初始化入口ETH_Init(ETH_InitTypeDef*)HAL_ETH_Init(ETH_HandleTypeDef*)DMA 描述符管理直接操作 ETH_DMADescTypeDef 數(shù)組HAL 內(nèi)部管理 Tx/Rx 描述符鏈表PHY 讀寫直接 MDIO 寄存器操作HAL_ETH_ReadPHYRegister / WritePHYRegister中斷處理ETH_IRQHandler 手動清標志HAL_ETH_IRQHandler 統(tǒng)一分發(fā)鏈接狀態(tài)應(yīng)用層自己輪詢HAL_ETH_GetLinkState / 回調(diào)機制這個表格里的差異不是簡單的函數(shù)改名而是驅(qū)動邊界的變化。HAL 庫把很多細節(jié)封裝到了內(nèi)部應(yīng)用層代碼更干凈但代價是如果出了問題追蹤起來需要更熟悉 HAL 的實現(xiàn)方式。3.2 初始化流程的對應(yīng)關(guān)系舊驅(qū)動的初始化順序是使能 ETH 時鐘和 GPIO 時鐘配置 GPIO 復用功能然后調(diào)用 ETH_Init 一次性設(shè)置 MAC、DMA、描述符。新驅(qū)動的初始化順序類似但被拆成了多個步驟ETH_HandleTypeDef heth; heth.Instance ETH; heth.Init.MACAddr mac_addr; heth.Init.MediaInterface HAL_ETH_RMII_MODE; heth.Init.TxDesc (ETH_DMADescTypeDef *)tx_desc_array; heth.Init.RxDesc (ETH_DMADescTypeDef *)rx_desc_array; heth.Init.RxBuffLen 1536; HAL_ETH_Init(heth); HAL_ETH_ConfigMAC(heth, mac_init); HAL_ETH_ConfigDMA(heth, dma_init); HAL_ETH_Start_IT(heth);看起來步驟差不多但因為 HAL 的HAL_ETH_Init內(nèi)部會自動讀取 PHY 的 ID 寄存器如果 PHY 沒有正常復位或 MDIO 引腳配置不對這個函數(shù)會直接返回 HAL_ERROR。老驅(qū)動里通常沒有這么嚴格的檢查所以同樣的板子老代碼能跑新代碼初始化失敗先從 PHY 復位時序和 MDIO 引腳配置查起。3.3 描述符結(jié)構(gòu)DMA 能訪問到的內(nèi)存才行STM32F2x7 的以太網(wǎng) DMA 使用描述符鏈表管理收發(fā)緩沖區(qū)每個描述符由 4 個 32 位字組成。舊驅(qū)動習慣把描述符定義成一個全局數(shù)組編譯器放在哪兒都能用。新版驅(qū)動中描述符數(shù)組必須放在 DMA 可以訪問的內(nèi)存區(qū)域而且地址要按 4 字節(jié)對齊。我在這次更新里遇到了一個奇怪現(xiàn)象編譯過后程序燒進去能進網(wǎng)但發(fā)幾個包后 DMA 就卡死。查到最后是描述符數(shù)組被鏈接到了外部 SDRAM 的區(qū)域雖然地址落在 4 字節(jié)對齊的邊界但外部存儲器的訪問時序和以太網(wǎng) DMA 的 Burst 模式不匹配。解決辦法是把描述符數(shù)組放到內(nèi)部 SRAM使用__attribute__((section(.ARM.__at_0x20000000)))這類方式顯式指定位置同時確認緩沖區(qū)也做了對齊。__attribute__((aligned(4))) ETH_DMADescTypeDef tx_desc[ETH_TX_DESC_CNT]; __attribute__((aligned(4))) ETH_DMADescTypeDef rx_desc[ETH_RX_DESC_CNT]; __attribute__((aligned(4))) uint8_t rx_buff[ETH_RX_DESC_CNT][1536];這個習慣要養(yǎng)成不要依賴編譯器的默認放置。3.4 寄存器級避坑MACCR 和 DMABMR 的幾個位不能亂動如果 HAL 封裝不能滿足你的定制需求還是得回去翻寄存器。STM32F2x7 的以太網(wǎng)核心寄存器主要有 MACCR、MACFFR、DMAOMR、DMABMR 等。MACCR 里的 RE、TE 位控制 MAC 收發(fā)使能更新驅(qū)動時如果有人直接操作寄存器容易把之前配置的自動協(xié)商、回環(huán)模式這些位覆蓋掉。HAL 庫里面的HAL_ETH_ConfigMAC會按傳入?yún)?shù)設(shè)置這些位相對安全。DMABMR 里有兩個位需要特別注意FBFixed Burst和 DADMA Arbitration。開啟 FB 后 DMA 使用固定突發(fā)長度吞吐量會明顯提升但外部 SDRAM 或某些 AHB 橋不支持這種突發(fā)模式時會導致 DMA 傳輸失敗。這次調(diào)吞吐量時我把 FB 打開速度從 5MB/s 提到了 8MB/s但跑到高負載時偶爾卡死關(guān)掉 FB 后穩(wěn)定性恢復速度略降到 7MB/s。最終權(quán)衡下來還是開著 FB但把內(nèi)存區(qū)域放到了內(nèi)部 SRAM問題就消失了。3.5 PHY 驅(qū)動從寫死改成參數(shù)化舊驅(qū)動里 PHY 初始化是硬編碼的比如把 BCR 寄存器直接設(shè)置為 0x1000 開啟自動協(xié)商。不同 PHY 的寄存器布局雖然基本遵循 IEEE 802.3但廠商的擴展寄存器差異很大例如 LAN8720A 的 RXER 計數(shù)器、DP83848 的 LED 控制。新驅(qū)動里我建議把 PHY 驅(qū)動單獨拆出一個文件通過一個結(jié)構(gòu)體描述 PHY 的 MDIO 地址、ID、復位引腳、中斷引腳以及需要在初始化階段寫入的寄存器列表。這樣以后換 PHY 型號只需要改表的配置不用動驅(qū)動主流程。4. FreeRTOS 接管后的任務(wù)切換、中斷優(yōu)先級和 DMA 內(nèi)存規(guī)劃4.1 以太網(wǎng)驅(qū)動掛在任務(wù)里還是中斷里這個問題我在項目初期糾結(jié)了很久。舊驅(qū)動是純輪詢方式在 while 循環(huán)里不斷調(diào)用 ethernetif_input 處理接收包。升級驅(qū)動后如果仍然把接收邏輯放到一個高優(yōu)先級任務(wù)里它和主任務(wù)搶 CPU 的問題不會消失。更好的方案是把以太網(wǎng) DMA 接收中斷打開在中斷服務(wù)函數(shù)里只做兩件事清中斷標志、給 tcpip_thread 發(fā)信號量。真正的數(shù)據(jù)包解析、協(xié)議棧處理由 lwIP 的 tcpip_thread 完成。這樣以太網(wǎng)驅(qū)動不會占著 CPU 不放系統(tǒng)整體響應(yīng)更好。4.2 中斷優(yōu)先級配置不是越大越好越小反而危險FreeRTOS 的configMAX_SYSCALL_INTERRUPT_PRIORITY決定了哪些中斷可以調(diào)用 FreeRTOS 的 API。以太網(wǎng)中斷優(yōu)先級必須設(shè)置得比這個“安全閾值”更低也就是數(shù)值上更大否則中斷里調(diào)xSemaphoreGiveFromISR時可能破壞臨界區(qū)。STM32F2x7 使用 4 位優(yōu)先級數(shù)值從 0 到 150 最高。我項目里把configMAX_SYSCALL_INTERRUPT_PRIORITY設(shè)為 5ETH 中斷優(yōu)先級設(shè)為 6PHY 外部中斷設(shè)為 7。這樣保證以太網(wǎng)和 PHY 中斷都能正常調(diào)用 FreeRTOS 的 FromISR API同時又不和 systick、PendSV 沖突。#define configMAX_SYSCALL_INTERRUPT_PRIORITY 5 // HAL_NVIC_SetPriority(ETH_IRQn, 6, 0); // HAL_NVIC_SetPriority(ETH_WKUP_IRQn, 7, 0);4.3 中斷服務(wù)程序設(shè)計不要在中斷里搬數(shù)據(jù)以太網(wǎng)中斷觸發(fā)后DMA 已經(jīng)把數(shù)據(jù)放到了 rx_buff 數(shù)組里中斷里不需要再搬一次數(shù)據(jù)。我看到有些人習慣在中斷里調(diào)用 memcpy 把數(shù)據(jù)拷到另一個緩沖區(qū)這在低負載時沒問題但在高速收發(fā)時會導致中斷處理時間過長后續(xù)中斷被淹掉。正確做法是中斷里只設(shè)置一個標志并喚醒接收任務(wù)接收任務(wù)里再把 rx_buff 中的數(shù)據(jù)交給 lwIP 的 PBUF。如果使用零拷貝連 memcpy 都省掉直接把新分配的 pbuf 地址映射到 DMA 描述符緩沖區(qū)這需要更細致的內(nèi)存池設(shè)計。我這次更新先用了普通拷貝版本穩(wěn)定性優(yōu)先等測到性能瓶頸再考慮零拷貝。4.4 DMA 緩沖區(qū)內(nèi)存規(guī)劃內(nèi)部 SRAM 優(yōu)先STM32F207 內(nèi)部 SRAM 總共 128KB其中 64KB 是普通 SRAM164KB 是 SRAM2。以太網(wǎng) DMA 描述符和緩沖區(qū)放在 SRAM1 和 SRAM2 都能訪問但要注意 4 字節(jié)對齊。我最終給以太網(wǎng)驅(qū)動劃分的內(nèi)存布局如下項目起始地址大小說明Tx 描述符數(shù)組0x200000004 * 4B * 8 128BTX_DESC_CNT 8Rx 描述符數(shù)組0x200001004 * 4B * 8 128BRX_DESC_CNT 8Rx 數(shù)據(jù)緩沖區(qū)0x200002008 * 1536 12288B每個緩沖區(qū) 1536 字節(jié)FreeRTOS 堆棧其余 SRAM動態(tài)分配heap_4 管理不要把描述符和緩沖區(qū)放在 CCM RAM 里STM32F2 系列沒有 CCM 這種 DMA 不可訪問的區(qū)域但如果你用 F4 的代碼習慣可能會把內(nèi)存放到__attribute__((section(CCM)))F2 上沒有這個區(qū)編譯直接報錯。4.5 lwIP 內(nèi)存配置也要跟著驅(qū)動一起更新驅(qū)動更新容易忽略 lwIP 的配套參數(shù)。lwIP 的內(nèi)存池大小和 pbuf 數(shù)量如果太小網(wǎng)絡(luò)在高負載下一樣丟包。根據(jù) 1536 字節(jié)的 MTU我調(diào)整了以下幾個關(guān)鍵配置#define MEM_ALIGNMENT 4 #define PBUF_POOL_SIZE 16 #define MEMP_NUM_PBUF 16 #define MEMP_NUM_TCP_SEG 32 #define TCP_SND_BUF 8 * 1024 #define TCP_WND 16 * 1024 #define MEM_SIZE (12 * 1024)這些值不是越大越好因為每多一份內(nèi)存就少一分給應(yīng)用任務(wù)的空間。我實測下來8 個收發(fā)描述符加 16 個 pbuf 池在 100M 網(wǎng)絡(luò)下已經(jīng)能穩(wěn)定跑滿 90% 帶寬。5. 實測數(shù)據(jù)從能 Ping 通到穩(wěn)定 11.5MB/s 的調(diào)優(yōu)路徑5.1 第一步先把鏈路層調(diào)通別急著跑 TCP/IP更新驅(qū)動后的第一個測試不是 ping而是看 PHY 的鏈接狀態(tài)。我寫了一段最簡單的測試代碼上電后循環(huán)讀取 PHY 的 BSR 寄存器打印 link status 和 speed/duplex。確認link up后再用 MDIO 讀 PHY ID 寄存器和 datasheet 上的值對照。這一步通過后才去配置 MAC 和 DMA。如果這一步就卡住回去查 PHY 復位、MDIO 上拉電阻、REF_CLK 是不是真的有 50MHz 方波。特別是 REF_CLK我很推薦用示波器量一下比盲猜快得多。5.2 ping 通了但不穩(wěn)定描述符數(shù)量和中斷閾值的關(guān)系我當時第一次跑通 ping 后連續(xù) ping 10000 個包總有十來個包延遲偏高偶發(fā)丟包。排查了很久最終發(fā)現(xiàn)是 DMA 接收中斷觸發(fā)條件太激進。STM32F2x7 的 DMAOMR 寄存器里可以配置接收中斷在收到多少幀后觸發(fā)RTC 00每收到一幀都觸發(fā)RTC 01每收到兩幀觸發(fā)RTC 10每收到四幀觸發(fā)RTC 11每收到八幀觸發(fā)如果每幀都觸發(fā)CPU 中斷負載太高如果四幀觸發(fā)一次延遲又變大。我最后設(shè)置成兩幀觸發(fā)一次配合 FreeRTOS 的接收任務(wù)丟包率降到 0。5.3 用 iperf 測吞吐對比新舊驅(qū)動我在 PC 端用 iperf 測試 TCP 發(fā)送和接收吞吐設(shè)備端跑 lwIP 的 TCP echo 服務(wù)結(jié)果對比如下測試項舊驅(qū)動輪詢新驅(qū)動中斷 HALTCP 下行PC→設(shè)備5.2 MB/s11.5 MB/sTCP 上行設(shè)備→PC4.1 MB/s10.8 MB/sUDP 下行 1472B4.8 MB/s11.2 MB/sCPU 占用率滿速時87%41%11.5MB/s 大約等于 92Mbps已經(jīng)接近 100M 以太網(wǎng)的理論上限約為 11.8MB/s。優(yōu)化的主要功勞來自三塊中斷驅(qū)動替代輪詢、DMA 固定突發(fā)模式、FreeRTOS 的及時調(diào)度。舊驅(qū)動用輪詢方式不僅速度慢CPU 也被吃掉大半幾乎沒辦法同時跑其他任務(wù)。5.4 測試時長必須夠長別信五分鐘數(shù)據(jù)吞吐測試只能說明瞬時性能長期穩(wěn)定性是另一回事。我在調(diào)優(yōu)階段讓設(shè)備持續(xù)跑 TCP 發(fā)送、接收、雙向混合三種模式每種至少跑 12 小時。期間監(jiān)控任務(wù)棧高水位、FreeRTOS 堆剩余量、以太網(wǎng) DMA 描述符的使用情況。有個很值得注意的現(xiàn)象新驅(qū)動在剛啟動時表現(xiàn)很好但連續(xù)跑幾個小時后如果某個描述符狀態(tài)沒有及時清理接收方向會慢慢降速。這個問題在普通測試中看不出來必須跑長時間才能發(fā)現(xiàn)。根因是 HAL 的接收中斷處理里如果一幀數(shù)據(jù)校驗失敗描述符的 ownership 位沒有正確歸還給 DMA導致后續(xù)幀無法接收。處理辦法是在接收中斷里檢查描述符錯誤標志錯誤幀直接歸還描述符不做協(xié)議棧處理。5.5 用任務(wù)運行時間統(tǒng)計驗證調(diào)度合理性調(diào)優(yōu)最后我打開 FreeRTOS 的configGENERATE_RUN_TIME_STATS實際看每個任務(wù)占用 CPU 的百分比。tcpip_thread 在高負載時大約占 60% CPU接收任務(wù)占 20%主業(yè)務(wù)任務(wù)只占 10%剩下給空閑任務(wù)。這個分布說明以太網(wǎng)驅(qū)動已經(jīng)把大量工作交給了 lwIP 自己的線程沒有在主任務(wù)里阻塞太久整體調(diào)度是健康的。如果接收任務(wù)占滿 CPU多半是每次中斷后沒有及時給 tcpip_thread 讓出執(zhí)行權(quán)或者描述符數(shù)量太少導致接收任務(wù)頻繁空轉(zhuǎn)。6. 三個反復踩的坑以及我最終留下的穩(wěn)定配置6.1 PHY 復位時序?qū)е碌某跏蓟〉谝淮斡眯买?qū)動時HAL_ETH_Init老是返回 HAL_ERROR但同樣的硬件在舊驅(qū)動里明明能跑。我一度以為新驅(qū)動有問題后來抓了時序才發(fā)現(xiàn)PHY 的復位引腳是 RC 上電復位芯片上電后 PHY 需要十幾毫秒才能準備好 MDIO 通信。舊驅(qū)動沒有做 MDIO 讀操作自然感知不到這個時序問題新驅(qū)動在初始化 MAC 前會嘗試讀 PHY 的 ID所以 PHY 沒準備好就直接失敗了。解決辦法是在調(diào)用 HAL_ETH_Init 前加上延時并且讓驅(qū)動每次都主動控制 PHY 復位引腳HAL_GPIO_WritePin(PHY_RST_PORT, PHY_RST_PIN, GPIO_PIN_RESET); HAL_Delay(50); HAL_GPIO_WritePin(PHY_RST_PORT, PHY_RST_PIN, GPIO_PIN_SET); HAL_Delay(100);之后 MDIO 讀 PHY ID 一次通過。這個經(jīng)驗提醒我新驅(qū)動檢查更嚴格不代表兼容性更差它只是把以前被掩蓋的問題暴露出來了。6.2 中斷標志未清干凈導致的死循環(huán)HAL 庫版本的以太網(wǎng)中斷處理里如果沒有正確清除中斷標志會頻繁進入中斷表現(xiàn)為程序卡在HAL_ETH_IRQHandler中出不來。我遇到的情況是 ETH DMA 的接收中斷標志只清了一半導致進入中斷后馬上再次觸發(fā)。調(diào)試方法是在 KEIL 里打斷點觀察 ETH-DMASR 寄存器的值每次進入中斷后記錄哪些標志位被置 1。正常流程下應(yīng)該同時確認DMASR的 NIS 和 RIS 位被清除。HAL 庫的HAL_ETH_IRQHandler內(nèi)部會處理大部分標志但如果你在中斷里額外做了HAL_ETH_ReadPHYRegisterMDIO 操作會因為占用總線而延遲不要放在中斷里做。6.3 -O2 優(yōu)化等級下的描述符狀態(tài)異常這個坑比較隱蔽。程序在 -O0 下跑得好好的換成 -O2 優(yōu)化后網(wǎng)絡(luò)吞吐直接掉到原來的一半偶爾還出現(xiàn)發(fā)送卡死。查了幾天才發(fā)現(xiàn)編譯器認為描述符里的狀態(tài)字段在循環(huán)中不會被外部修改于是把某些讀取操作優(yōu)化掉了。DMA 硬件在后臺寫描述符CPU 讀到的卻是緩存的值。解決方法是把描述符結(jié)構(gòu)體里的狀態(tài)字段聲明成 volatile或者在讀取前加內(nèi)存屏障#define ETH_READ_DESC_OWN(desc) (((volatile ETH_DMADescTypeDef *)(desc))-Status)STM32F2 的 Cortex-M3 沒有數(shù)據(jù)緩存不像 F7/H7 那樣有 cache 一致性問題但在高優(yōu)化等級下編譯器對內(nèi)存訪問的重排和優(yōu)化仍會造成類似現(xiàn)象定義 volatile 是最穩(wěn)妥的處理。6.4 最終固化的穩(wěn)定配置經(jīng)過一周的折騰我把最終驗證過的配置整理成一張表之后換板子、換 PHY 都直接按這個模板套配置項取值說明HAL 庫版本STM32Cube_FW_F2_V1.27較新穩(wěn)定版lwIP 版本2.1.2配合 HAL 的 ethernetif 示例PHY 芯片LAN8720AMDIO 地址 0RMIIREF_CLKMCO 輸出 50MHz測量確認頻率穩(wěn)定Tx 描述符數(shù)8可調(diào)Rx 描述符數(shù)8可調(diào)Rx 緩沖區(qū)大小1536B對齊到 4 字節(jié)中斷優(yōu)先級ETH6, PHY7configMAX_SYSCALL_INTERRUPT_PRIORITY5DMA 突發(fā)模式Fixed Burst內(nèi)部 SRAM 時開啟lwIP PBUF_POOL_SIZE16實測穩(wěn)定這套配置在壓力和長穩(wěn)測試下跑了半個月表現(xiàn)穩(wěn)定。最后說一句很實際的體會驅(qū)動更新最怕的不是代碼量大而是對底層機制理解不透徹碰到問題只能靠試。我在這次更新中最大的收獲其實是把 STM32F2x7 以太網(wǎng)從“黑盒”變成“灰盒”知道它怎么初始化、怎么搬數(shù)據(jù)、怎么和 FreeRTOS 配合之后再遇到網(wǎng)絡(luò)疑難雜癥至少知道往哪個方向查。希望這篇經(jīng)驗?zāi)軒湍闵僮邘撞綇澛贰?