1. 先把ETH外设这件事拆开看MAC、DMA、PHY到底谁干什么很多人第一次在STM32上点以太网卡住的地方往往不是代码而是压根没搞明白这颗芯片里的ETH外设边界在哪。STM32的ETH是一个MAC控制器它负责的是数据链路层那一摊事帧的组装和拆解、前导码和SFD的识别、CRC32的生成与校验、地址过滤、冲突检测、退避重传。它不含PHY也就是说它管不到电平、管不到双绞线上的曼彻斯特编码更管不到RJ45接口上的变压器。PHY是板子上那颗独立芯片MAC和PHY之间靠MII或者RMII这根总线连着。这条边界一定要先划清楚否则后面调试时会一直在错误的地方找问题。我的经验是把整条链路想成一条流水线RJ45进来的是差分模拟信号PHY把它变成数字的MII/RMII时序MAC把时序变成帧DMA把帧搬进内存lwIP在内存里解析出IP包最后交给你的socket回调。任何一个环节断了现象都是ping不通但原因可能天差地别。所以定位问题的第一步永远是分层而不是盲改代码。1.1 MAC与DMA为什么必须有DMA以太网帧最小64字节、最大1518字节不带VLAN标签千兆以下速率下每秒可能来上万帧。如果每个字节都让CPU去读寄存器CPU基本就废了。所以STM32的ETH内部集成了一个专用的DMA引擎它和MAC之间是内部总线直连和系统内存之间通过总线矩阵访问SRAM。DMA的工作方式是基于描述符环Descriptor Ring。你在内存里开辟一段连续的描述符数组每个描述符32位×4个字TDES0~TDES3或RDES0~RDES3里面记录了本帧的缓冲区地址、长度、以及各种状态位和中断位。DMA自己维护一个当前指针发送和接收各一套环。CPU只需要把要发的帧放进缓冲区然后置位描述符的OWN位表示这个描述符归DMA所有了剩下的搬运工作DMA自己完成。这个设计带来一个必须注意的后果描述符和缓冲区所在的内存区域其访问属性必须和DMA的访问方式一致。在带Cache的核比如Cortex-M7上如果这块内存是可缓存的CPU写进去的数据可能还躺在D-Cache里没落到SRAMDMA读到的就是旧数据反过来DMA把收到的帧写进SRAMCPU从Cache里读到的又是旧内容。这是新手在H7系列上最常踩的坑后面第3章会专门讲MPU配置怎么处理。1.2 MII和RMII省下的那16根线值不值MII是标准接口发送接收各4位数据线加上TX_CLK、RX_CLK、TX_EN、TX_ER、RX_DV、RX_ER、CRS、COL一共十几根。RMII是精简版数据线砍到2位时钟统一成一根50MHz的REF_CLK引脚数降到7根左右。选RMII几乎是必然的理由很实际引脚省下来了PCB好布而且大部分常用PHY都支持RMII。代价是REF_CLK必须是50MHz、精度±50ppm这个时钟的质量直接决定链路稳定性。我见过因为用了普通晶振分频出来的50MHz、抖动偏大导致跑一段时间就出现CRC错误的案例。MII只在两种情况下值得考虑一是需要10/100M全双工且对时序余量要求极高二是某些老PHY只支持MII。除此之外RMII是默认选择。1.3 描述符与缓冲区的内存布局规划在动手写代码之前先在链接脚本或者内存规划表里给ETH留一块地。以常见的F4系列为例典型配置是项目数量单元大小占用发送描述符416字节64字节接收描述符416字节64字节发送缓冲区41524字节6096字节接收缓冲区41524字节6096字节合计约12KB。这个量在SRAM里不算小尤其是F407只有128KB64KB CCM的情况下得提前算清楚。描述符数组必须32位对齐缓冲区建议也按4字节对齐某些系列如H7甚至要求描述符地址按32字节对齐以避免Cache行撕裂。注意缓冲区大小建议取1524或1536不要图省事取1518。多出来的几个字节是为了容纳VLAN标签和可能的对齐填充某些交换机会发出带标签的帧缓冲区不够会被DMA直接截断并置错误位。2. 硬件设计原理图阶段就该定死的东西以太网这部分硬件一旦打板出错软件怎么调都是白费。我在实际项目里见过太多代码查了三天最后发现是PHY地址strap电阻贴错的情况。所以这一章讲的都是原理图评审时该盯住的点。2.1 PHY选型的几个现实考量市面上常用的RMII PHY不少选型时别看参数表上写的工业级低功耗重点看四件事时钟输出能力、strap引脚定义、寄存器兼容性、封装和供货。型号接口时钟方案地址配置备注LAN8720ARMII外接25MHz晶振REF_CLK输出50MHzPHYAD0引脚strap0x00或0x01用量大资料多注意它没有MIIDP83848MII/RMII需外部提供50MHzPHYAD[4:0]引脚strap老牌方案功耗略高KSZ8081RMII外接25MHz输出50MHz通过strap引脚或MDIO配置支持线缆诊断YT8512RMII外接25MHzstrap引脚国产替代寄存器基本兼容选型时我一般会先确认一件事这颗PHY的REF_CLK是输出还是输入。LAN8720A默认是从25MHz晶振分频出50MHz给MAC用此时STM32的ETH_REF_CLK配置为输入模式有些PHY需要MAC提供50MHz那就要用STM32的MCO输出这时候MCU的主频和MCO分频必须算准MCO的抖动也比专用晶振差一截。2.2 时钟方案50MHz这根线值得单独画一页RMII的REF_CLK是整条链路的节拍器。它的频率容差要求±50ppm占空比40%~60%上升沿要干净。三种常见来源对比PHY的25MHz晶振分频输出最稳晶振精度天然满足走线也短。这是首选。MCU的MCO输出50MHz省一颗晶振但MCO是从PLL分频出来的抖动大长距离走线容易劣化。只在板子空间极度紧张时用。独立50MHz有源晶振成本高但精度最好适合多PHY或者对同步有要求的场景。25MHz晶振的负载电容要按晶振规格书算别照抄参考设计。我遇到过一批板子用12pF负载电容配了标称18pF的晶振起振勉强但频率偏了表现为链路能起来但大流量下丢包。2.3 差分走线与变压器不是能通就行TX±和RX±是100Ω差分对走线要求差分对内等长误差控制在5mil以内。差分对之间保持足够间距至少3倍线宽避免串扰。尽量不走层间换层必须换层时在旁边加回流地过孔。走线远离晶振、DC-DC、复位线。变压器这块常用的是1:1隔离变压器中心抽头接法分电压型和电流型PHY两种。LAN8720A是电压型驱动TX侧中心抽头接3.3V并通过0.1μF去耦DP83848偏电流型接法不同。这一条接错链路指示灯可能亮但就是收不到包。我在评审原理图时这一项永远单独圈出来确认。RJ45建议用集成变压器的连接器省事且一致性更好。外壳地SHIELD通过1nF/2kV电容和RC网络连到数字地防静电也防地环路。接口侧再加TVS阵列做防护尤其是外露的场景。2.4 复位、strap与中断引脚PHY的复位至少要拉低10ms以上具体看手册。复位释放后到MDIO可访问还要等几十毫秒的内部初始化。如果MCU启动比PHY快第一次读PHY寄存器会读回0xFFFF很多人以为是MDIO坏了其实是时序问题。稳妥做法是复位后延时100ms再初始化MAC。Strap引脚决定PHY的MDIO地址、是否自协商、是否全双工。这些引脚在复位期间被采样所以上拉下拉电阻的阻值要按手册给的范围取一般4.7kΩ到10kΩ。我自己踩过的坑是PHYAD0上拉用了100kΩ理论上够但因为走线旁边有个强驱动信号耦合采样时被拉低了一瞬地址变成0x01软件按0x00去读自然读不到。中断引脚建议接上虽然轮询也能跑但链路状态变化插拔网线用中断响应更及时。如果引脚紧张至少保证能通过轮询PHY的BMSR寄存器检测Link Up。3. CubeMX配置从引脚到参数一项一项抠CubeMX确实能省不少事但它生成的以太网代码有几个默认值是不能直接用的尤其是内存相关的配置。这一章按配置顺序讲每一项都说明为什么这么设。3.1 时钟树与引脚分配的核对顺序配置顺序我习惯是先定系统时钟再开ETH最后配lwIP。原因是以太网的时序依赖系统时钟尤其RMII的REF_CLK如果是MCO输出的PHY和MAC的时钟必须同源。以常见的F407为例典型配置是HSE 8MHzPLL到168MHzETH时钟来自PLL的48MHz那一路ETH_PTP_CLK。RMII模式下CubeMX里PHY Interface选RMIIAuto Negotiation使能RX Mode和TX Mode都选轮询或中断一般选中断Checksum offload建议开能减轻CPU负担。引脚上会自动分配PA1REF_CLK、PA2MDIO、PA7CRS_DV、PC1MDC、PC4RXD0、PC5RXD1、PB11TX_EN、PB12TXD0、PB13TXD1。这里有个细节PA1在RMII模式下是REF_CLK输入此时它必须配置成复用功能而不是普通GPIO手册里对它的模式有明确要求CubeMX会自动处理但如果你手动改过引脚配置回头检查一下。3.2 ETH参数逐项解析参数默认值建议值说明Auto NegotiationEnableEnable让PHY自己协商速率和双工Speed100M100M自协商失败时的兜底Duplex ModeFullFull半双工会引入冲突尽量不用RX/TX Descriptor count44~8数量多能缓冲突发但吃内存Buffer size15241524与前面规划一致Checksum offloadDisableEnable硬件算校验省CPU描述符数量我在资源紧张时用4资源宽松时用8。数量太少接收突发时容易丢帧太多中断处理延迟会变大。这没有标准答案得看你实际的流量模型。3.3 LwIP配置默认1600字节的堆根本不够CubeMX里LwIP的默认MEM_SIZE是1600这个值只能跑通ping稍微用一下TCP就内存耗尽返回ERR_MEM。我一般这么改#define MEM_SIZE (16 * 1024) // 堆TCP发送/接收缓冲都从这里分 #define MEMP_NUM_PBUF 16 #define MEMP_NUM_TCP_PCB 8 #define MEMP_NUM_TCP_SEG 32 #define PBUF_POOL_SIZE 16 #define PBUF_POOL_BUFSIZE 1524 #define TCP_MSS 1460 #define TCP_SND_BUF (4 * TCP_MSS) #define TCP_WND (4 * TCP_MSS) #define LWIP_DHCP 0 // 调试期先关静态IP更可控 #define LWIP_NETIF_LINK_CALLBACK 1这里解释几个关键值。TCP_MSS取1460是因为1500的MTU减去20字节IP头减20字节TCP头。TCP_SND_BUF取4倍MSS意味着最多能有4个满尺寸段在途这是能跑出稳定吞吐量又不吃太多内存的折中。PBUF_POOL_SIZE和PBUF_POOL_BUFSIZE决定接收队列如果网络上有大量小包池子小了会丢包。提示MEM_SIZE里的内存在lwIP里是统一管理的一块堆所有pcb、pbuf的头部都从这里分。16KB能应付中小流量如果要跑大文件传输建议拉到32KB甚至更多同时配合内存池一起看占用。3.4 生成代码后必须手改的几处CubeMX生成的代码在MX_ETH_Init()里已经配好了MAC但有几个地方它管不到第一描述符和缓冲区的对齐和内存属性。在F4上直接静态定义全局数组即可编译器和链接器会按4字节对齐。在H7上必须做MPU配置把描述符区比如0x30040000开始的区域配置为Device或Non-cacheable或者每次收发前后手动做Cache Clean/Invalidate。后者性能损失大前者更干净MPU_Region_InitTypeDef MPU_InitStruct {0}; HAL_MPU_Disable(); MPU_InitStruct.Enable MPU_REGION_ENABLE; MPU_InitStruct.BaseAddress 0x30040000; MPU_InitStruct.Size MPU_REGION_SIZE_32KB; MPU_InitStruct.AccessPermission MPU_REGION_FULL_ACCESS; MPU_InitStruct.IsBufferable MPU_ACCESS_NOT_BUFFERABLE; MPU_InitStruct.IsCacheable MPU_ACCESS_NOT_CACHEABLE; MPU_InitStruct.TypeExtField MPU_TEX_LEVEL1; MPU_InitStruct.SubRegionDisable 0x00; MPU_InitStruct.DisableExec MPU_INSTRUCTION_ACCESS_DISABLE; HAL_MPU_ConfigRegion(MPU_InitStruct); HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);第二PHY地址。CubeMX默认填0如果你的板子strap成了0x01这里必须改或者用扫描的方式自动探测。第三链路状态回调。打开LWIP_NETIF_LINK_CALLBACK之后实现netif_set_link_callback在网线插拔时重新触发DHCP或者重设接口状态否则插拔后要重启才能恢复。4. lwIP真正跑起来从ping通到业务可用ping通只是起点离业务可用还有段距离。这一章讲初始化顺序、常见吞吐量瓶颈和最小可用骨架。4.1 初始化顺序错一步全盘皆输正确的顺序是上电等待系统时钟稳定拉低PHY复位至少10ms释放后再延时100msMX_ETH_Init()配置MAC和DMA启动自协商轮询或者等中断确认Link Up读PHY状态得到速率和双工MX_LWIP_Init()创建netif设置IP进入主循环定期调用MX_LWIP_Process()裸机或让线程自然运行RTOS第4步是最容易漏的。如果Link还没起来就初始化lwIPnetif会处于DOWN状态DHCP永远超时。有些项目的做法是在MX_LWIP_Init()之后加一个while循环等Link但这样会阻塞启动。更好的做法是注册链路回调在回调里处理。4.2 静态IP还是DHCP调试期怎么选调试阶段我强烈建议先用静态IP。理由很直接DHCP会引入额外变量如果DHCP失败你分不清是网络问题还是DHCP服务器问题。静态IP配置简单IP4_ADDR(ipaddr, 192, 168, 1, 200); IP4_ADDR(netmask, 255, 255, 255, 0); IP4_ADDR(gw, 192, 168, 1, 1); netif_set_addr(gnetif, ipaddr, netmask, gw);注意PC端也要在同一网段并且关闭PC的防火墙或者放行ICMP。我见过不止一次ping不通最后发现是Windows防火墙拦了回复包。静态IP跑通之后再切DHCP验证。切的时候注意dhcp_start()必须在netif link up之后调用另外DHCP过程中如果超时检查一下是不是路由器开了AP隔离。4.3 吞吐量的三个瓶颈点很多人跑通之后发现TCP速率只有几百KB/s远低于100M的理论值。实际瓶颈通常在这三处瓶颈一MX_LWIP_Process()的调用频率。裸机下这个函数要尽可能频繁地调用如果主循环里有大延时收包会积压。我用过的最低要求是每1ms调一次。瓶颈二拷贝次数。从ETH DMA缓冲区到lwIP的pbuf如果配置成ETH_RX_BUFFER直接给lwIP用zero-copy能省一次memcpy。CubeMX默认是拷贝模式改动需要调整ethernetif.c里的low_level_input。瓶颈三TCP_SND_BUF和窗口大小。对端窗口小发送方就得等ACK。把TCP_WND和TCP_SND_BUF都提到4~8倍MSS吞吐量能明显上来。我实测过一组对比同一块板、同一台PC直连配置单向吞吐默认MEM_SIZE 1600SND_BUF 2×MSS约 3~5 MbpsMEM_SIZE 16KSND_BUF 4×MSS约 35~45 MbpsMEM_SIZE 32KSND_BUF 8×MSSzero-copy约 70~85 Mbps最后一档已经接近100M的实际上限了剩下的差距主要是协议栈开销和CPU主频。4.4 一个能直接用的TCP echo骨架把下面这段贴进main.c的初始化之后就能验证整条链路static err_t echo_recv(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err) { if (p NULL) { tcp_close(tpcb); return ERR_OK; } tcp_recved(tpcb, p-tot_len); tcp_write(tpcb, p-payload, p-tot_len, TCP_WRITE_FLAG_COPY); tcp_output(tpcb); pbuf_free(p); return ERR_OK; } static err_t echo_accept(void *arg, struct tcp_pcb *newpcb, err_t err) { tcp_recv(newpcb, echo_recv); return ERR_OK; } void echo_init(void) { struct tcp_pcb *pcb tcp_new(); tcp_bind(pcb, IP_ADDR_ANY, 7); pcb tcp_listen(pcb); tcp_accept(pcb, echo_accept); }PC端用telnet 192.168.1.200 7或者任意TCP工具连上去发什么回什么说明MAC、DMA、lwIP、协议栈全通了。这个骨架的价值在于它把变量降到最少如果这个都跑不通问题一定在底层。5. 调试实录那些让人抓狂的现象和它们的真凶这一章是我这些年攒下来的排查表按现象分类基本覆盖了90%的以太网问题。5.1 链路都起不来现象PHY的Link灯不亮或者亮了但读BMSR寄存器的Link位一直是0。排查顺序先量PHY的供电和复位电平确认复位已经释放再量25MHz晶振是否起振用示波器看万用表测不准然后确认MDC/MDIO上有没有波形如果没有说明MAC根本没发起MDIO事务回头查ETH初始化有没有执行到如果有波形但读回全0xFF检查PHY地址对不对。我遇到过一个特别隐蔽的PHY的复位引脚接在MCU的GPIO上但CubeMX里那个GPIO被配置成了模拟输入浮空状态下PHY一直处于复位。改回推挽输出就正常了。5.2 ping不通但Link是Up的这是最常见的一类。排查步骤检查项方法常见问题MAC地址读寄存器或打印全0或全FF会被交换机丢弃IP网段对比PC和板子掩码不一致导致跨网段ARPPC上arp -a板子没回ARP说明接收链路没通防火墙临时关闭ICMP被拦收发计数读ETH的DMA统计收有计数发没计数说明发送描述符没提交读DMA统计寄存器是最有信息量的一步。ETH_DMARXPKT在涨但ETH_DMATXPKT不动说明收方向通了、发方向有问题重点查发送描述符的OWN位有没有正确置位以及TX_EN引脚有没有输出。5.3 小包正常、大包丢ping 32字节能通ping 1472字节就不通或者TCP传大文件一会儿就断。这类问题的根源通常是缓冲区不够或者Cache一致性。先确认PBUF_POOL_BUFSIZE是否≥1524再看接收描述符数量是不是太少导致突发丢帧。H7上还要重点查Cache如果描述符区是可缓存的CPU看到的OWN位可能是Cache里的旧值导致DMA和CPU对同一个描述符的理解不一致表现出来就是随机丢包。判断方法很土但有效把MPU配置成Non-cacheable再跑一遍如果问题消失那就是Cache的事。5.4 跑几个小时就挂这类问题最耗时间因为复现周期长。常见原因有三个第一个是内存泄漏。lwIP里pbuf用完必须pbuf_freetcp_recved也必须在对的地方调。漏一次不显眼跑几小时pbuf池就空了。建议打开LWIP_STATS和MEM_STATS定期打印剩余量。第二个是描述符环指针越界。DMA的当前指针如果跑到环外面整个收发就停了。这个一般是初始化时环的长度配置和实际数组长度不一致导致的。第三个是PHY自协商抖动。某些劣质网线或者RJ45接触不良链路会反复Up/Down每次Down都触发一次lwIP重连久而久之资源耗尽。对策是在链路回调里加去抖连续N次检测到Down才真正处理。心得长时间稳定性测试我一般跑24小时同时用脚本每10秒ping一次并记录丢包率。丢包率超过0.1%就要查别等到客户现场才暴露。6. 几条用血换来的经验写在这里省你几天第一先让硬件说话再让软件说话。板子回来第一件事不是烧程序是量电源、量晶振、量复位、看Link灯。硬件层面没确认软件调一天都是白搭。第二MDIO扫描是个好习惯。初始化时遍历0~31号地址读PHYID寄存器把读到的地址打印出来能省掉大量地址配错的排查时间。这几十行代码我每个项目都带着。第三把DMA统计寄存器做成调试命令。收包数、发包数、CRC错误数、溢出数、描述符错误数这几个数字一摆出来问题范围立刻缩小一半。比起加打印这个成本低得多。第四别迷信CubeMX生成的默认值。它给的是一个能编译能跑的配置不是能用在产品上的配置。内存、描述符数量、TCP窗口这些参数必须按你的实际流量重新算一遍。第五RMII的50MHz时钟用示波器看一眼。频率、峰峰值、上升时间一分钟的事能排掉一大批玄学问题。我现在的习惯是每个以太网板子首件都要看这根线看过的板子里大概有两成时钟质量不达标问题都出在晶振负载电容或者走线太长。最后说个扩展方向如果项目对实时性有要求可以把ETH的中断优先级调高并把lwIP跑在独立的RTOS线程里配合信号量唤醒比裸机轮询的响应确定性要好得多。不过线程优先级和栈大小要试栈给小了会在处理大包时溢出这个坑我也踩过。
1. 先把ETH外设这件事拆开看MAC、DMA、PHY到底谁干什么很多人第一次在STM32上点以太网卡住的地方往往不是代码而是压根没搞明白这颗芯片里的ETH外设边界在哪。STM32的ETH是一个MAC控制器它负责的是数据链路层那一摊事帧的组装和拆解、前导码和SFD的识别、CRC32的生成与校验、地址过滤、冲突检测、退避重传。它不含PHY也就是说它管不到电平、管不到双绞线上的曼彻斯特编码更管不到RJ45接口上的变压器。PHY是板子上那颗独立芯片MAC和PHY之间靠MII或者RMII这根总线连着。这条边界一定要先划清楚否则后面调试时会一直在错误的地方找问题。我的经验是把整条链路想成一条流水线RJ45进来的是差分模拟信号PHY把它变成数字的MII/RMII时序MAC把时序变成帧DMA把帧搬进内存lwIP在内存里解析出IP包最后交给你的socket回调。任何一个环节断了现象都是ping不通但原因可能天差地别。所以定位问题的第一步永远是分层而不是盲改代码。1.1 MAC与DMA为什么必须有DMA以太网帧最小64字节、最大1518字节不带VLAN标签千兆以下速率下每秒可能来上万帧。如果每个字节都让CPU去读寄存器CPU基本就废了。所以STM32的ETH内部集成了一个专用的DMA引擎它和MAC之间是内部总线直连和系统内存之间通过总线矩阵访问SRAM。DMA的工作方式是基于描述符环Descriptor Ring。你在内存里开辟一段连续的描述符数组每个描述符32位×4个字TDES0~TDES3或RDES0~RDES3里面记录了本帧的缓冲区地址、长度、以及各种状态位和中断位。DMA自己维护一个当前指针发送和接收各一套环。CPU只需要把要发的帧放进缓冲区然后置位描述符的OWN位表示这个描述符归DMA所有了剩下的搬运工作DMA自己完成。这个设计带来一个必须注意的后果描述符和缓冲区所在的内存区域其访问属性必须和DMA的访问方式一致。在带Cache的核比如Cortex-M7上如果这块内存是可缓存的CPU写进去的数据可能还躺在D-Cache里没落到SRAMDMA读到的就是旧数据反过来DMA把收到的帧写进SRAMCPU从Cache里读到的又是旧内容。这是新手在H7系列上最常踩的坑后面第3章会专门讲MPU配置怎么处理。1.2 MII和RMII省下的那16根线值不值MII是标准接口发送接收各4位数据线加上TX_CLK、RX_CLK、TX_EN、TX_ER、RX_DV、RX_ER、CRS、COL一共十几根。RMII是精简版数据线砍到2位时钟统一成一根50MHz的REF_CLK引脚数降到7根左右。选RMII几乎是必然的理由很实际引脚省下来了PCB好布而且大部分常用PHY都支持RMII。代价是REF_CLK必须是50MHz、精度±50ppm这个时钟的质量直接决定链路稳定性。我见过因为用了普通晶振分频出来的50MHz、抖动偏大导致跑一段时间就出现CRC错误的案例。MII只在两种情况下值得考虑一是需要10/100M全双工且对时序余量要求极高二是某些老PHY只支持MII。除此之外RMII是默认选择。1.3 描述符与缓冲区的内存布局规划在动手写代码之前先在链接脚本或者内存规划表里给ETH留一块地。以常见的F4系列为例典型配置是项目数量单元大小占用发送描述符416字节64字节接收描述符416字节64字节发送缓冲区41524字节6096字节接收缓冲区41524字节6096字节合计约12KB。这个量在SRAM里不算小尤其是F407只有128KB64KB CCM的情况下得提前算清楚。描述符数组必须32位对齐缓冲区建议也按4字节对齐某些系列如H7甚至要求描述符地址按32字节对齐以避免Cache行撕裂。注意缓冲区大小建议取1524或1536不要图省事取1518。多出来的几个字节是为了容纳VLAN标签和可能的对齐填充某些交换机会发出带标签的帧缓冲区不够会被DMA直接截断并置错误位。2. 硬件设计原理图阶段就该定死的东西以太网这部分硬件一旦打板出错软件怎么调都是白费。我在实际项目里见过太多代码查了三天最后发现是PHY地址strap电阻贴错的情况。所以这一章讲的都是原理图评审时该盯住的点。2.1 PHY选型的几个现实考量市面上常用的RMII PHY不少选型时别看参数表上写的工业级低功耗重点看四件事时钟输出能力、strap引脚定义、寄存器兼容性、封装和供货。型号接口时钟方案地址配置备注LAN8720ARMII外接25MHz晶振REF_CLK输出50MHzPHYAD0引脚strap0x00或0x01用量大资料多注意它没有MIIDP83848MII/RMII需外部提供50MHzPHYAD[4:0]引脚strap老牌方案功耗略高KSZ8081RMII外接25MHz输出50MHz通过strap引脚或MDIO配置支持线缆诊断YT8512RMII外接25MHzstrap引脚国产替代寄存器基本兼容选型时我一般会先确认一件事这颗PHY的REF_CLK是输出还是输入。LAN8720A默认是从25MHz晶振分频出50MHz给MAC用此时STM32的ETH_REF_CLK配置为输入模式有些PHY需要MAC提供50MHz那就要用STM32的MCO输出这时候MCU的主频和MCO分频必须算准MCO的抖动也比专用晶振差一截。2.2 时钟方案50MHz这根线值得单独画一页RMII的REF_CLK是整条链路的节拍器。它的频率容差要求±50ppm占空比40%~60%上升沿要干净。三种常见来源对比PHY的25MHz晶振分频输出最稳晶振精度天然满足走线也短。这是首选。MCU的MCO输出50MHz省一颗晶振但MCO是从PLL分频出来的抖动大长距离走线容易劣化。只在板子空间极度紧张时用。独立50MHz有源晶振成本高但精度最好适合多PHY或者对同步有要求的场景。25MHz晶振的负载电容要按晶振规格书算别照抄参考设计。我遇到过一批板子用12pF负载电容配了标称18pF的晶振起振勉强但频率偏了表现为链路能起来但大流量下丢包。2.3 差分走线与变压器不是能通就行TX±和RX±是100Ω差分对走线要求差分对内等长误差控制在5mil以内。差分对之间保持足够间距至少3倍线宽避免串扰。尽量不走层间换层必须换层时在旁边加回流地过孔。走线远离晶振、DC-DC、复位线。变压器这块常用的是1:1隔离变压器中心抽头接法分电压型和电流型PHY两种。LAN8720A是电压型驱动TX侧中心抽头接3.3V并通过0.1μF去耦DP83848偏电流型接法不同。这一条接错链路指示灯可能亮但就是收不到包。我在评审原理图时这一项永远单独圈出来确认。RJ45建议用集成变压器的连接器省事且一致性更好。外壳地SHIELD通过1nF/2kV电容和RC网络连到数字地防静电也防地环路。接口侧再加TVS阵列做防护尤其是外露的场景。2.4 复位、strap与中断引脚PHY的复位至少要拉低10ms以上具体看手册。复位释放后到MDIO可访问还要等几十毫秒的内部初始化。如果MCU启动比PHY快第一次读PHY寄存器会读回0xFFFF很多人以为是MDIO坏了其实是时序问题。稳妥做法是复位后延时100ms再初始化MAC。Strap引脚决定PHY的MDIO地址、是否自协商、是否全双工。这些引脚在复位期间被采样所以上拉下拉电阻的阻值要按手册给的范围取一般4.7kΩ到10kΩ。我自己踩过的坑是PHYAD0上拉用了100kΩ理论上够但因为走线旁边有个强驱动信号耦合采样时被拉低了一瞬地址变成0x01软件按0x00去读自然读不到。中断引脚建议接上虽然轮询也能跑但链路状态变化插拔网线用中断响应更及时。如果引脚紧张至少保证能通过轮询PHY的BMSR寄存器检测Link Up。3. CubeMX配置从引脚到参数一项一项抠CubeMX确实能省不少事但它生成的以太网代码有几个默认值是不能直接用的尤其是内存相关的配置。这一章按配置顺序讲每一项都说明为什么这么设。3.1 时钟树与引脚分配的核对顺序配置顺序我习惯是先定系统时钟再开ETH最后配lwIP。原因是以太网的时序依赖系统时钟尤其RMII的REF_CLK如果是MCO输出的PHY和MAC的时钟必须同源。以常见的F407为例典型配置是HSE 8MHzPLL到168MHzETH时钟来自PLL的48MHz那一路ETH_PTP_CLK。RMII模式下CubeMX里PHY Interface选RMIIAuto Negotiation使能RX Mode和TX Mode都选轮询或中断一般选中断Checksum offload建议开能减轻CPU负担。引脚上会自动分配PA1REF_CLK、PA2MDIO、PA7CRS_DV、PC1MDC、PC4RXD0、PC5RXD1、PB11TX_EN、PB12TXD0、PB13TXD1。这里有个细节PA1在RMII模式下是REF_CLK输入此时它必须配置成复用功能而不是普通GPIO手册里对它的模式有明确要求CubeMX会自动处理但如果你手动改过引脚配置回头检查一下。3.2 ETH参数逐项解析参数默认值建议值说明Auto NegotiationEnableEnable让PHY自己协商速率和双工Speed100M100M自协商失败时的兜底Duplex ModeFullFull半双工会引入冲突尽量不用RX/TX Descriptor count44~8数量多能缓冲突发但吃内存Buffer size15241524与前面规划一致Checksum offloadDisableEnable硬件算校验省CPU描述符数量我在资源紧张时用4资源宽松时用8。数量太少接收突发时容易丢帧太多中断处理延迟会变大。这没有标准答案得看你实际的流量模型。3.3 LwIP配置默认1600字节的堆根本不够CubeMX里LwIP的默认MEM_SIZE是1600这个值只能跑通ping稍微用一下TCP就内存耗尽返回ERR_MEM。我一般这么改#define MEM_SIZE (16 * 1024) // 堆TCP发送/接收缓冲都从这里分 #define MEMP_NUM_PBUF 16 #define MEMP_NUM_TCP_PCB 8 #define MEMP_NUM_TCP_SEG 32 #define PBUF_POOL_SIZE 16 #define PBUF_POOL_BUFSIZE 1524 #define TCP_MSS 1460 #define TCP_SND_BUF (4 * TCP_MSS) #define TCP_WND (4 * TCP_MSS) #define LWIP_DHCP 0 // 调试期先关静态IP更可控 #define LWIP_NETIF_LINK_CALLBACK 1这里解释几个关键值。TCP_MSS取1460是因为1500的MTU减去20字节IP头减20字节TCP头。TCP_SND_BUF取4倍MSS意味着最多能有4个满尺寸段在途这是能跑出稳定吞吐量又不吃太多内存的折中。PBUF_POOL_SIZE和PBUF_POOL_BUFSIZE决定接收队列如果网络上有大量小包池子小了会丢包。提示MEM_SIZE里的内存在lwIP里是统一管理的一块堆所有pcb、pbuf的头部都从这里分。16KB能应付中小流量如果要跑大文件传输建议拉到32KB甚至更多同时配合内存池一起看占用。3.4 生成代码后必须手改的几处CubeMX生成的代码在MX_ETH_Init()里已经配好了MAC但有几个地方它管不到第一描述符和缓冲区的对齐和内存属性。在F4上直接静态定义全局数组即可编译器和链接器会按4字节对齐。在H7上必须做MPU配置把描述符区比如0x30040000开始的区域配置为Device或Non-cacheable或者每次收发前后手动做Cache Clean/Invalidate。后者性能损失大前者更干净MPU_Region_InitTypeDef MPU_InitStruct {0}; HAL_MPU_Disable(); MPU_InitStruct.Enable MPU_REGION_ENABLE; MPU_InitStruct.BaseAddress 0x30040000; MPU_InitStruct.Size MPU_REGION_SIZE_32KB; MPU_InitStruct.AccessPermission MPU_REGION_FULL_ACCESS; MPU_InitStruct.IsBufferable MPU_ACCESS_NOT_BUFFERABLE; MPU_InitStruct.IsCacheable MPU_ACCESS_NOT_CACHEABLE; MPU_InitStruct.TypeExtField MPU_TEX_LEVEL1; MPU_InitStruct.SubRegionDisable 0x00; MPU_InitStruct.DisableExec MPU_INSTRUCTION_ACCESS_DISABLE; HAL_MPU_ConfigRegion(MPU_InitStruct); HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);第二PHY地址。CubeMX默认填0如果你的板子strap成了0x01这里必须改或者用扫描的方式自动探测。第三链路状态回调。打开LWIP_NETIF_LINK_CALLBACK之后实现netif_set_link_callback在网线插拔时重新触发DHCP或者重设接口状态否则插拔后要重启才能恢复。4. lwIP真正跑起来从ping通到业务可用ping通只是起点离业务可用还有段距离。这一章讲初始化顺序、常见吞吐量瓶颈和最小可用骨架。4.1 初始化顺序错一步全盘皆输正确的顺序是上电等待系统时钟稳定拉低PHY复位至少10ms释放后再延时100msMX_ETH_Init()配置MAC和DMA启动自协商轮询或者等中断确认Link Up读PHY状态得到速率和双工MX_LWIP_Init()创建netif设置IP进入主循环定期调用MX_LWIP_Process()裸机或让线程自然运行RTOS第4步是最容易漏的。如果Link还没起来就初始化lwIPnetif会处于DOWN状态DHCP永远超时。有些项目的做法是在MX_LWIP_Init()之后加一个while循环等Link但这样会阻塞启动。更好的做法是注册链路回调在回调里处理。4.2 静态IP还是DHCP调试期怎么选调试阶段我强烈建议先用静态IP。理由很直接DHCP会引入额外变量如果DHCP失败你分不清是网络问题还是DHCP服务器问题。静态IP配置简单IP4_ADDR(ipaddr, 192, 168, 1, 200); IP4_ADDR(netmask, 255, 255, 255, 0); IP4_ADDR(gw, 192, 168, 1, 1); netif_set_addr(gnetif, ipaddr, netmask, gw);注意PC端也要在同一网段并且关闭PC的防火墙或者放行ICMP。我见过不止一次ping不通最后发现是Windows防火墙拦了回复包。静态IP跑通之后再切DHCP验证。切的时候注意dhcp_start()必须在netif link up之后调用另外DHCP过程中如果超时检查一下是不是路由器开了AP隔离。4.3 吞吐量的三个瓶颈点很多人跑通之后发现TCP速率只有几百KB/s远低于100M的理论值。实际瓶颈通常在这三处瓶颈一MX_LWIP_Process()的调用频率。裸机下这个函数要尽可能频繁地调用如果主循环里有大延时收包会积压。我用过的最低要求是每1ms调一次。瓶颈二拷贝次数。从ETH DMA缓冲区到lwIP的pbuf如果配置成ETH_RX_BUFFER直接给lwIP用zero-copy能省一次memcpy。CubeMX默认是拷贝模式改动需要调整ethernetif.c里的low_level_input。瓶颈三TCP_SND_BUF和窗口大小。对端窗口小发送方就得等ACK。把TCP_WND和TCP_SND_BUF都提到4~8倍MSS吞吐量能明显上来。我实测过一组对比同一块板、同一台PC直连配置单向吞吐默认MEM_SIZE 1600SND_BUF 2×MSS约 3~5 MbpsMEM_SIZE 16KSND_BUF 4×MSS约 35~45 MbpsMEM_SIZE 32KSND_BUF 8×MSSzero-copy约 70~85 Mbps最后一档已经接近100M的实际上限了剩下的差距主要是协议栈开销和CPU主频。4.4 一个能直接用的TCP echo骨架把下面这段贴进main.c的初始化之后就能验证整条链路static err_t echo_recv(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err) { if (p NULL) { tcp_close(tpcb); return ERR_OK; } tcp_recved(tpcb, p-tot_len); tcp_write(tpcb, p-payload, p-tot_len, TCP_WRITE_FLAG_COPY); tcp_output(tpcb); pbuf_free(p); return ERR_OK; } static err_t echo_accept(void *arg, struct tcp_pcb *newpcb, err_t err) { tcp_recv(newpcb, echo_recv); return ERR_OK; } void echo_init(void) { struct tcp_pcb *pcb tcp_new(); tcp_bind(pcb, IP_ADDR_ANY, 7); pcb tcp_listen(pcb); tcp_accept(pcb, echo_accept); }PC端用telnet 192.168.1.200 7或者任意TCP工具连上去发什么回什么说明MAC、DMA、lwIP、协议栈全通了。这个骨架的价值在于它把变量降到最少如果这个都跑不通问题一定在底层。5. 调试实录那些让人抓狂的现象和它们的真凶这一章是我这些年攒下来的排查表按现象分类基本覆盖了90%的以太网问题。5.1 链路都起不来现象PHY的Link灯不亮或者亮了但读BMSR寄存器的Link位一直是0。排查顺序先量PHY的供电和复位电平确认复位已经释放再量25MHz晶振是否起振用示波器看万用表测不准然后确认MDC/MDIO上有没有波形如果没有说明MAC根本没发起MDIO事务回头查ETH初始化有没有执行到如果有波形但读回全0xFF检查PHY地址对不对。我遇到过一个特别隐蔽的PHY的复位引脚接在MCU的GPIO上但CubeMX里那个GPIO被配置成了模拟输入浮空状态下PHY一直处于复位。改回推挽输出就正常了。5.2 ping不通但Link是Up的这是最常见的一类。排查步骤检查项方法常见问题MAC地址读寄存器或打印全0或全FF会被交换机丢弃IP网段对比PC和板子掩码不一致导致跨网段ARPPC上arp -a板子没回ARP说明接收链路没通防火墙临时关闭ICMP被拦收发计数读ETH的DMA统计收有计数发没计数说明发送描述符没提交读DMA统计寄存器是最有信息量的一步。ETH_DMARXPKT在涨但ETH_DMATXPKT不动说明收方向通了、发方向有问题重点查发送描述符的OWN位有没有正确置位以及TX_EN引脚有没有输出。5.3 小包正常、大包丢ping 32字节能通ping 1472字节就不通或者TCP传大文件一会儿就断。这类问题的根源通常是缓冲区不够或者Cache一致性。先确认PBUF_POOL_BUFSIZE是否≥1524再看接收描述符数量是不是太少导致突发丢帧。H7上还要重点查Cache如果描述符区是可缓存的CPU看到的OWN位可能是Cache里的旧值导致DMA和CPU对同一个描述符的理解不一致表现出来就是随机丢包。判断方法很土但有效把MPU配置成Non-cacheable再跑一遍如果问题消失那就是Cache的事。5.4 跑几个小时就挂这类问题最耗时间因为复现周期长。常见原因有三个第一个是内存泄漏。lwIP里pbuf用完必须pbuf_freetcp_recved也必须在对的地方调。漏一次不显眼跑几小时pbuf池就空了。建议打开LWIP_STATS和MEM_STATS定期打印剩余量。第二个是描述符环指针越界。DMA的当前指针如果跑到环外面整个收发就停了。这个一般是初始化时环的长度配置和实际数组长度不一致导致的。第三个是PHY自协商抖动。某些劣质网线或者RJ45接触不良链路会反复Up/Down每次Down都触发一次lwIP重连久而久之资源耗尽。对策是在链路回调里加去抖连续N次检测到Down才真正处理。心得长时间稳定性测试我一般跑24小时同时用脚本每10秒ping一次并记录丢包率。丢包率超过0.1%就要查别等到客户现场才暴露。6. 几条用血换来的经验写在这里省你几天第一先让硬件说话再让软件说话。板子回来第一件事不是烧程序是量电源、量晶振、量复位、看Link灯。硬件层面没确认软件调一天都是白搭。第二MDIO扫描是个好习惯。初始化时遍历0~31号地址读PHYID寄存器把读到的地址打印出来能省掉大量地址配错的排查时间。这几十行代码我每个项目都带着。第三把DMA统计寄存器做成调试命令。收包数、发包数、CRC错误数、溢出数、描述符错误数这几个数字一摆出来问题范围立刻缩小一半。比起加打印这个成本低得多。第四别迷信CubeMX生成的默认值。它给的是一个能编译能跑的配置不是能用在产品上的配置。内存、描述符数量、TCP窗口这些参数必须按你的实际流量重新算一遍。第五RMII的50MHz时钟用示波器看一眼。频率、峰峰值、上升时间一分钟的事能排掉一大批玄学问题。我现在的习惯是每个以太网板子首件都要看这根线看过的板子里大概有两成时钟质量不达标问题都出在晶振负载电容或者走线太长。最后说个扩展方向如果项目对实时性有要求可以把ETH的中断优先级调高并把lwIP跑在独立的RTOS线程里配合信号量唤醒比裸机轮询的响应确定性要好得多。不过线程优先级和栈大小要试栈给小了会在处理大包时溢出这个坑我也踩过。
