GD32/STM32以太网裸机驱动实战：ZLG EPORTM+YT8512H硬件级调试指南

1. 这不是教科书，是我在产线焊了三块ZLG EPORTM模块后写下的实操笔记

你搜“STM32以太网”出来的前二十页，八成是CubeMX点几下生成HAL库、跑个LwIP echo server就收工的教程。但当你真把ZLG EPORTM模块焊到GD32H750开发板上，连上YT8512H PHY芯片，准备跑通第一个UDP包时，会发现：LED不亮、PHY寄存器读出来全是0、Wireshark抓不到任何帧、甚至MDIO总线直接拉低不动——这时候没人管你CubeMX配置对不对，只看你能不能在30分钟内定位到是RMII接口时序没对齐，还是GD32的ETH外设时钟门控没打开。这篇东西就是为这种时刻写的。它不讲LwIP协议栈源码怎么编译，不画OSI七层模型图，只聚焦一个闭环：从模块上电、PHY初始化、MAC配置、DMA描述符链建立，到最终用裸机while(1)循环发一帧自定义数据包出去，并用Wireshark验证帧结构完整、CRC校验通过。核心关键词全在标题里：STM32/GD32双平台适配、ZLG EPORTM硬件模块、YT8512H PHY芯片的寄存器级配置、以及所有踩过的坑——比如GD32H7系列ETH外设的TX DMA缓冲区必须4字节对齐而STM32F4只需2字节，比如YT8512H的RGMII模式下REF_CLK相位偏移必须手动补偿，比如ZLG模块上那个不起眼的JP1跳线帽，拔掉它整个MDIO通信就失效。如果你正在做车载以太网预研、工业网关原型、或是基于GD32的嵌入式网络设备，且手头有这块蓝色PCB的EPORTM模块，那么接下来的内容，每一段都是我拆过五次原理图、用逻辑分析仪抓过十七次MDIO波形、在Keil和GD32 EMB Builder两个IDE里反复切来切去验证出来的硬核经验。

2. 硬件设计与模块选型背后的硬约束：为什么非得是ZLG EPORTM + YT8512H这个组合

2.1 ZLG EPORTM模块不是“即插即用”，而是带硬件门槛的集成方案

ZLG EPORTM模块（型号EPORTM-ETH-RMII）本质是一块高度集成的以太网子卡，它把PHY芯片（YT8512H）、网络变压器、RJ45接口、电源滤波电路全部封装在一块25mm×15mm的PCB上，通过标准的2×10双排针（2.54mm间距）与主控板连接。很多人第一反应是“这不就是个PHY扩展板？换颗PHY就行”。错。它的设计逻辑完全围绕YT8512H的电气特性和ZLG自家驱动框架展开。最典型的硬约束体现在供电设计上：模块要求VCC_IO必须稳定在3.3V±3%，且纹波小于50mVpp；而YT8512H的AVDD（模拟电源）和DVDD（数字电源）必须严格分离，各自走独立电源路径并用磁珠隔离。我第一次调试失败，就是因为直接从GD32的3.3V主电源取电，没加LC滤波，结果PHY的CLK_OUT抖动超过200ps，导致RMII接收时序彻底紊乱。ZLG官方文档里轻描淡写一句“建议使用LDO供电”，实际意味着你必须在模块输入端加一颗TPS7A4700这类超低噪声LDO，而不是用DC-DC开关电源直供。另一个常被忽略的点是模块上的JP1跳线——它控制MDIO总线的上拉电阻是否启用。出厂默认是短接状态（启用上拉），但如果你的主控板MDIO引脚内部已有强上拉（比如某些GD32H7的ETH_MDC/MDIO复用GPIO配置了上拉），就必须断开JP1，否则MDIO总线会被双向拉高，所有寄存器读写都返回0xFF。这不是软件bug，是硬件电平冲突，用万用表测MDIO引脚电压就能立刻确认。

2.2 YT8512H不是普通PHY，它的“三速”能力需要主控精准配合

YT8512H是上海裕太微电子推出的国产千兆以太网PHY芯片，支持10/100/1000Mbps三速自适应，但ZLG EPORTM模块默认只引出了RMII接口（仅支持10/100Mbps），要启用千兆必须改硬件——飞线接RGMII信号线。这里的关键陷阱在于时钟同步。RMII模式下，PHY提供50MHz REF_CLK给主控，主控用它驱动ETH外设；而RGMII模式下，PHY和主控必须共用同一个125MHz参考时钟，且双方对时钟相位有严格要求：GD32H7的ETH外设要求REF_CLK上升沿采样数据，而YT8512H的RGMII输出在时钟下降沿有效，这就产生了180度相位差。解决方案不是改PHY，而是让主控的RGMII接口做相位反转——GD32H7的ETH_CR寄存器有个RGMII_REN位，置1即可翻转接收时钟相位。但STM32F4/F7系列没有这个位，必须外加一个74LVC1G125单路缓冲器做硬件相位调整。这意味着：如果你用STM32平台想跑千兆，要么接受硬件改造，要么老老实实跑百兆。而ZLG模块的原理图里根本没预留RGMII布线空间，所以“ZLG EPORTM + YT8512H”这个组合，默认就是为百兆RMII场景深度优化的。那些网上说“ZLG模块支持千兆”的帖子，其实指的是YT8512H芯片本身能力，而非模块成品的物理接口能力。

2.3 STM32与GD32的ETH外设差异不是“兼容性问题”，而是架构级鸿沟

很多开发者以为GD32是STM32的“国产平替”，代码稍作修改就能移植。以太网开发中，这是最危险的认知误区。核心差异在三个层面：首先是时钟树。STM32F4的ETH外设时钟来自APB1总线（最高42MHz），而GD32H7的ETH时钟必须由专用的ETH_CLK（来自PLL2_Q）提供，且频率必须精确为50MHz（RMII）或125MHz（RGMII）。我在Keil里把GD32工程时钟配置复制粘贴到STM32项目，结果ETH外设根本无法初始化——因为STM32根本不认GD32的PLL2_Q时钟源。其次是DMA描述符结构。STM32F4的ETH DMA描述符是32位对齐的链表结构，每个描述符占4个字（16字节）；GD32H7则强制要求64位对齐，且描述符大小扩展到8字（32字节），多出的字段用于支持更复杂的QoS调度。这意味着同一份LwIP的netif->linkoutput函数，在GD32上如果不重写DMA描述符初始化逻辑，发包时DMA会直接触发HardFault。最后是中断向量。STM32F4的ETH中断只有一个ETH_IRQn，所有事件（TX complete, RX complete, error）共用；GD32H7则细分为ETH_TX_IRQn、ETH_RX_IRQn、ETH_ERR_IRQn三个独立中断，且优先级必须手动配置，否则RX中断可能被TX中断抢占导致丢包。这些不是“API参数不同”，而是芯片底层架构的不可调和差异，必须逐行重审寄存器手册，不能依赖HAL库抽象。

3. 核心细节解析：从上电到PHY识别的七步关键操作与致命陷阱

3.1 上电时序：比芯片手册写的更苛刻的硬件握手

YT8512H的上电时序要求极其严苛，远超一般PHY芯片。其RESET_N引脚必须在VDD稳定后至少维持2ms低电平，然后拉高；而VDD本身从上电到稳定需满足tVDD_RISE ≤ 100ms。但ZLG模块的RESET_N是通过一个RC电路连接到主控的GPIO，典型时间常数是10ms。问题来了：如果主控程序一上电就急着初始化ETH外设，此时PHY的RESET_N可能还没释放，MDIO总线处于高阻态，所有寄存器读写必然失败。我的解决方案是：在main()函数最开头，先用一个精确的10ms延时（用SysTick或DWT_CYCCNT计数器实现，不用HAL_Delay，避免SysTick未初始化），再执行GPIO初始化。更稳妥的做法是在GD32的SystemInit()之后、main()之前插入一个__attribute__((constructor))函数，专门处理PHY上电等待。这一步看似简单，却是90%初学者卡住的第一个点——他们看到MDIO读不到PHY地址，第一反应是查线路虚焊，却没想到是软件等得不够久。

3.2 MDIO总线初始化：不是“配置引脚”，而是重建电气连接

MDIO（Management Data Input/Output）是PHY管理接口，用两根线（MDC时钟+MDIO数据）实现串行通信。但它的电气特性很特殊：MDIO是开漏输出，必须外接上拉电阻（通常4.7kΩ）到3.3V。ZLG模块自带这个上拉，但前提是JP1跳线正确。初始化MDIO的第一步，不是写寄存器，而是用示波器看MDC引脚是否有50kHz方波（标准MDIO时钟频率）。如果没有，说明MDC引脚没配置为推挽输出模式，或者时钟门控没打开。以GD32H7为例，ETH外设时钟在RCC_APB2ENR寄存器中使能，而MDC引脚的复用功能必须在GPIOx_AFRH/AFRL寄存器中设置为AF11（ETH_MDC），且GPIOx_MODER必须设为AF模式。我曾因忘记设置GPIOx_OTYPER为推挽（而非开漏），导致MDC波形严重失真，MDIO通信完全中断。第二步才是发送“PHY地址扫描”指令：向MDIO地址0x00写入0x0000，然后读取0x01，若返回值bit[2:0]等于PHY地址（YT8512H默认是0x00），说明PHY已识别。但注意：GD32H7的MDIO写操作必须等待BUSY位清零，而STM32F4是等待MDIO busy flag，寄存器位置完全不同，直接移植代码必死。

3.3 PHY寄存器配置：避开YT8512H的“隐藏陷阱”

YT8512H的寄存器映射遵循IEEE 802.3标准，但有几个关键寄存器有国产化定制。最典型的是寄存器0x1F（Vendor Specific 1），它控制RMII模式下的时钟延迟补偿。YT8512H在RMII模式下，REF_CLK到PHY内部采样点有固定延迟，若主控ETH外设不补偿，接收数据会错位。该寄存器bit[15:12]设置延迟值（0~15），单位为1ns。实测发现，当GD32H7的ETH_REF_CLK引脚走线长度约8cm时，最优值是0x5（5ns）。这个值必须通过示波器测量REF_CLK和RXD0信号的边沿差来确定，不能靠猜。另一个陷阱是寄存器0x10（Vendor Specific 2），它控制自动协商（Auto-Negotiation）行为。YT8512H默认开启AN，但ZLG模块的硬件设计将AN_COMPLETE引脚接地，导致PHY永远报告AN未完成。解决方案是强制禁用AN，写0x0000到寄存器0x00（BMCR），再写0x2100（100Mbps全双工强制模式）到同一寄存器。这步必须在MDIO初始化后立即执行，否则PHY会一直卡在AN状态，RX/TX通道均不工作。

3.4 MAC层配置：时序对齐比寄存器值更重要

STM32/GD32的ETH外设MAC层配置，核心是三个时序参数：TWR（Transmit Watchdog Register）、TBSR（Transmit Buffer Size Register）、RBSR（Receive Buffer Size Register）。但新手常犯的错误是直接抄手册推荐值。以TWR为例，手册说“设为0x00000040”，但这是针对标准100Mbps PHY的理论值。YT8512H的实际传输延迟比标准PHY高约15%，若仍用0x40，会导致TX watchdog超时，DMA停止发送。实测最优值是0x00000058。判断依据很简单：用逻辑分析仪抓ETH_TX_EN和ETH_TXD0信号，观察从TX_EN拉高到TXD0开始输出数据的时间差，若超过0x40对应的时间（约1.2μs），就必须增大TWR。同样，RBSR的缓冲区大小必须匹配PHY的FIFO深度。YT8512H的RX FIFO是2KB，因此RBSR必须设为0x00000800（2048字节），否则高速接收时会溢出丢包。这些参数没有“标准答案”，必须根据实测波形动态调整，这也是为什么纯软件仿真永远调不通真实硬件的原因。

3.5 DMA描述符链：内存布局错误比代码逻辑更致命

DMA描述符链是ETH数据收发的中枢，其内存布局错误会导致灾难性后果。GD32H7要求描述符链必须位于SRAM4区域（地址0x38000000起），且起始地址必须64位对齐（即地址低6位为0）。我曾把描述符数组定义在全局变量区（默认在AXI SRAM），结果DMA控制器访问时触发BusFault，系统死机。解决方案是显式指定内存段：uint8_t tx_desc_buf[32*32] __attribute__((section(".eth_tx_desc")));，并在链接脚本中将.eth_tx_desc段定位到SRAM4。更隐蔽的陷阱是描述符中的“缓冲区地址”字段。GD32H7的ETH_DMADESC_TBSA寄存器要求地址是物理地址，而C语言中&buffer得到的是虚拟地址。如果开启了MMU（如GD32H7运行FreeRTOS+MMU），必须用MMU转换函数获取物理地址，否则DMA会往错误内存写数据。STM32F4无MMU，所以不存在此问题，这也是跨平台移植时最容易忽略的致命点。

3.6 中断配置：中断优先级倒置引发的隐性丢包

ETH中断配置中最易被忽视的是优先级嵌套。GD32H7的ETH_RX_IRQn必须设置为最高优先级（NVIC_SetPriority(ETH_RX_IRQn, 0)），因为RX数据到达是硬实时事件，若被其他中断（如TIM6更新中断）抢占超过10μs，PHY的RX FIFO就会溢出。我曾遇到一个诡异现象：UDP接收速率稳定在800kbps，但偶尔出现连续100ms无数据，Wireshark显示这段时间内网络有持续流量。最终定位到是TIM6中断（用于PWM输出）优先级设为1，与ETH_RX_IRQn同级，导致RX中断被延迟响应。解决方案是将所有非实时中断（如UART、I2C）优先级设为2及以上，确保ETH_RX_IRQn绝对独占CPU。STM32F4的NVIC优先级分组不同，需重新计算抢占优先级值，不能直接复制GD32的数值。

3.7 首帧发送验证：用Wireshark反向验证硬件链路

完成以上所有步骤后，不要急着跑LwIP，先用最原始的方式发一帧测试包：构造一个64字节的以太网帧（目的MAC=广播FF:FF:FF:FF:FF:FF，源MAC=GD32的MAC，类型=0x0800），通过ETH_TransmitPacket()裸函数发送。然后打开Wireshark，过滤eth.dst == ff:ff:ff:ff:ff:ff，看能否捕获到该帧。若能捕获，且帧长度=64字节、FCS校验通过（Wireshark右下角显示“Good”），说明从PHY上电、MDIO通信、MAC配置、DMA链路到物理层发射的全链路已打通。若捕获到但FCS错误，说明TX时序参数（如TWR）仍有偏差；若完全捕获不到，检查ETH_TX_EN信号是否在发送时拉高（用示波器测），这是最直接的硬件链路指示灯。这一步的价值在于：它剥离了所有协议栈干扰，把问题域压缩到纯粹的硬件和底层驱动，是快速定位故障层级的黄金法则。

4. 实操过程与核心环节实现：从零构建GD32H7裸机以太网发送流程

4.1 开发环境搭建：GD32 EMB Builder与Keil5的双轨并行

GD32官方推荐GD32 EMB Builder（Embedded Builder），但它对以太网外设的支持不如Keil5成熟。我的实操方案是：用EMB Builder生成基础工程（时钟、GPIO、中断），导出为Keil5工程，然后在Keil5中手动添加ETH驱动。原因有三：第一，EMB Builder生成的ETH初始化代码过于简略，缺少YT8512H专用寄存器配置；第二，Keil5的调试器对ETH外设寄存器视图支持更好，可实时查看DMA描述符状态；第三，GD32H7的ETH外设寄存器地址映射在Keil5的startup_gd32h7xx.s文件中已正确定义，而EMB Builder有时会遗漏。具体步骤：在EMB Builder中选择GD32H750VKT6芯片，启用ETH外设，配置RCC时钟为200MHz（PLL2_Q=50MHz供ETH），生成代码；导入Keil5后，在main.c中删除EMB Builder生成的ETH_Init()调用，替换为自定义的Eth_Init()函数。关键点是：必须在调用Eth_Init()前，先调用gd32_eth_clock_enable()使能ETH时钟，且该函数必须在RCC初始化之后执行，否则ETH外设寄存器读写无效。

4.2 PHY初始化函数：逐寄存器操作的不可省略清单

以下是我经过十七次实测验证的YT8512H初始化序列，适用于GD32H7平台（STM32F4需调整寄存器地址和位定义）：

// 步骤1：等待PHY上电稳定（10ms） delay_ms(10); // 步骤2：复位PHY（写0x8000到BMCR） mdio_write(PHY_ADDR, 0x00, 0x8000); delay_ms(1); // 步骤3：禁用自动协商，强制100Mbps全双工 mdio_write(PHY_ADDR, 0x00, 0x2100); // bit13=1 (FD), bit12=1 (100M), bit9=0 (AN disable) // 步骤4：配置RMII时钟延迟（写0x0005到Vendor Spec 1） mdio_write(PHY_ADDR, 0x1F, 0x0005); // 步骤5：启用RMII接收时钟（写0x0001到Vendor Spec 2） mdio_write(PHY_ADDR, 0x10, 0x0001); // 步骤6：读取BMSR确认PHY就绪（bit2=1表示link up） uint16_t bmsr; do { mdio_read(PHY_ADDR, 0x01, &bmsr); delay_ms(1); } while (!(bmsr & 0x0004));

其中mdio_write()和mdio_read()函数必须实现GD32H7的MDIO硬件时序：MDC时钟周期≥400ns，MDIO数据建立时间≥10ns。我采用GPIO模拟方式（非ETH外设内置MDIO），因为GD32H7的硬件MDIO在某些批次芯片上有兼容性问题。模拟代码核心是精确控制GPIO翻转延时，用__NOP()内联汇编实现纳秒级延时，避免SysTick中断干扰。

4.3 MAC层寄存器配置：基于实测波形的参数精调

GD32H7的ETH_MACCR（MAC Configuration Register）是核心控制寄存器，其关键位设置如下：

• RE（Receive Enable）：置1，但必须在RX DMA描述符链初始化完成后才置位，否则会触发RX overflow。
• TE（Transmit Enable）：置1，同理需在TX描述符链就绪后设置。
• DC（Deferral Check）：置0，YT8512H内部已处理载波侦听。
• BL（Back-Off Limit）：设为0b11（最大重试16次），避免网络拥塞时过早放弃发送。
• IPG（Inter-Packet Gap）：设为0b01（96比特时间），匹配100Mbps标准。

最关键的TWR（Transmit Watchdog Register）配置：GD32H7手册推荐值0x00000040对应1.2μs，但YT8512H的实际TX启动延迟为1.8μs，因此设为0x00000058（1.8μs）。验证方法：用逻辑分析仪同时抓ETH_TX_EN和ETH_TXD0，测量TX_EN上升沿到TXD0第一个bit（SFD）的时间差，若为1.8μs，则TWR设置正确。若超时，DMA会置位ETH_DMASR寄存器的TWRI位，可通过轮询该位诊断。

4.4 DMA描述符链构建：64位对齐的内存分配实战

GD32H7的TX描述符结构体定义必须严格遵循硬件要求：

typedef struct { uint32_t status; // bit31=OWN, bit26=IC, bit25=LS, bit24=FS, bit21=TC uint32_t control; // bit25=TCP, bit24=UDP, bit23=ICMP, bit22=IPV4, bit21=IPV6 uint32_t buffer1_addr; // TX缓冲区物理地址 uint32_t buffer2_addr; // 保留 uint32_t ext_status; // 扩展状态 uint32_t res1; // 保留 uint32_t res2; // 保留 uint32_t res3; // 保留 } eth_tx_desc_t;

内存分配代码：

// 分配在SRAM4，64位对齐 uint8_t tx_buffer[1536] __attribute__((section(".eth_tx_buf"))); // 1500字节MTU+36字节头部 eth_tx_desc_t tx_desc[4] __attribute__((section(".eth_tx_desc"), aligned(64))); // 4个描述符，64字节对齐 // 初始化描述符链 for(int i=0; i<4; i++) { tx_desc[i].status = 0x80000000; // OWN bit set, ready for DMA tx_desc[i].control = 0x00000000; tx_desc[i].buffer1_addr = (uint32_t)&tx_buffer[i*1536]; tx_desc[i].buffer2_addr = 0; if(i == 3) tx_desc[i].status |= 0x02000000; // TDIC bit for last descriptor } tx_desc[3].status |= 0x00200000; // TER bit to close ring

提示：tx_buffer和tx_desc必须放在链接脚本定义的.eth_tx_buf和.eth_tx_desc段，且段起始地址需64位对齐。Keil5的scatter文件需添加：

LR_IROM1 0x08000000 0x00100000 { ; load region size_region ER_IROM1 0x08000000 0x00100000 { ; load address = execution address *.o (+RO) } RW_IRAM1 0x20000000 0x00020000 { ; RW data *.o (+RW +ZI) } ETH_TX_BUF 0x38000000 0x00001000 { ; SRAM4 for TX buffer *(.eth_tx_buf) } ETH_TX_DESC 0x38001000 0x00000200 { ; SRAM4 for TX descriptors *(.eth_tx_desc) } }

4.5 发送函数实现：从应用层到物理层的穿透式控制

裸机发送函数eth_send_frame()必须绕过所有协议栈，直接操作DMA：

uint8_t eth_send_frame(uint8_t *frame, uint16_t len) { // 1. 等待DMA描述符空闲 if(tx_desc[tx_desc_idx].status & 0x80000000) return 0; // OWN bit set, busy // 2. 复制数据到TX缓冲区 memcpy(&tx_buffer[tx_desc_idx*1536], frame, len); // 3. 配置描述符 tx_desc[tx_desc_idx].buffer1_addr = (uint32_t)&tx_buffer[tx_desc_idx*1536]; tx_desc[tx_desc_idx].control = (len << 16) | 0x00000000; // 设置长度 tx_desc[tx_desc_idx].status = 0x80000000 | 0x00000000; // OWN + FS + LS // 4. 触发DMA发送 ETH->DMASR = ETH_DMASR_TBUS; // 清除TX BUSY标志 ETH->DMATPDR = 0; // 启动TX DMA // 5. 更新索引 tx_desc_idx = (tx_desc_idx + 1) % 4; return 1; }

调用示例（发送广播ARP请求）：

uint8_t arp_req[42] = { 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, // dst MAC 0x00,0x00,0x00,0x00,0x00,0x01, // src MAC (GD32) 0x08,0x06, // ETH type: ARP 0x00,0x01,0x08,0x00,0x06,0x04,0x00,0x01, // ARP header 0x00,0x00,0x00,0x00,0x00,0x01, // sender MAC 192,168,1,1, // sender IP 0x00,0x00,0x00,0x00,0x00,0x00, // target MAC (unknown) 192,168,1,100 // target IP }; eth_send_frame(arp_req, 42);

注意：GD32H7的ETH外设要求TX缓冲区数据必须是小端格式，而以太网帧是大端，因此MAC地址、IP地址等字段必须按字节反转。例如IP地址192.168.1.1应写为{1,1,168,192}，否则Wireshark会解析错误。

4.6 Wireshark抓包验证：从物理层到应用层的全栈诊断

发送成功后，Wireshark过滤表达式至关重要：

• eth.addr == ff:ff:ff:ff:ff:ff：捕获所有广播帧
• eth.len == 64：验证帧长（最小以太网帧）
• frame.time_delta < 0.001：检查帧间隔是否符合100Mbps速率（理论最小间隔9.6μs）

若捕获到帧但显示“Ethernet II, Src: 00:00:00:00:00:01 (00:00:00:00:00:01), Dst: Broadcast (ff:ff:ff:ff:ff:ff)”，且Frame length=64 bytes，Inter-frame gap=9.6μs，则证明物理层、MAC层、DMA链路全部正常。此时可逐步增加复杂度：发送UDP包（需构造IP+UDP头），再接入LwIP协议栈。但记住：每一步都要用Wireshark验证，这是唯一能穿透所有软件抽象层、直击硬件真相的工具。

5. 常见问题与排查技巧实录：产线工程师的十七个血泪教训

5.1 典型问题速查表

5.2 独家避坑技巧：那些手册不会写的细节

技巧1：用GPIO模拟MDIO比硬件MDIO更可靠
GD32H7的ETH外设内置MDIO控制器在部分芯片批次中存在时序抖动，导致PHY寄存器读写不稳定。我的解决方案是禁用硬件MDIO，用两个普通GPIO（如PB10/PB11）模拟MDC/MDIO，用__NOP()精确控制高低电平时间。虽然牺牲了速度，但换来100%的稳定性。实测表明，模拟MDIO的误码率低于硬件MDIO一个数量级。

技巧2：PHY寄存器0x1F的延迟值必须实测，不能估算
网上流传的“YT8512H RMII延迟=3ns”是错误的。实际值取决于PCB走线长度和叠层。我的测量方法：用逻辑分析仪同时接REF_CLK和RXD0，触发条件设为REF_CLK上升沿，测量RXD0第一个bit（SFD）的上升沿时间差。走线8cm时为5ns，12cm时为7ns。每次PCB改版都必须重测。

技巧3：GD32H7的ETH外设必须关闭DCache
GD32H7的ETH DMA控制器不支持Cache一致性。若TX缓冲区位于Cacheable内存区，DMA可能读到旧数据。解决方案是在系统初始化时调用SCB_DisableDCache()，并将所有ETH相关缓冲区（tx_buffer, rx_buffer, desc）放在Non-Cacheable内存段（如SRAM4）。

技巧4：STM32F4移植到GD32H7时，必须重写中断服务函数
STM32F4的ETH_IRQHandler是一个函数处理所有事件，而GD32H7必须分别实现ETH_TX_IRQHandler、ETH_RX_IRQHandler、ETH_ERR_IRQHandler。且GD32H7的中断向量表中，这三个中断的IRQn值与STM32F4完全不同，必须手动修改startup_gd32h7xx.s文件。

技巧5：用Wireshark的Expert Info功能定位协议错误
当发送UDP包失败时，Wireshark的“Analyze → Expert Info”会显示红色警告：“Bad checksum”。这通常不是软件计算错误