一个因初始化顺序而导致异常的话题
有STM32用户反映，他使用STM32F4系列芯片进行开发，通过STM32CubeMX配置初始化代码，使用了UART的DMA传输。但他发现DMA根本不工作。后来他无意中发现，是因为他在用户代码里不经意地调整过UART外设和DMA外设初始化代码的前后顺序，当他重新调整二者的先后顺序后就一切正常了。他想知道这个顺序是怎么影响DMA功能的。
笔者顺手拿了块STM32F334的NUCLEO板，开启UART1/UART3的数据通信功能，使用DMA进行数据的循环传输。UART1 发送数据，UART3接收数据，均配置在异步双工模式。基于STM32CubeMX配置后生成初始化代码，添加用户代码。如下图所示：
file:///C:\Users\Administrator.WIN-STED6B9V5UI\AppData\Local\Temp\ksohtml14452\wps5.jpg
经测试验证，发现基于UART1/3的DMA传输功能是正常的。
结合客户的反馈，我将DMA与UART初始化顺序前后调换下，如下图：
file:///C:\Users\Administrator.WIN-STED6B9V5UI\AppData\Local\Temp\ksohtml14452\wps6.jpg
果然发现，DMA真的不工作了，UART1/UART3之间没有发生数据通信。通过调试发现，UART1/3的数据寄存器内容维持0值而没有任何变化，尤其作为发送端的UART1的数据寄存器也毫无动静。
看来，DMA和UART的初始化代码的顺序的确影响到了二者的功能。也就是说如果代码是基于现有CubeMX生成的初始化代码，二者的初始化顺序不能随意调整，那到底怎么回事呢？
首先自然是查看这两个初始化代码内容，试图找到蛛丝马迹。很遗憾，并未很快发现原因。当再次查看DMA初始化函数MX_DMA_Init();的具体内容时，发现其代码其实很简单，就两个动作，几行代码而已：
file:///C:\Users\Administrator.WIN-STED6B9V5UI\AppData\Local\Temp\ksohtml14452\wps7.png
一个开启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功能，在UART_MspInit();函数里不仅有对与UART相关的GPIO的复用功能配置，还有跟UART事件有关的DMA配置。看来UART的初始化还是跟DMA有关联的。【见如下截图】
file:///C:\Users\Administrator.WIN-STED6B9V5UI\AppData\Local\Temp\ksohtml14452\wps8.png
结合前面提到的DMA初始化函数里的那句开启DMA外设时钟代码，到这里基本明白怎么回事了。
因为我们在UART初始化代码里要做跟DMA有关的配置，如果不事先将DMA外设的时钟开启，【UART初始化函数里也没有开启DMA外设时钟的代码】，那么，在UART初始化代码进行有关DMA的配置操作就没法保证有效。
到此，开篇中提到的因为DMA和UART初始化代码顺序影响DMA功能的原因应该说揭晓了。
在做嵌入式开发过程中，很多的初始化配置都是基于硬件本身的，有些初始化顺序往往有硬件方面的配置时序要求，关于这些各个芯片手册中一般都会有描述和说明。我们在编写初始代码时须遵循相关规定或约定。当然，有些配置顺序可能还得结合具体应用，实际体会后而做灵活调整。
具体到文中案例，本来STM32CubeMX在生成初始化代码时已经考虑到初始化时序这点了，只是用户在整理代码过程中无意调整了二者的初始化顺序而不自知，再加上我们对CubeMX生成的初始化代码本身往往缺乏足够的熟悉度，在开发过程中可能会因此陷入一时的困扰。关于这点，相信未来版本的STM32CubeMX会做进一步的调整与完善。
