这个现象是正常的，并非所有通道事件都能 同时 申请到独立的DMA传输通道。 就像并非每个定时器事件都能申请到1个独立的IRQ一样，很多时候多个事件共用一个NVIC矢量入口。 像你这种情况，你可以看看别的TIMER，比方TIM1，它的4个通道都能申请到不同的DMA stream. 或者，DMA不够时用中断补。
参考一下库中例程，在例程条件下看看功耗是否对的上。 主要是检验硬件或测试方式是否合适。 不妨先单纯的测试STOP模式，不要开启RTC，这样测试相对容易点。 代码开始前最好增加两秒延时时间，方便下次连接容易些。
你是说的那个NCS脚吧。 该引脚通常是固定的，恐怕不能随意更改。其实，你想下，如果可以随意自行定义，它这里肯定就不用固定下来了。 这样设计应该是基于信号完整性以及时序、硬件设计、系统可靠性等多方面的综合考虑。
从你描述的情况来看，程序卡死跟中断发生的频率强相关。 如果中断频率过高，系统可能会花费过多时间处理中断，导致任务无法及时执行。这可能导致任务队列积压，进而导致电机卡死。 建议尽量减少中断或降低中断频率。比方通过减少中断源或增加中断触发周期，可以有效降低中断频率，削减系统负荷。 同时，确保中断处理程序尽量短小精悍。复杂的处理尽量放在任务中进行，而不是在中断中直接处理。 另外，根据实际需求调整任务优先级，确保关键任务能够及时执行。 注意队列的长度和项大小适合你的应用需求。队列长度过短可能导致队列满无法发送新的事件，过长则可能内存浪费。 还有，注意配置合适的系统栈和任务栈，确保系统和任务有足够的堆栈空间，避免堆栈溢出导致异常。
这个问题已经找到原因了。 !(data/attachment/forum/202504/23/185401orqqryrphhr9xrhu.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")!(data/attachment/forum/202504/23/185420fzr2woyo7th2xuyx.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png") 在进行FLASH擦除时从FLASH_FlushCaches函数里进入了中断。 !(data/attachment/forum/202504/23/185438fgztqbqyj69yygjy.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png") 这个函数进行了指令缓存的关闭和复位。 在程序卡死时可以通过仿真单步执行，当单步执行到开启指令缓存后就可以全速运行了。DMA通道中断太多了，升级多次就容易在这个点被打断导致程序卡死。目前通过关中断可以解决（屏蔽这个函数也可以）。但关闭中断，HAL库中用于等待超时的systick中断就无法实现了。 是不是HAL库这里没考虑到中断的问题
不知你目前设置的接收缓冲区的个数是几，一般设置为4. 你改大点试试，比方8。 另外，你也可以跟踪下，通过heth->DMAErrorCode看看到底发生了什么错误，或许可以找到 有针对性的解决办法。
咋听起来还是有点奇怪的。 不过，你使用STM32H7系列芯片的话，就有可能碰到这个现象。 你现在用于DMA传输是内存数据定义为常量数组时正常，而定义为变量数组时则传输异常。结合你的代码来看，你使用的是DMA1. 当定义为常量型数组时，数据存放在flash区，此时DMA就是在FLASH区和TIMERE寄存器间实现传输，这是没问题的。 当定义为变量型数组时，数据被编译器安排在RAM区，到底被安排在哪个RAM区，就跟你当时默认使用的RAM区有关，如果说被安排到 DTCM区，即0x2000,0000地址开始的RAM区，此时DMA1是访问不了TCM RAM的，出现传输异常就不奇怪了。这样的话，你需要在 IDE里调整下默认使用的RAM区，比方SRAM1 SRAM2 或者AXI SRAM，或者手动为数组给存储地址落在DMA1可以访问到的RAM区。
理论上只要是STM32就都可以，有人在F103小蓝板上跑过，部分ARDUINO也可以。 https://mp.weixin.qq.com/s/EW9b4Ywf5IHqvSmLd8o1sw
微信公众号
手机版
