企业官网建设流程全解析

如果你在STM32H7上跑LwIP做UDP收发，碰到过这类现象：短包偶尔能通，稍微加长或提高频率就丢包；回环测试里收进来一堆被改写的脏数据；个别情况下甚至直接HardFault。大多数人第一反应是查PHY配置、查中断、查MAC时钟，折腾很久都找不到问题。我实际调试下来，这类问题十有八九不是网络栈本身的配置，而是内存落点出了偏差。H7的主RAM不是单一区段，DTCM、AXI RAM、D2域SRAM各自有不同的访问路线，而DMA能不能“够”到某块内存是有严格规则的。LwIP的收发缓冲区、DMA描述符一旦被放到了DMA到不了的地方，就会出现上面这堆看似随机、其实规律极强的故障。这篇文章就围绕“主RAM选哪儿、DTCM和AXIRAM怎么分、UDP收发如何稳定”展开，把整个排查思路和最终可落地的配置方案拆开讲清楚。

1. 跳进H7内存前，先理解“DMA够不着”是什么概念

1.1 现象本身：UDP收发异常的三类表现

这类问题不会一开始就把所有故障全暴露出来，通常是一步步加重。我见过的典型过程是这样：板子刚调通网络，先用笔记本ping主机板，ICMP小包通；然后用上位机发UDP短报文给设备，设备能回；继续加压，每秒钟发50包、每包512字节，开始出现零星收不到；再往后，长包或者大频率下丢包率直接飙升；最后在调试器里发现程序进了HardFault，或者ETH DMA状态寄存器里的总线错误标志位被置上。

从这些现象里能看出一个共性：只要DMA搬运的数据量变大、频率变高，故障就变明显。短包偶尔能过，是因为数据恰好在小概率下走了碰巧可行的路径，或者缓冲区没被多次复用；长包和高压则立刻把隐患放大。很多人会下意识以为这是MAC层时序、中断优先级、PHY电气质量等问题，绕了很多弯路。实际上当你把内存分配地址打出来看，会发现那些接收缓冲区、发送描述符链表的地址，可能全都落在0x20000000开头的DTCM区间里。

1.2 核心概念：CPU看得见不等于DMA看得见

Cortex-M7和老的M3/M4一个很大的区别，在于它引入了紧密耦合内存（ITCM/DTCM）和AXI总线架构。在M4上，整块SRAM基本都被CPU和外设DMA共享，你只要把一个缓冲区数组的地址交给外设，DMA就能来搬。到了M7上，事情变了：DTCM虽然离内核非常近、零等待、性能极好，但它挂在一条私有的tightly coupled总线上，这条总线只有CPU核心能看到。换句话说，以太网MAC这种外设，它的DMA控制器根本不知道DTCM的存在。

你可以把DTCM理解为一条只给CPU走的“快速内部通道”，CPU从DTCM取数特别快；而以太网、USB、DMA2D、SDMMC这类外设DMA，需要的是能通过总线矩阵“按地址寻访”的物理内存。当CPU把LwIP的pbuf、ETH的描述符数组，甚至整个堆分配在DTCM里时，外设DMA去读这块内存就会触发总线错误。轻则这一次传输失败、描述符状态异常；重则DMA控制器挂住，芯片进入HardFault。问题本质不是软件流程错了，而是“DMA看不到目标内存”。

这也是为什么标题里“主RAM选择”非常关键。你总得先决定工程的主力内存放在哪个区域，而不是让编译器默认往最快的地方塞——最快的地方反而是最危险的地方。

1.3 最常见的错配：LwIP缓冲落进了DTCM

默认的CubeMX工程模板，内存布局往往把DTCM当作主RAM，中断向量、初始化数据可能都安排在DTCM里，堆和栈往往也被安排在DTCM附近。对于纯GPIO操作、普通运算，这没问题，而且性能很好。问题出在LwIP这种涉及外设DMA的网络协议栈上。

LwIP发送UDP的流程大致是：应用数据先被拷贝到一个pbuf，pbuf里填好UDP头、IP头、以太网头，最终把帧缓冲区地址交给MAC的DMA描述符，由ETH DMA按描述符地址去搬数据。接收方向更直接：MAC DMA一收到帧，就把数据搬到预设好的接收缓冲区里，等CPU来处理。如果这些缓冲区地址全部位于DTCM，那DMA搬运就是一个必然出错的操作。我在调试时遇到过一种特别迷惑的情况：短包偶尔成功，因为某些情况下缓冲区可能被放在了D2域的SRAM里，而碰撞概率决定失败不总发生；等到缓冲池被耗尽、分配策略发生了变化，或者包长导致DMA要连续读取更多内存，错误就开始集中爆发。

搞清楚这个底层关系之后，所谓“RAM选择”就不再是性能调优问题，而是能否稳定工作的前提。

2. H7的RAM地形图：哪些区域能放什么

2.1 DTCM：只有CPU能走的快速通道

DTCM在STM32H7系列里通常有128KB（不同型号略有差异），地址从0x20000000开始。它最突出的优势是零等待、访问延迟极低，特别适合放实时计算的关键变量、操作系统内核对象、中断服务用的临时数据。我在实际工程里通常把任务栈、RTOS TCB、高频中断的局部缓冲放DTCM，性能非常稳。

但它的致命限制是：外部DMA访问不了。不管是ETH DMA、USB OTG DMA、通用DMA1/DMA2都不能直接访问DTCM。如果数据要先由CPU算好、再由DMA交给外设，你必须在DTCM里做临时计算，然后把最终结果拷到DMA可达的内存区域，再触发DMA。也就是说，DTCM适合做“CPU私有的工作台”，不适合做“CPU和外设共享的数据交换区”。

2.2 AXI RAM：能当主力的公共客厅

AXI RAM，也叫D1域SRAM或AXI SRAM，地址从0x24000000起，容量在H743/H750这类芯片上是512KB。它是H7里名副其实的“主力RAM”。一方面CPU通过AXI总线访问它，访问速度和普通SRAM一致；另一方面，各类总线主设备（包括ETH DMA）也能经过AXI总线和总线矩阵访问它。因此，LwIP的DMA描述符、数据缓冲区、pbuf池，放这里都是合理选择。

AXI RAM还有一个特性，它有16个独立bank和对应的CacheLine交互行为。因为它的地址范围在0x24000000这个普通映射区，CPU缓存（D-Cache和I-Cache）会把它当成普通可缓存内存来对待。只要开启了D-Cache，CPU写进去的数据可能先留在Cache里，而DMA直接从物理AXI RAM里搬数据，搬走的可能是旧数据；反过来，DMA刚搬进来的数据如果还在Cache里是旧状态，CPU读到的也会是脏数据。这就是缓存一致性问题。解决办法是：要么把这块区域配成MPU的non-cacheable区域，要么在对DMA释放缓冲区之前主动做Clean/Invalidate。

2.3 D2/D3域SRAM：给外设搬砖的侧门

除了DTCM和AXI RAM，H7还有D2域和D3域的SRAM。D2域的SRAM1（0x30000000，约128KB）、SRAM2（0x30020000，约128KB）、SRAM3（0x30040000，约32KB）挂在较低速的AHB总线上，以太网MAC模块本身就在D2域，所以ETH DMA访问D2 SRAM也很顺。很多工程师喜欢把网络缓冲丢在这里，因为离MAC更“近”，确实也能用。不过相比AXI RAM，D2 SRAM的仲裁优先级和带宽在一些高负载场景下会吃亏，如果同时有多个DMA在D2域搬运数据，延迟会更明显。

D3域还有一个SRAM4，地址在0x38000000，通常几十KB，用在需要低功耗唤醒保持数据的场景，不太适合做大流量网络缓冲。

2.4 DMA访问矩阵速查表

为了不让你在后续配置里反复翻手册，我整理了一个简化的访问参考表，基于H743/H750这类常见型号（具体数值以自己芯片型号为准）。

表格里需要注意的是“与D-Cache关系”这一列。AXI RAM因为在0x24000000段，默认可能是可缓存的；而D2/D3 SRAM的地址段通常不在可缓存范围内，反而省去很多缓存一致性麻烦，只是带宽和仲裁条件不如AXI RAM。所以设计时要在“DMA可达性”和“缓存一致性复杂度”之间权衡。

2.5 为什么ETH DMA不能访问DTCM——生活化类比

用个生活化的类比：DTCM就像业主自住的一个内书房，只有业主本人有钥匙，快递员、外卖员一概进不来；AXI RAM就像小区里的公共快递柜，业主能存取，快递员也能往里放。LwIP要做的事情本质上是“业主写一封信放到快递柜里，让快递员取走”；如果把信写在内书房里，快递员自然取不到。这个类比虽然简单，但足够解释为什么短包偶尔也能通：如果某个缓冲区实际上是放在公共区域的，那快递员就能取到；但网络栈内部的很多临时pbuf都在DTCM，一旦用到就出问题。

理解了这个地形，下一步就是动手改配置。

3. LwIP在H7上的内存落位实操

3.1 CubeMX为你生成的段和链接脚本

多数人会从STM32CubeMX生成工程，然后在里面开启ETH、配好LwIP。CubeMX生成的链接脚本，在不同IDE下有不同写法，但思路一致：CubeMX会把ETH描述符和Rx/Tx数据缓冲区分别放到指定的section。以Keil MDK为例，默认链接脚本会定义：

RW_IRAM1 0x20000000 0x20000 ; DTCM RW_AXIRAM 0x24000000 0x80000 ; AXI RAM

CubeMX生成的驱动代码里，描述符数组会加上section标记，比如：

__ALIGN_BEGIN ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT] __ALIGN_END __attribute__((section(".RxDecripSection"))); __ALIGN_BEGIN ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT] __ALIGN_END __attribute__((section(".TxDecripSection"))); __ALIGN_BEGIN uint8_t RxBuff[ETH_RX_DESC_CNT][ETH_RXBUF_SIZE] __ALIGN_END __attribute__((section(".RxArraySection")));

这些section在链接脚本里被定向到哪个RAM区域，决定了ETH DMA到底能不能访问它们。如果你在CubeMX的内存配置里把这些section全部指向DTCM，或者默认配置没注意RAM区域映射，那问题马上就来了。

3.2 把ETH描述符和缓冲数组固定到AXI RAM

最稳的做法，是在链接脚本里给AXI RAM划出专门的section，让描述符和DMA缓冲区全部落在AXI RAM。以IAR/EWARM的.icf为例，我可以这样摆：

define symbol __ICFEDIT_region_D1RAM_start__ = 0x24000000; define symbol __ICFEDIT_region_D1RAM_end__ = 0x2407FFFF; define region D1RAM_region = [from __ICFEDIT_region_D1RAM_start__ to __ICFEDIT_region_D1RAM_end__]; place in D1RAM_region { readwrite section .rxDescrip, readwrite section .txDescrip, readwrite section .rxBuf, readwrite section .txBuf };

对于MDK的分散加载文件，方式类似：

RW_ETH_DESC 0x24040000 0x2000 { *(.RxDecripSection) *(.TxDecripSection) }

当然也可以不单独固定起始地址，直接用RW_D1RAM来放。关键是保证这些section最终被放到0x24000000这个AXI RAM区间里，而不是0x20010000之类的DTCM区间。

这里有一个重要提醒：ETH DMA描述符和缓冲区还必须按32位对齐。因为HB设计里ETH DMA要求描述符地址以4字节对齐，缓冲区最好也按32字节边界对齐，方便Cache Line操作。CubeMX生成的数组里已经加了__ALIGN_BEGIN，如果你自己重写数组，千万不要省掉。

3.3 把LwIP堆和pbuf池搬出DTCM

LwIP内部有两个核心内存来源：一个是堆内存mem_malloc，用于较临时、较大的pbuf；另一个是内存池memp，用于大小为固定值的小pbuf。这两个来源都来自于在链接阶段分配的静态数组。默认情况下，这些数组会进入常规.bss段，最后被放进CubeMX指定的“主RAM”。如果主RAM是DTCM，那么这些pbuf池也全在DTCM里。

很多人把ETH描述符和接收缓冲数组已经移到了AXI RAM，以为万事大吉，结果UDP还是有问题，就是因为pbuf池还在DTCM。发送UDP时，应用层如果调用pbuf_alloc(PBUF_TRANSPORT, len, PBUF_POOL)，分配出来的pbuf就可能在内存池里，而内存池还在DTCM，EMAC DMA搬不了这个地址。

要解决这个，最直接的办法是改变LwIP内存分配器。一个高效的方法是自己实现一个区块分配器，从一个固定的AXI RAM缓冲区中切出LwIP堆。假设我在AXI RAM非缓存区里保留了一块64KB区域：

#define LWIP_RAM_HEAP_POINTER __attribute__((section(".eth_dma_ram"))) uint8_t mem_memory[MEM_SIZE]

mem_memory是LwIPmem.c里面的全局数组，只要把它指定到新的section，整个堆就移到AXI RAM了。对应地，在lwipopts.h里设置：

#define MEM_SIZE (60 * 1024) #define PBUF_POOL_SIZE (16) #define PBUF_POOL_BUFSIZE (1600) #define LWIP_RAM_HEAP_POINTER ??

上述写法中LWIP_RAM_HEAP_POINTER不是标准LwIP选项，别照抄。更适合的做法是：直接修改mem.c或利用链接器把mem_memory强制放置到目标section。在实际的STM32CubeMX生态里，你可以在链接脚本直接添加一个区域，再把所有LwIP相关变量统一用section标注过去。只要保证mem_memory和内存池的静态数组落在AXI RAM，LwIP内部动态分配就都在安全区。

3.4 MPU与D-Cache：要么关缓存，要么管好一致性

AXI RAM可以被D-Cache缓存，所以即使ETH缓冲都在AXI RAM，只要D-Cache开着，仍可能发生数据不一致。有两个方向可以选。

方向一：把ETH专用RAM标记为不可缓存。这是嵌入式网络开发中最常见、也最省心的方案。配置MPU，把AXI RAM中的某个子区域（比如0x24040000开始的64KB）设为normal memory但cacheable=No，或者直接设为设备区。配置完成后，CPU读写这块区域和普通SRAM一样，不做Cache缓冲，DMA搬进搬出就是物理内存里的真实数据。代码里MPU初始化类似这样：

MPU_Region_InitTypeDef MPU_InitStruct = {0}; MPU_InitStruct.Enable = MPU_REGION_ENABLE; MPU_InitStruct.BaseAddress = 0x24040000; MPU_InitStruct.Size = MPU_REGION_SIZE_64KB; MPU_InitStruct.SubRegionDisable = 0; MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0; MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS; MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE; MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE; MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE; HAL_MPU_ConfigRegion(&MPU_InitStruct);

CubeMX里也有可视化配置页，直接添加Region，BaseAddress设为0x24040000，属性选Non-cacheable，生成代码即可。

方向二：如果坚持让这块RAM走Cache，那每次DMA操作都得做缓存维护。发送前，CPU写完数据后要SCB_CleanDCache_by_Addr，把Cache里的数据刷回物理内存；接收后，DMA写入数据，CPU读之前要SCB_InvalidateDCache_by_Addr，让Cache失效并重新从物理内存加载。但代码里很容易漏掉某一处，特别是处理环状描述符、多缓冲帧时。我自己实践下来的建议是：对于LwIP这类大流量缓冲，干脆用MPU划一块non-cacheable的AXI RAM专区，剩下的AXI RAM保持Cache，性能和数据正确性都能兼顾。

3.5 一种随手可用的稳妥布局

综合上面的分析，我推荐一套能覆盖大多数场景的分配策略：

这套布局说白了就是：DMA要碰的内存统一抬到AXI RAM的non-cacheable区域，CPU自己的数据留在DTCM和AXI RAM缓存区。这样两边互不干扰，UDP收发的稳定性和速度都能达到理想状态。

4. 从现象到修复：一次UDP收发问题的完整定位

4.1 启动阶段就失败，怎么确认是DMA访问不了内存

如果程序初始化ETH DMA描述符之后就卡住或HardFault，首先要检查描述符地址。我常用的办法是在HAL_ETH_Init返回后，用一个临时变量打印或记录：

printf("RX desc addr: 0x%08X\r\n", (uint32_t)&DMARxDscrTab[0]); printf("TX desc addr: 0x%08X\r\n", (uint32_t)&DMATxDscrTab[0]); printf("RX buf addr: 0x%08X\r\n", (uint32_t)&RxBuff[0][0]);

如果打印出来的地址全是0x2xxxxxxx，尤其落在0x20000000-0x2001FFFF这类DTCM区间，那基本就能下结论了：ETH DMA描述符不在它可达的内存里。再看ETH中断状态寄存器，通常会有总线错误标志被置位的痕迹。这类问题在启动阶段表现为“初始化过不去”，在运行阶段则表现为“丢包+异常数据”。

另一种快速验证方法：把描述符和接收缓冲的section改到D2域SRAM1，如果问题立即消失，也能反推原来确实放错了位置。

4.2 收包正常、发包异常或反过来

很多现场表现是“单向正常”。比如设备能ping通，说明接收和发送的ICMP回声请求都能被MAC DMA搬运；但你用上位机持续给设备发UDP数据，设备收不到。这里要细看：LwIP内部ethernet_input收到的帧缓冲区是从接收描述符的RxBuff里搬出来的，如果RxBuff在DTCM，DMA搬不进来；如果RxBuff在AXI RAM但LwIP处理时把它拷贝到DTCM的临时pbuf里再解析，也可能出问题。

更常见的是“发送失败、接收正常”：应用程序能收到UDP包，但上位机收不到设备回包。因为发回包时，应用数据会经过新的pbuf分配和填充，如果这个pbuf被分配到DTCM，ETH DMA发送时就成了无源之水。我在某块H7板子上就见过这种单边现象：接收路径的缓冲区是CubeMX实际放到AXI RAM的，但发送路径用txpbuf临时把所有数据拼接进一个位于DTCM的数组，结果接收完全正常、发送永远发不出去。把那块临时数组强制放到AXI RAM后，回归测试通过。

4.3 加长包、高频率之后的二级问题

当你的内存落点已经放到AXI RAM，但UDP发长包仍丢包，就要检查另外两件事。

第一件：pbuf池的容量和大小是否够。LwIP默认的PBUF_POOL_SIZE和PBUF_POOL_BUFSIZE在H7工程里经常没有根据报文长度调整。比如某个上位机会发1500字节的UDP包，加上IP头、以太网头，需要的pbuf可能要1600字节；如果PBUF_POOL_BUFSIZE只有1514，包会溢出或分片，看起来就像丢包。

第二件：DMA描述符个数与缓冲块是否匹配。ETH_DMADescTypeDef的Rx描述符个数、Tx描述符个数要和驱动代码里的ETH_RX_DESC_CNT、ETH_TX_DESC_CNT一致。发送频率高时，如果TX描述符数量太少，DMA还来不及搬完，应用程序新一轮发送就排队堵死。H7的ETH DMA有四级发射队列，虽然LwIP默认不做多队列调度，但描述符个数直接决定吞吐上限。

还有一种很坑的情况：DMA缓冲区被配置成non-cacheable，但MPU的配合有问题。比如只把前一部分RAM设置了non-cacheable，后一部分实际仍然可缓存，而LwIP的内存池恰好横跨了两块区域，数据后半段走了缓存通道，就出现“前半包正确、后半包错乱”的怪现象。排查这类问题，建议把所有缓冲区的地址范围打印出来，和MPU区域范围仔细比对。

4.4 修复后的最终效果

在一套完整修复方案落地后，我通常能看到这样的结果：短包、长包、持续UDP压力测试都稳定通过；DMA描述符和所有pbuf地址都在0x24040000之后；HardFault不再复现；即使开着D-Cache也不影响收发。这说明不是运气好，而是内存访问路径彻底理顺了。一些工程师问过我：既然non-cacheable区域性能低，为什么还要把LwIP丢进去？我的回答是：网络数据本来就是外设和CPU之间交换的，宁可用non-cacheable换取一致性，也不要为了那一点Cache命中率反复排查灵异问题。真对性能敏感，可以对接收路径做特别优化，但那是在稳定之后的事。

5. 排查这类问题的几条经验

5.1 三件套检查：地址、Cache、池大小

任何LwIP在H7上出UDP收发问题时，我都建议先做三个检查，按顺序来，效率最高。

先查地址。把描述符地址、RxBuff地址、TxBuff地址，以及运行中动态分配pbuf的地址全部打印出来。看它们是不是落在0x24000000这个AXI RAM区间。发现落在DTCM，直接改section，不要继续排查网络参数。

再查Cache。确认ETH缓冲区所在的内存区域是否为non-cacheable。如果不是，检查代码里是否在正确位置做了Clean/Invalidate。这个可以通过单步观察：向缓冲区写一个特征值，立即读回来，如果读到旧值，就是Cache问题。

最后查池大小。PBUF_POOL_SIZE、PBUF_POOL_BUFSIZE、MEM_SIZE三个参数要和实际收发报文长度匹配。大包场景下，PBUF_POOL_BUFSIZE至少要大于“链路层最大帧长”，一般给1600以上；如果板子内存够，给到2048更稳。

5.2 常见错误快查表

这张表不是万能，但覆盖了我在H7上遇到过的绝大多数情况。

5.3 防患于未然的工程习惯

踩过多回坑之后，我现在在H7工程里的习惯是：从一开始就明确划分“CPU私有内存”和“DMA共享内存”两套区域。CPU私有内存放DTCM和可缓存的AXIRAM；DMA共享内存放AXIRAM的non-cacheable固定区域，并用宏和链接脚本单独管理。这样后面接USB、DCMI摄像头、SDMMC这类也要DMA的设备，直接套用同一套规则，不会每次重新踩一遍。

还有一点值得分享：调试这类问题，建议把ETH_DMACSR和ETH_DMASR里的标志位做成调试输出，出问题时先看有没有BUS ERR、FBI、RBUS这类错误位。大多数情况下，DMA总线错误就是“放错内存”的直接证据。比反复抓包分析快得多。

最后再提一个小技巧：如果你在SDRAM外部内存上跑LwIP，也要同样关注SDRAM映射区的MPU属性和刷新策略；如果SDRAM走的地址段被配成write-back，同样会闹出缓存一致性问题。规则和AXI RAM完全一样，先保证DMA可达，再处理Cache，最后才是池大小描述符个数这些参数调优。