用户最近将CubeMX升级到了5.5.0版本，因此他怀疑这是新版本的一个bug。为了进一步了解问题，我们可以一起查看他提供的截图。在配置UART5时，界面上甚至没有出现DMA配置的选项。
为了验证这个问题，我使用最新的CubeMX版本5.6.1进行了测试。在配置STM32F407VE的UART5并尝试为其申请DMA传输时，并没有遇到用户所描述的问题。这让我们开始思考，问题究竟出在哪里。
经过分析，我发现用户的工程不仅仅使用了UART5，还涉及到了其他外设。这可能意味着他在配置其他外设并申请DMA请求时，无意中占用了UART5可以使用的DMA流。为了确认这个猜想，我们查阅了STM32F4系列参考手册中的DMA章节。
根据手册，UART5的TX/RX事件确实可以申请DMA，但只能使用DMA1_S0和DMA1_S7。然而，其他外设事件也可能申请这两个DMA流，例如TIM4_CH1和TIM4_CH3。如果这些外设事件先一步占用了DMA流，UART5就无法再申请DMA了。
为了验证这个理论，我们先将TIM4_CH1和TIM4_CH3的DMA流申请走，然后再尝试为UART5申请DMA。结果CubeMX提示无法进行DMA请求，这与用户的反馈相符。
那么，当遇到这种情况，我们应该如何解决呢？首先，可以检查当前占用UART5欲申请DMA流的外设，看是否可以调整它们申请其他DMA流，以避免竞争。以STM32F4芯片为例，一些外设事件如TIM1_CH1、SPI1_RX和SPI1_TX可以申请多条DMA传输流。
此外，STM32家族中部分系列支持DMAMUX，这可以让DMA配置更加灵活高效。但即便如此，DMA请求事件通常远多于DMA传输流，因此并不是每个事件都能成功申请到DMA。
如果在实际应用中，两个外设事件确实需要竞争同一个DMA传输流，而它们的使用时间可以错开，那么还有一种解决方案。可以在CubeMX中为每个外设的DMA请求事件生成两套配置，然后手动调整代码。在需要使用哪个外设事件的DMA传输时，只需启用相应的DMA配置和应用函数即可。
总之，在使用CubeMX等工具进行配置时，不仅要熟练掌握工具的使用方法，还要对基本原理有所了解。只有这样，在遇到问题时才能迅速找到解决方向。希望通过本文的分享，能给大家提供一些启示和帮助。
某STM32用户反映，他目前使用STM32F407VE的芯片开发产品，在使用CubeMx做初始化配置时发现没法给UART5配置基于该外设事件的DMA请求。他觉得很奇怪,坚信UART5是可以申请DMA传输的，而且他还基于早期CubeMx 版本配置过、使用过。
他刚好最近对CubeMx升级到5.5.0了，怀疑是不是STM32CubeMx5.5以上版本的bug。
说到这里，可能有人还不是没完全明白具体怎么回事。我们结合他给过来得截图一起来看看。他在对uart5做配置时出现的界面是下面这样的，连那个DMA配置的菜单都没有。
基于他的反馈，我用目前最新的CubeMX版本5.6.1进行验证，同样对STM32F407VE的UART5进行配置并试着为其申请DMA传输。经过测试并没有碰到他所说的问题。
那问题出在哪儿呢？
我的测试工程只是单纯使用到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传输流都不只一条。
或许有人知道，STM32家族中有些系列支持DMAMUX，如果有它做DMA配置就更方便、高效。但不管怎样，DMA请求事件肯定要远远多于具体实施传输的DMA流，所以具体应用中并不能保证有申请DMA资格的事件就一定申请得到相应的DMA传输。就像你有钱也有资格坐飞机坐高铁，但并不能保证你时刻可以买到你期望的机票或火车票而成行。
再结合到本案例，遇到两个外设事件对一个DMA传输流发生竞争不可避免的时候，若两个外设对DMA的使用在时间上可以错开的话，也还是有办法解决的。我们可以使用CubeMx分别基于两个外设的DMA请求事件生成两套配置，然后手动调整代码，需要使用哪个外设事件的DMA传输时就启用相应的DMA配置及应用函数。总之，搞清了怎么回事，结合具体应用灵活处理就好。
最后小结下。针对上面的客户问题，如果对CubeMx工具的使用不熟或者说只是机械地使用该工具做配置，心里没有些基本原理做支撑的话，遇到该问题时恐怕一时也的确难以找到方向。在此分享，权作提醒。
