STM32H7 LwIP 主RAM选择 DTCM AXIRAM UDP 收发问题

STM32H7 LwIP 主RAM选择 DTCM AXIRAM UDP

这段时间一直在调试STM32H743，期间掉进了不少坑，最大的坑还是网络这一块，例如LwIP移植，已经有前人踩过的坑，我以为我能避免，结果自己还是踩了，耽误了不少时间。

本人以前只用过M4的芯片，有标准库，习惯了所有工程自己建，库文件自己移植，文件目录按自己的风格走，所以非常不习惯CubeMX导出来的目录结构，H7木有标准库，只能HAL库走起来。

CubeMX是个好东西，但是封装的太抽象，有时候并不是一件好事，遇到问题怼寄存器的时候，就会很有体会，另外，中断处理的过程，都封装完了，你只是重写了应用部分，新手有可能都不知道需要清除中断标志位。

回到主题，LwIP移植就不多说了，应该算是比较好搜索教程了，不知道大家有没有注意到在CubeMX中配置的时候有这么一句话“The ETH can work only RAM is pointing at 0x24000000” ，今天的问题就在这里了，下边是截图。

你如果搜索H7 LwIP移植教程，大概率能搜到的是这个帖子，里边有一点提示和今天要记录的问题相关，如下图，我已经用红框框起来了，当然这个帖子是非常好的。

你这样配置，它一点问题都没有，可以正常运行，UDP一定能收能发，TCP我没有测试，想必也不会有任何问题的。

那么问题来了，DTCM，闲着了，在整个芯片里，就属他效率最高了，不用他岂不是灰常可惜，因为这个配置主内存是AXIRAM，也就是最大的那块，512K的那块，系统堆栈什么的，但凡是编译器分配的，都会优先选择这个，我想没有哪一位大仙，每定义一个变量就要写定义到DTCM中吧，累不死你才怪，就比如说系统堆栈，你定义啊，怎么定义？得用分散加载文件了吧，你还是得把IRAM1勾上，对吧，然后查map文件，你会惊奇的发现，想死的心都有了，分散加载文件，这玩意从F4上来的人，用的很熟练的没几个吧，当然我也是。

关于分散加载文件介绍，野火的教程和安富莱的教程都有，正点原子的没有看见（可能我眼瞎），可以学学，然后就各种自由各种畅快了，安富莱V7教程有一章，【STM32H7教程】第26章 STM32H7的TCM，SRAM等五块内存的超方便使用方式，提供了一个分散加载文件，嗯可以直接用的，用了就会发现，网络能ping通，一旦收发数据就挂了，酸爽不，我用的UDP挂了，TCP暂时还没有用到，想来挂掉是100%的。到目前为止，我提到了两个帖子，一个CubeMX的截图，V7教程推荐DTCM为主RAM，可是却又网络又ping不通，这就是今天要解决的问题。

那我们首先想的是这是什么原因造成的，一般情况下你的网络数据包，在你准备阶段，你是怎么处理的，是不是直接定义一个合适长度的数据，填充完毕调用相关API发送就over了。有没有思考一下，这个数组具体位置在哪里呢，只要能收发数据，谁还会关心这个问题呢？那就直说了，采用V7教程方法配置工程，你的数组在DTCM中，如果是移植教程的那个方法，你的数组在AXIRAM中。那就不得不贴一下总线架构图了：

由上边的这个图看出来，位于D1域和D2域的存储块ETH外设都能访问得到，效率怎样不管，不管有多绕，总之能访问到，DTCM是CM7专享，so，用V7教程方法，ETH的DMA就会各种错误都会来了，那么问题也就随之解决了，准备收发的数组定义到D2域或者D3域就解决了，我定义在了D2域是可以的，D3域还没有试，但是可以说明是可以的。

现在在说一下，为什么能ping通，想一下，你有主动去干预ping这个过程吗，LwIP协议栈已经帮你处理掉了呀，他也会收发数据的呀，他的数据在哪里，直接告诉你，就在D3域，为什么，想想你在移植LwIP时都定义了那些数组，是不是给协议栈一个很大的数组，ping操作就直接用他了，表面上用户是什么也没动的。

所以DTCM还是可以畅快的当主内存用的。