某STM32用户反映，他目前使用STM32F407VE的芯片开发产品，在使用CubeMx做初始化配置时发现没法给UART5配置基于该外设事件的DMA请求。他觉得很奇怪,坚信UART5是可以申请DMA传输的，而且他还基于早期CubeMx 版本配置过、使用过。

他刚好最近对CubeMx升级到5.5.0了，怀疑是不是STM32CubeMx5.5以上版本的bug。

说到这里，可能有人还不是没完全明白具体怎么回事。我们结合他给过来得截图一起来看看。他在对uart5做配置时出现的界面是下面这样的，连那个DMA配置的菜单都没有。

基于他的反馈，我用目前最新的CubeMX版本5.6.1进行验证，同样对STM32F407VE的UART5进行配置并试着为其申请DMA传输。经过测试并没有碰到他所说的问题。

0 `1 N5 l/ V- W

那问题出在哪儿呢？

我的测试工程只是单纯使用到UART5，并未使用其它外设及相关DMA应用。我结合他反馈过来的配置截图，隐约发现他的工程应用中并不仅仅使用一个UART5外设，还用到了其它外设。会不会是他在配置其它外设并申请DMA请求时，把UART5可以申请的DMA流占用了呢？

我们先不妨打开STM32F4系列参考手册的DMA章节，看看有关外设事件与DMA传输流的映射关系图。从手册中我们可以看到，UART5的TX/RX事件能申请DMA毫无疑问，但只能申请DMA1_S0和DMA1_S7。

然而呢，可以申请DMA1_S0和DMA1_S7的外设事件又有很多，比方TIM4_CH1和TIM4_CH3就可以分别申请DMA1_S0和DMA1_S7。如果说，在做UART5事件的DMA配置之前，若有别的外设事件已经将DMA1_S0和DMA1_S7申请走了，这时UART5就应该没得申请了。

基于上面分析，我们可以进一步验证下。

我们使用上面提到得TIM4_CH1和TIM4_CH3先将DMA1_S0和DMA1_S7申请走，再来尝试为UART5申请DMA，看看会怎么样。结果CubeMX提示该外设请求无效，不能申请DMA了。如下图所示：

提示界面跟客户反馈的不太一样，应该是CubeMx版本的差异所致。表达的基本意思还是相同的，即此时没法为UART5事件申请DMA传输。

到此，客户反馈的问题原因也基本清晰。像这种情况，由于UART5的TX/RX事件要申请的DMA流固定了，我们可以看看目前占用uart5欲申请的DMA流的外设，他们是否可以做调整去申请别的DAM流，从而避免竞争。因为有些外设事件可能申请的DMA流不只一条，当然这要结合具体的芯片。以STM32F4芯片为例，下图中的TIM1_CH1,SPI1_RX，SPI1_TX可申请的DMA传输流都不只一条。

2 L* C% ~* y6 f

1 b0 E& }  T' c& P

或许有人知道，STM32家族中有些系列支持DMAMUX，如果有它做DMA配置就更方便、高效。但不管怎样，DMA请求事件肯定要远远多于具体实施传输的DMA流，所以具体应用中并不能保证有申请DMA资格的事件就一定申请得到相应的DMA传输。就像你有钱也有资格坐飞机坐高铁，但并不能保证你时刻可以买到你期望的机票或火车票而成行。

. m8 N0 u( i7 y

再结合到本案例，遇到两个外设事件对一个DMA传输流发生竞争不可避免的时候，若两个外设对DMA的使用在时间上可以错开的话，也还是有办法解决的。我们可以使用CubeMx分别基于两个外设的DMA请求事件生成两套配置，然后手动调整代码，需要使用哪个外设事件的DMA传输时就启用相应的DMA配置及应用函数。总之，搞清了怎么回事，结合具体应用灵活处理就好。

最后小结下。针对上面的客户问题，如果对CubeMx工具的使用不熟或者说只是机械地使用该工具做配置，心里没有些基本原理做支撑的话，遇到该问题时恐怕一时也的确难以找到方向。在此分享，权作提醒。

* u7 c, P0 O3 C/ T/ ?

先顶一下啊！！！！！

WO DE 我的也是配置不了DMA1