简介面向嵌入式开发者的 STM32H743DP83848 以太网通信测试工程覆盖 RMII 硬件连接到网络协议栈集成的完整链路。资料基于 STM32Cube 生态含 STM32CubeMX 配置 ETH MAC、DP83848 PHY 驱动示例以及 lwIP/FreeRTOSTCP 协议栈移植思路适合快速验证 STM32H7 平台 TCP/UDP 收发的软硬件工程师。压缩包采用 RAR 格式约 96.56MB文件清单未单独标注已有 1638 人浏览学习。通过研究该工程可掌握 MCU 与 PHY 时序配合、RMII 差分信号布线要点及常见排错方法缩短从硬件样板到链路通畅的调试周期。 前一阵子在做一块基于STM32H743的工业控制板通信接口里正好需要一路百兆以太网PHY 芯片选了DP83848。其实一开始也纠结过是用 LAN8720 还是 DP83848后来因为供应链和温宽要求最终定了 DP83848。整个开发流程是用STM32CubeMX生成工程、HAL 库驱动、再叠加上 lwIP 协议栈。整个过程踩了一些坑尤其在 PHY 地址、RMII 时钟和寄存器兼容性上浪费了不少时间。这篇文章就完整复盘一下这个项目从方案选型到最终 ping 通、收发数据稳定的全过程给正在做 H743 以太网开发的朋友一些参考。1. 整体方案拆解为什么是 H743 DP83848 CubeMX1.1 核心需求解析这个项目的应用场景是工业现场的数据采集与设备控制对网络的要求是百兆速率够用、链路稳定、抗干扰能力要强同时主控还需要跑 FreeRTOS并且留出足够的算力处理其他控制逻辑。之所以选择 STM32H743最直接的原因是它内置了 10/100M 以太网 MAC支持 MII 和 RMII 两种接口不用外接 MAC 芯片成本低且整体可靠性更好。STM32H743 的以太网 MAC 本身能力不弱支持 VLAN 标签、多播过滤、DMA 描述符管理等高级功能。它的 DMA 控制器是独立的收发数据可以做到不占用 CPU 核心资源这对实时性要求高的工业场景很关键。另外 H743 的主频跑到 480MHz算力冗余足够跑 lwIP 这种轻量协议栈根本不费力。1.2 PHY 芯片选型DP83848 和 LAN8720 怎么选很多人在做 STM32 以太网时第一反应是用 LAN8720因为价格便宜、模块多、资料多。但 DP83848 和它走的是完全不同的设计路线两者不能简单互相替换。对比项DP83848LAN8720接口模式支持 MII 和 RMII切换由引脚电平决定仅支持 RMII需要外部提供 50MHz 参考时钟PHY 地址由 RX_D0/RX_D1/CRS_DV/RX_ER 引脚上下拉决定常见为 0x01由 PHYAD0 引脚决定常见为 0x00工作电压3.3V I/O核心 1.8V 内部 LDO3.3V 供电内置 1.2V LDO寄存器映射标准 IEEE 802.3扩展寄存器丰富基本标准寄存器扩展寄存器较少温宽商业级 0~70℃工业级 -40~85℃后缀 I通常为 0~70℃MDIO 时序要求较严格对时序稳定性敏感相对宽松兼容性更好如果你只是做开发板学习、跑通 demoLAN8720 完全可以胜任而且模块很便宜。但如果项目要考虑温度范围、长时间运行稳定性、或者你恰好需要 MII 模式比如跑一些特殊 MAC 应用DP83848 会更合适。从驱动开发的视角看两者还有一个很重要的差异PHY 地址不同。这个差异最容易被忽略导致的现象就是 HAL_ETH_Init 能过但读 PHY ID 读到 0xFFFFFFFF或者 lwIP 链路状态一直不对。我后面会详细讲这点。1.3 接口模式选择RMII 还是 MIISTM32H743 支持 MII 和 RMII 两种模式。两者引脚数量差异很大MII 需要 16 根信号线RMII 只要 7 根。对于板卡面积和 PCB 布线来说RMII 优势太明显了所以我这个项目选的是 RMII 模式。RMII 的信号定义相对简单TX_EN发送使能TXD[1:0]发送数据RXD[1:0]接收数据CRS_DV载波侦听/数据有效REF_CLK50MHz 参考时钟MDC / MDIO管理接口关键点REF_CLK 必须是 50MHz而且要由外部时钟源产生。这个时钟是 MAC 和 PHY 共用的参考时钟如果时钟不干净或者相位抖动大会出现链路能起来、但收发丢包严重的问题。我这里用了一颗 50MHz 有源晶振提供给 DP83848 的 XI 引脚然后让 DP83848 的 XO 引脚回给 STM32H743 的 ETH_RMII_REF_CLK。这也是 DM9000、LAN8720、DP83848 等常见 PHY 的标准接法。2. CubeMX 工程配置与关键参数详解2.1 引脚分配和模式设置在 STM32CubeMX 中找到 ETH 外设选择 RMII 模式。H743 的 ETH 引脚和 SDMMC、FMC 等功能有复用冲突配置时要留意。我用的引脚组合如下信号引脚说明ETH_RMII_REF_CLKPA1由 PHY 提供 50MHz 时钟输入ETH_RMII_CRS_DVPA7载波侦听/数据有效ETH_RMII_TX_ENPB11发送使能ETH_RMII_TXD0PB12发送数据位 0ETH_RMII_TXD1PB13发送数据位 1ETH_RMII_RXD0PC4接收数据位 0ETH_RMII_RXD1PC5接收数据位 1ETH_MDCPC1管理时钟ETH_MDIOPA2管理数据另外还需要配置一个引脚作为 DP83848 的复位输出我用的是 PH6连接到 DP83848 的 RESET 引脚。复位时间要满足 PHY 的上电时序要求至少保持低电平 10ms 以上否则 PHY 可能初始化失败。CubeMX 里可以简单配置为 GPIO 输出然后在代码里手动控制复位时序不依赖 HAL 的默认初始化顺序。2.2 时钟树设置50MHz 那个坑必须说清楚STM32H743 的时钟树里ETH 外设的时钟源可以选择 PLL1Q、PLL2P 等。很多人会在这里出错以为只要把 ETH 的时钟选好就行。实际上RMII 模式的 50MHz REF_CLK 是由外部 PHY 提供的不是由 STM32 内部时钟直接产生的。我见过有人想省晶振试图从 STM32 的 MCO 引脚输出 50MHz 给 PHY这个方案理论上可行但实际调试时要配置 MCO 分频而且 MCO 输出时钟的抖动指标不一定能满足 100M 以太网的时序要求建议只在学习板上这么玩。CubeMX 里需要做的开启 ETH 外设选择 RMII 模式。将 ETH 的时钟源选为 PLL1Q并确保 PLL1Q 输出 50MHz。这里注意H743 的 PLL1 输出频率范围有约束需要通过调整 PLL1M、PLL1N、PLL1P、PLL1Q 来凑出正确的频率。手动验证时钟树页面里 ETH 相关的时钟值是否为 50MHz不要只看默认值。我实际配置的 PLL1 参数是PLL1M5PLL1N192PLL1P2PLL1Q12。输入时钟 HSE25MHz算出来 PLL1Q 25/5 * 192 / 12 80MHz不对这里只是举例不同板子 HSE 频率不同参数也会变。建议在 CubeMX 的 Clock Configuration 页面里直接观察并微调直到显示的 ETH 时钟为 50.000MHz。2.3 ETH 参数配置PHY 地址和 DMA 描述符CubeMX 的 ETH 参数配置里有一项 PHY Address默认值是 0。但这个值必须和硬件上 DP83848 的实际地址一致否则 HAL_ETH_Init 里的 PHY 通信会失败或能通信但读到的 PHY ID 不对。DP83848 的 PHY 地址由硬件引脚决定RX_D0、RX_D1、CRS_DV、RX_ER 这四个引脚在上电复位时的电平状态组合成 5 位地址实际上 RX_ER 对应 PHYAD[4]RX_D0 对应 PHYAD[0] 等等具体要看数据手册的 strap 引脚说明。因为 RX_D0、RX_D1、CRS_DV 在 RMII 模式下也是数据信号引脚所以需要通过外部上下拉电阻来设置地址。我板子上把 RX_D0 拉高其余相关引脚接特定的上下拉组合结果是 PHY 地址为 0x01。这里有个实操建议CubeMX 生成的代码里ETH 初始化结构体中的 PHY 地址字段要手动核对不要依赖 CubeMX 的默认值。因为 CubeMX 并不知道你板子上的 strap 电阻是怎么接的。如果 PHY 地址错了HAL_ETH_Init 会返回 HAL_ERROR或者 ETH 能初始化但 lwIP 一直显示链路 down。DMA 描述符数量方面CubeMX 默认 TX 和 RX 各 4 个描述符。这个值要看项目的数据量。如果收发频率较高、数据包较大建议适当增加比如 TX 8 个、RX 8 个。描述符数量太少在高负载下会出现 DMA 描述符耗尽导致丢包。这个参数在 ETH 配置里的 DMA Descriptor 选项调整生成代码后对应 ETH_DMADescritorTypeDef 数组的大小。2.4 FreeRTOS 和 lwIP 的集成我在这个项目里使用 FreeRTOS 作为操作系统所以在 CubeMX 里同时开启了 FreeRTOS 和 lwIP。lwIP 可以选择带操作系统版本通常选 LWIP_NO_SYS0并指定它为 FreeRTOS 的某个任务。有一些关键参数需要在 CubeMX 里先想清楚MEM_SIZElwIP 堆内存大小我配置为 1010241024 太大没必要实际用的 102410 也就是 10KB 不太够后面改成了 102464 即 64KB。这个要根据实际业务调整太小会导致内存分配失败太大浪费 RAM。H743 的 RAM 有 1MB 以上所以大方一点没问题。PBUF_POOL_SIZE数据包缓冲池大小默认 16 可能不够我改成了 32。TCP_MSS 和 TCP_WND这两个会影响 TCP 传输性能默认值可以先用后续调优时再改。生成代码后在 lwip.c 里需要重点检查 low_level_init 函数中 netif 的 hardware addressMAC 地址是否正确。没有唯一 MAC 时可以自己定义一个本地管理的 MAC 地址比如 02:00:11:22:33:44注意第一个字节的低两位要为 10本地管理才合法。3. 编译调试与功耗/时序实测3.1 编译环境搭建与常见编译器问题这个项目使用的是 STM32CubeIDE它内置了 GCC for ARM 编译器。不过也有团队用 Keil MDK 来开发 H743这里顺带说一下 Keil 环境下的一个关键点Keil 从 5.36 版本开始ARM Compiler 6基于 Clang成了默认编译器编译器版本号显示为 6.x。H743 的外设库、CMSIS 等都有更新所以如果你把老工程从 AC5 迁移到 AC6会冒出不少语法兼容性问题比如结构体指针的匿名初始化方式不同weak 函数声明的语法差异某些内联汇编在 AC6 下会报错。我个人的建议是新项目直接用 AC6不要回头用 AC5。虽然 AC5 兼容性好但官方已经把它标记为旧版而且 AC6 的优化效果和编译速度都有优势。如果一定要用 AC5需要到 Keil 安装目录的 ARM/ARMCC 文件夹里找是否有历史版本新装 Keil 默认可能不带 AC5。CubeMX 生成的代码对 AC6 的适配已经很成熟所以不必担心兼容性。3.2 首次上电调试PHY ID 读取验证拿到板子后我最先做的动作不是直接跑 lwIP而是写一段最简单的 MDIO 读取代码验证 MDC/MDIO 通信是否正常以及 PHY 地址是否匹配。具体做法在 main 函数里初始化 ETH 外设后用 HAL_ETH_ReadPHYRegister 去读 DP83848 的 PHYIDR1寄存器地址 0x02和 PHYIDR2寄存器地址 0x03然后打印出来。DP83848 的 PHY ID 是 0x2000 和 0x5C90具体可能因版本后缀有差异如果你读到的不是这个值而是 0xFFFF 或者 0x0000那基本可以确定MDC/MDIO 引脚接反或未上拉PHY 地址配置不对复位引脚时序问题PHY 芯片本身没工作供电、晶振有问题。这段代码是整个网络调试的第一步也是最重要的一步。如果这步走不通后面所有网络配置都是空中楼阁。我建议每个做以太网开发的朋友在接 lwIP 之前都先用 PHY ID 的读取来验证硬件底层这样可以大幅缩小问题的排查范围。3.3 网络连通性测试从 ping 到 TCP 通信PHY ID 读取正常后就可以初始化 lwIP 并测试链路了。我用的是静态 IP把开发板接到 PC 的同一台交换机上然后 ping 测试。首次 ping 测试时大概率会遇到问题。我这里遇到的情况是PHY ID 能正常读取但 lwIP 网络接口一直是 down 状态表现为 ping 不通且 netif_is_up 返回为 0。排查思路先检查 PHY 的 BMSR寄存器 0x01里的 Link Status 位。DP83848 的 Link Status 在 BMSR 的 bit 2这个位是锁存的读一次会更新需要注意连续读两次才能得到实时状态。检查 PHY 的 PHYSTS寄存器 0x10寄存器它更直观地反映了链路状态、速度、双工模式。再检查 STM32 的 ETH 外设状态寄存器ETH_MACSR看看是否有接收错误、载波错误等标志。最终发现问题是 RMII 的 REF_CLK 时钟质量不好。虽然用了有源晶振但晶振的电源滤波不充分导致时钟抖动偏大。后来在晶振电源引脚旁边加了一颗 10uF 和 0.1uF 的去耦电容并且把晶振的接地处理得更干净问题就消失了。这个案例说明以太网调试往往不只是软件的问题硬件设计的细节尤其是电源和时钟会直接决定系统是否稳定。3.4 高速数据通信下的稳定性验证网络通了之后不能只满足于 ping 通。我写了一个简单的 TCP 回环测试程序PC 端发送大文件给开发板开发板接收后再原样发回对比收发字节数是否一致。测试中发现了两个问题。第一个问题是在持续高速收发一段时间后网络会断掉必须重启才能恢复。排查后发现是 DMA 描述符耗尽导致的。虽然我已经把描述符数量改成 88但当数据包速率特别高时RX 描述符还是可能全部处于被占用状态而应用层没有及时处理。解决思路是在 lwIP 的接收任务里增加处理优先级确保数据包能及时从 DMA 描述符中取出来交给协议栈同时在 lwipopts.h 里把 NO_SYS 保持为 0即使用操作系统模式让 lwIP 运行在独立的线程中。第二个问题是 TCP 传输速率不稳定时高时低。通过 Wireshark 抓包发现是 PC 端在高速发送时开发板的 ACK 响应有延迟导致触发 TCP 重传。这个问题的本质是 CPU 中断优先级配置不合理。以太网 DMA 的中断优先级如果太低在系统繁忙时可能被其他中断延迟导致 RX 描述符处理不及时。我把 ETH 相关的 IRQ 优先级在 FreeRTOS 的配置范围内调高后传输速率就稳定多了。4. 常见问题速查与避坑经验4.1 问题排查速查表现象可能原因解决建议HAL_ETH_Init 返回错误PHY 地址不对确认 strap 引脚电平核对 CubeMX 中 PHY AddressPHY ID 读到 0xFFFFFFFFMDIO/MDC 线路异常检查上拉电阻、引脚复用配置、时钟线是否有信号能读到 PHY ID但 Link 一直 down网线、对端设备问题更换网线、检查对端设备是否开机Link up 但 ping 不通RMII REF_CLK 时钟质量差检查 50MHz 时钟波形加强电源滤波信号灯正常但收发不稳定DMA 描述符耗尽增加描述符数量优化 CPU 中断优先级TCP 速度慢、重传多中断延迟高、CPU 负载重调高 ETH 中断优先级减少无关中断干扰复位后偶发初始化失败上电时序问题手动控制 PHY 复位引脚保持至少 10ms 低电平4.2 PHY 地址配置的深度说明DP83848 的 PHY 地址具体怎么算这里必须展开说清楚因为这是最容易出问题的地方。根据数据手册DP83848 有 5 个 strap 引脚用于配置 PHY 地址PHYAD[4:0]在 RMII 模式下分别是RX_ER 对应 PHYAD[4]CRS_DV 对应 PHYAD[3]RX_D1 对应 PHYAD[2]RX_D0 对应 PHYAD[1]另一个引脚通常是 RX_DV 或 COL对应 PHYAD[0]让我用真实项目配置举例我板子上设置 PHYAD[4:0] 00001所以地址是 0x01。具体做法是 PHYAD[0] 对应的引脚接上拉电阻其余接下拉电阻。CubeMX 的 ETH 配置里PHY Address 就填 1。如果你不小心把 PHY Address 填成 0也不是完全不能工作。STM32H743 的 HAL 库在 ETH_MAC 初始化时会用这个地址去访问 PHY 的寄存器比如读 PHY IDR如果地址不匹配MDIO 通信没有回应HAL_ETH_Init 会卡在超时检查点。所以先用万用表确认 strap 引脚的上下拉电平再填 PHY Address能省掉大量调试时间。4.3 lwIP 内存与描述符的联动关系lwIP 的内存管理和 STM32 的 DMA 描述符是两套独立的资源但它们之间有关联。以太网数据包的接收流程是PHY 收到数据 - MAC 通过 DMA 写入 RX 描述符指向的缓冲区 - CPU 处理完数据后释放描述符。如果 lwIP 的内存池PBUF_POOL耗尽导致上层应用无法分配新的 pbuf数据包就一直滞留在 DMA 缓冲区中描述符无法释放。久而久之所有 RX 描述符都被占满新收到的数据包无处存放MAC 会直接丢弃它们。所以调优时PBUF_POOL_SIZE 和 DMA 描述符数量要联动调整。经验值是如果 PBUF_POOL_SIZE32DMA RX 描述符至少也要 16 个以上这样底层缓冲和上层缓冲之间有足够的缓冲余量不容易出现相互阻塞的情况。4.4 Keil、IAR 等工具链的差异提醒我用的是 CubeIDE 做的主开发环境但团队成员有人用 Keil。一次代码合并时发现两边编译出来的行为表现不一致Keil 编译后 PHY ID 读取正常CubeIDE 编译出来却卡在 HAL_ETH_Init。原因并不是代码逻辑问题而是不同编译器下结构体对齐方式、volatile 变量处理方式存在差异导致对硬件寄存器的访问时序略有不同。解决方法是在 ETH_MAC 外设的初始化代码中关键寄存器写入步骤之间加入少量 nop 或者延时比如 1us确保时序稳定。这种问题很隐蔽如果遇到类似的同一份代码不同编译器结果不同的怪事可以从时序容忍度入手排查。5. 一些晶振、PCB 和采购层面的经验补充5.1 复位时序和上电时序很多人在 PHY 芯片的复位上栽跟头。DP83848 要求供电稳定后RESET 引脚保持至少低电平 10ms然后释放再等待至少 10ms 才能进行 MDIO 通信参考数据手册的 Tmin 参数。如果你把 RESET 直接接到 STM32 的 GPIO在 main 函数初始化 ETH 之前就要完成这个时序控制。我之前在一版板子上用了简单的 RC 复位电路结果因为 RC 时间常数不够上电后 PHY 初始化经常失败。后来改成用 GPIO 手动控制复位代码里实现拉低延时 20ms拉高再延时 20ms问题才彻底解决。对于工业级产品不建议用简单的 RC 电路控制 PHY 复位直接用 GPIO 做软件复位时序是最可靠的方式。5.2 晶振布局与参考时钟完整性RMII 模式下50MHz 参考时钟是整个以太网链路的心脏。有源晶振或者无源晶振PHY 内部振荡器产生的时钟要求频率精度50MHz ± 50ppm 以内抖动性能周期抖动尽量控制在几十 ps 级别走线长度从晶振到 PHY、从 PHY 到 STM32 的时钟走线要短尽量包地。有件事值得注意DP83848 的 XI/XO 引脚既可以接无源晶振也可以由外部时钟直接驱动。如果使用无源晶振需要匹配晶振的负载电容如果使用外部时钟源直接接到 XI 引脚XO 悬空。我这个项目用的是有源晶振输出给 DP83848 的 XIDP83848 的 XO 引脚再连接 STM32 的 ETH_RMII_REF_CLK。这种接法的好处是时钟链路清晰只有一个时钟源保证 MAC 和 PHY 的同频同相。5.3 PCB 布线的关键点以太网信号是差分对但在 RMII 接口上数据线是单端的。需要注意以下几点TXD0、TXD1、TX_EN 这组发送信号要一起走线尽量保持等长间距一致RXD0、RXD1、CRS_DV 接收信号同理MDC/MDIO 是管理接口速率较低布线要求不高但要加上拉电阻MDIO 通常需要 1.5k 上拉到 3.3VPHY 的电源去耦要到位每一个电源引脚都要加 0.1uF 电容大的电源域还要有 10uF 级别的大电容。变压器部分如果用的是带网络变压器的 RJ45 座比如 HR911105APCB 布局时变压器中心抽头到 PHY 的布线要对称。如果用了分离式的网络变压器变压器两侧的地要隔离不能直接大面积敷铜连通。这是很多硬件工程师容易忽略的细节布局不当会直接导致辐射超标和通信不稳定。5.4 采购和替代料问题DP83848 这颗料是德州仪器的老牌 PHY供货相对稳定但价格波动也客观存在。市场上有一批打磨片、翻新片建议优先从正规代理商渠道采购。如果项目量比较大可以问一下原厂或代理当前的优选推荐是 DP83848 的哪个版本。老版本的 DP83848C 和新版本的 DP83848I 封装基本兼容但勘误表有差异大批量贴片前一定确认芯片顶标和批次。另外如果后续想把 PHY 换成国产替代方案需要注意寄存器级别的兼容性。很多国产 PHY 称管脚兼容 DP83848但寄存器映射并不是 100% 一致至少在 PHY ID 寄存器的默认值上就不同所以换料后软件里的 PHY 识别逻辑必须做适配。5.5 关于 CubeMX 生成代码的二次修改建议Cube 生成的代码结构是用户代码区 自动生成区的模式。当你改动 CubeMX 配置并重新生成代码时自动生成区的代码会被覆盖但用户代码区User Code Begin / User Code End 注释之间的部分会保留。所以建议lwIP 相关的底层接口函数如果有定制修改放在用户代码区PHY 地址相关的宏定义比如 PHY_ADDRESS 的宏如果要改优先去 CubeMX 的配置界面修改再重新生成而不是直接在代码里改因为生成代码时会被覆盖中断回调函数、错误回调函数里加的调试打印代码放在用户代码区内。另外CubeMX 的 PHY 驱动库里默认带的是 LAN8742 或者 LAN8720 的库取决于CubeMX版本。DP83848 和 LAN8720 的寄存器映射不完全兼容我建议直接使用通用 PHY 驱动手动实现 PHY 的初始化、状态读取、协商参数设置等。这样做虽然麻烦一点但可控性最好出了问题也容易排查。6. 进阶扩展H743 与 FPGA 的 FMC 通信、CAN 过滤器等补充在 H743 的生态里以太网往往只是整个系统的一部分。我这里顺带扩展一下搜索热词里经常出现几个和 H743 相关的点给正在做综合项目的朋友指个方向。6.1 H743 与 FPGA 通过 FMC 通信STM32H743 的 FMC灵活存储控制器支持、NOR Flash、SRAM 等并行外设。用 FMC 和 FPGA 通信的做法是把 FPGA 映射为一块片选空间STM32 通过地址总线和数据总线读写 FPGA 内部的寄存器或 FIFO。关键点是 FMC 的时序配置。需要根据 FPGA 侧的读写时序要求调整 FMC 的地址建立时间、数据建立时间、总线周转时间等参数。H743 的 FMC 支持独立的读写时序配置这一点特别方便。配置参数时不要只对着 CubeMX 的默认值来而要根据 FPGA 逻辑设计时给定的时序约束来设置。实际操作中我习惯先把 FPGA 侧的接口设计为类似异步 SRAM 的接口然后让 STM32 用 FMC 以 SRAM 模式去访问。调试时用逻辑分析仪抓 FMC 总线波形对比 FPGA 测到的时序反复微调 CubeMX 里的参数直到两边时序满足要求。第一次做 FMCFPGA 联调时务必把频率降下来测比如先 10MHz通了之后再逐步提高不要一上来就追求最高带宽。6.2 STM32F1 的 CAN 过滤器配置与 Busoff 恢复虽然标题是 H743但热词里 STM32F1 cube can 过滤器、cube stm32 busoff 恢复 这两个词说明很多朋友在 CAN 通信上也踩过坑。简单说两个点STM32F1 的 CAN 过滤器是 28 个bxCAN每个过滤器可以配置为屏蔽位模式或者列表模式。CubeMX 里配置过滤器时注意 ID 掩码模式的应用场景。Busoff 恢复是 CAN 控制器进入离线状态后重新同步的过程。HAL 库提供了 HAL_CAN_ErrorCallback可以在回调里检测 CAN 错误状态如果检测到 Busoff可以调用 HAL_CAN_Stop 和 HAL_CAN_Start 重新初始化链路同时延长定时器做延迟恢复防止反复抖动导致总线持续占用。H743 的 CAN 其实是 FDCAN和 F1 的 bxCAN 在寄存器层面完全不同但 CubeMX 和 HAL 库把差异封装得很好使用起来几乎无感。如果是从 F1 迁移到 H743 的项目CAN 驱动部分的修改量并不大。6.3 H743 的 SPI 与 FreeRTOS 结合H743 的 SPI 最高速率很高实测跑 50MHz 以上的 SPI 时钟没有问题前提是收发数据的缓冲区处理好。如果 SPI 的数据发送放在中断回调里发送要注意回调函数里不能执行耗时过长的操作否则会卡住整个中断响应。更推荐的方式是使用 DMA 传输 SPI 数据配合 HAL_SPI_TransmitReceive_DMA 这类接口在传输完成回调里释放信号量通知 FreeRTOS 任务做后续处理。7. 一个容易忽视的点MAC 地址和网络标识的规划最后补充一个产品化相关的小细节。开发阶段可以用任意 MAC 地址但产品阶段每个设备必须有唯一的 MAC 地址。有些产品主控里带 EEPROM 或 Flash可以在出厂时写入 MAC 地址。STM32H743 本身也有唯一的 UUID96 位可以用来生成一个基于 UUID 派生出的 MAC 地址。简单做法是取 UUID 的低 48 位然后把第一个字节的最低位和第二低位做本地管理标记处理得到一个不冲突的 MAC 地址。这样做的好处是不需要额外的 EEPROM每颗芯片烧录固件后自动拥有唯一的 MAC 地址批次更换 MCU 后MAC 依然唯一。lwIP 中设置 MAC 地址的位置在 low_level_init 函数里需要在 netif_add 之前就配置好 netif-hwaddr。如果你是动态生成 MAC 地址在 main 函数里先读取 UUID 并生成 MAC再初始化 lwIP这样就不会出现 MAC 地址全零的问题。在我实际项目中我把这个 MAC 地址生成逻辑放在了一个独立的函数里并且在启动日志中打印出来方便后续问题追踪。尤其在多个设备同时接入网络的场景下能看到每台设备的 MAC 地址是最有效的排障手段。8. 最终的工程验证和性能表现整个系统完成后的网络性能测试数据如下ping 延迟本地局域网平均 2ms大文件 TCP 传输连续传输 1GB 文件平均速率稳定在 8MB/s 左右百兆理论极限约 11MB/s扣掉协议开销这个成绩正常UDP 收发持续 24 小时压力测试丢包率 0.01%断网重连交换机断电重启后lwIP 能自动重新协商并连接无需手动干预。FreeRTOS 的各个任务运行正常以太网接收中断的最高频率没有对其他任务造成不良影响。功耗方面整板网络功能全速运行时电流约 230mA5V在工业产品的可接受范围内。如果你也在做 H743 以太网项目我可以肯定地告诉你这个方案是完全靠谱的硬件设计只要上电时序、时钟、PHY 地址这三件事不出错后续软件调试会顺利很多。遇到问题时记住一个原则先硬件后软件先 PHY 后 MAC先链路后协议。从 PHY ID 开始查起一步步来绝大多数问题都能快速定位。本文还有配套的精品资源点击获取
