一个跟初始化顺序有关的异常话题

最近有人反馈，他使用STM32F4系列芯片进行开发，通过STM32CubeMx配置初始化代码，使用了UART的DMA传输。但他发现DMA根本不工作。后来他无意中发现，是因为他在用户代码里不经意地调整过UART外设和DMA外设初始化代码的前后顺序，当他重新调整二者的先后顺序后就一切正常了。他想知道这个顺序是怎么影响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在生成初始化代码时已经考虑到初始化时序这点了，只是用户在整理代码过程中无意调整了二者的初始化顺序而不自知，再加上我们对初始化代码本身缺乏足够的熟悉度而可能会陷入一时的困扰。关于这点，相信未来版本的STM32CubeMx会做更进一步的调整与完善。

==============================

往期话题链接：【点击即可查看】