‍经常有STM32开发者基于STM32CubeMx进行配置并生成基于HAL库的初始化代码，当涉及到DMA功能时，发现DMA功能无效，但从配置操作及代码本身又似乎找不出原因来的情况。此情此景 往往挺令人抓狂的。

比方曾有人反馈，他使用STM32F4系列芯片进行产品开发，通过STM32CubeMx配置并生成初始化代码，使用了UART的DMA传输。但他发现DMA根本不工作。后来他无意中发现，是因为他在用户代码里不经意地调整过UART外设和DMA外设初始化代码的前后顺序，当他重新调整二者的先后顺序后就一切正常了【此时DMA初始化代码在前，UART初始化代码在后】。他想知道这个顺序是怎么影响DMA功能的。

我顺手拿了块STM32F334的Nucleo板，开启UART1/UART3的数据通信功能，使用DMA进行数据的循环传输。UART1发送数据，UART3接收数据。基于STM32CubeMx配置后生成初始化代码，添加用户代码。如下图所示：

经测试验证，发现基于UART1/3的DMA传输功能是正常的。

结合客户的反馈，我将DMA与UART初始化顺序前后调换下，如下图：

果真发现DMA不工作了，UART1/UART3之间也没有数据通信。UART1/3的数据寄存器内容维持0值而没有任何变化，尤其作为发送端的UART1的数据寄存器也毫无动静。

看来，DMA和UART的初始化代码的顺序的确影响到了二者的功能，也就是说如果代码是基于现有CubeMX生成的初始化代码，二者的初始化顺序不能随意调整，那到底怎么回事呢？

首先查看这两个初始化代码内容，试图找到蛛丝马迹。很遗憾，并未很快发现原因。后来，当再次查看DMA初始化函数MX_DMA_Init();的具体内容时，发现代码其实很简单，就两个动作：

一个动作是开启DMA外设的时钟，另一个就是使能DMA相关的中断矢量控制。

既然这样，我尝试将该DMA初始化函数体位置依然保持放在UART初始化代码的后面，但将DMA初始化函数里的那句开启DMA外设时钟的代码提取出来，并移至UART初始化代码之前，据此进行验证。这次，结果就一切正常了。

看来，基于现有初始化代码，这个DMA时钟的开启要放在UART初始化代码之前，那是为什么呢？感觉UART的配置跟DMA时钟没有啥关系啊。

继续挖掘原因！

再回头细看UART的初始化代码，在UART初始化函数的一个子函数HAL_UART_MspInit()那里发现了端倪。

MX_USART1_UART_Init()==》HAL_UART_Init()==》HAL_UART_MspInit();

因为我们开启了跟UART传输事件相关的DMA功能，在HAL_UART_MspInit();函数里不仅有对与UART相关的GPIO的复用功能配置，而且，还有跟UART事件相关的DMA配置。看来UART的初始化还是跟DMA有关联的。

结合上面DMA初始化函数里的那句开启DMA外设时钟代码，到这里基本明白怎么回事了。

因为我们在UART初始化代码里要做跟DMA有关的配置，如果不事先将DMA外设的时钟开启，加上UART初始化函数里也没有开启DMA外设时钟的代码，那么，在UART初始化代码进行有关DMA的配置操作就没法保证有效。

到此，开篇中提到的因为DMA和UART初始化代码顺序影响DMA功能的原因应该说揭晓了。

在做嵌入式开发过程中，很多的初始化配置都是基于硬件本身的，有些初始化顺序可能有硬件方面的时序要求。关于这些，各芯片手册中一般都会有明确描述和说明。我们在编写初始化代码时须遵循相关规定。当然，有些配置顺序可能还得结合具体应用，实际体会后而做灵活调整。

回到文中案例，一般来说，STM32CubeMx在生成初始化代码时已经考虑到初始化时序这点了，只是用户在整理代码过程中可能无意调整了二者的初始化顺序而不自知，再加上我们对初始化代码本身缺乏足够的了解而可能一度陷入困境。

据个人体验，在实际应用中，当我们基于CubeMx来回调整配置时，这个顺序也可能会被打乱。请注意这点。说实在的，这个地方非常隐蔽，即使知道有这么回事也还是可能忘记或忽略。当因此而出现DMA传输异常时，如果不是基于代码做跟踪调试或阅读是很难找到问题症结的，因为配置操作和所调用的库函数代码本身是没有问题的。核心问题就是初始化代码的执行顺序。

比方这两天连续有人反馈，他们使用STM32芯片的ADC并启用DMA传输时，都是因为这个原因使得ADC数据无法被DMA取走而产生异常。总之，在现有情况下， 保证DMA初始化代码放在其它与DMA有关的各个外设初始化之前就不会有类似问题。比方就像下面的样子：

关于这个话题，三年前我已经在此分享过了。这个过程中，依然陆续也有人会遇到这个问题，我觉得有必要再分享之，所以在这里再分享一遍，以资提醒，愿君在开发过程中少一份坎坷。