有人使用STM32的定时器事件触发DMA，让其将内存数据传输到通信外设的数据寄存器进行发送，发现DMA根本就不动作。
8 J$ e2 S. d0 }% `3 R& ]

% s7 z1 X* t& D. y3 E& V1 D比方以基于STM32F411的芯片为例，通过TIM3更新事件触发DMA请求，DMA从内存将数据送到SPI1的数据寄存器，从而完成数据发送。

4 ?4 ~1 y- c; K7 J( D$ A
他采用CubeMx进行配置。基本配置如下：[文中图片可以放大观看]
9 n9 \9 R9 ~) n- U. h$ g



+ e* h2 N, L; ?+ N! j3 x7 b

5 q( A' I2 k, H8 M2 {
2 l" L. g" x: o: q4 C% {* |
" B  X  ]  M4 P/ J: n相关用户实现代码如下：

; O$ X( p6 T1 U6 C& d

5 n  g' j2 _7 o4 R- c/ ^

" w, w# |9 K" A' b5 U从配置过程和代码实现来看，似乎都没有问题。那DMA怎么就是不动作呢？


( t1 }8 ]& R# A问题出在我们使用上面的函数做DMA传输所关联源端和目标端时，出现了想当然的情况。


: `! X3 Q1 T* Y0 z9 B我们利用TIMER事件来作为DMA请求源时，而作为数据传输的源端或目的端，都是我们用户指定的。这时就一定要注意源端和目标端是当前DMA流所支持的。否则就会出现乱点鸳鸯谱，DMA根本可能就跑不起来。就像你叫了某快递公司，它的服务范围是相对固定的，并非你想去哪里她就能服务到哪里。
5 k. E6 u: a! y% O( ?

/ |3 f9 O6 O: G8 \0 |) [ 比方上面的例子，如果改成SPI2就没问题。为什么刚才SPI1不行呢，因为DMA1根本访问不到SPI1，我们不妨看看基于STM32F411芯片的内部功能及总线框图就很清晰了。
! P5 S4 D) ~, B! l: U
- H3 y0 S( \, H6 m9 p2 M+ c1 Y
7 N' p: ?0 r& Z' ^/ _( E  \

' z2 r3 C$ v* y
! ~1 x# O7 E, [) d$ T从上图不难看出DMA1是访问不到SPI1或SPI4这些外设的，或者说DMA1就没法访问挂在APB2总线上的外设，只能访问APB1总线上的外设。
( w+ C, k& p$ ^3 k. ^1 b) T2 U
1 W2 z! c7 W& l$ `: g
9 C# ~+ o3 K6 i' ^6 s小结：一般来讲，基于某触发事件，对应的DMA数据流就可以确定下来了，那该DMA数据流的传输范围往往也随之确定。我们在为该DMA数据流指定源端和目标端时一定要符合其传输范围，否则会出现传输无法完成的情形。换言之，我们在做DMA传输时，为了实现DMA的有效传输，往往需要结合源端和目的端来调整或选择合适的DMA数据流。

, C" e) K4 j/ V) c3 T6 \