实现这个还是很简单的，先使用CubeMx将这两个通道进行配置，注意采样时间参数不要太短了。 启动方式可以跟单个通道一样，也可以不一样。可以先跟单通道采样一样。 数据的提取可以基于中断方式或DMA方式，如果DMA方式就需要对DMA相关参数做配置。 库里有现存的启动函数，你根据具体情形来选用。 HAL_ADC_Start()；配合结果查询函数； HAL_ADC_Start_DMA(ADC_HandleTypeDef *hadc, uint32_t *pData, uint32_t Length)； HAL_ADC_Start_IT(ADC_HandleTypeDef *hadc, uint32_t *pData, uint32_t Length)；
在HAL 库中有个例程，可以参考一下 STM32Cube_FW_G4_V1.5.0\Projects\STM32G474E-EVAL\Applications\OpenBootloader Run STM32CubeProgrammer and connect to OpenBootloader using USART1
楼主说的方式符合应用笔记所描述的。 目前楼主验证不成功，可以检查一下bootloader 的版本，如果是早期的 V13.3(0XD3)是可能的。 建议换一个最新版更新过的芯片。 我的测试板上的芯片就是 V13.3的，比较旧的版本，不能实现这个功能。
这个问题离STMCU本身有点距离了。 从你给出的电路来看，PC5 PC6的标号怎么感觉是随便乱标的。 至于干簧管旁边为什么不直接让其直接接地，而是接了RC电路，本质是硬件低通滤波，目的应该是做按键消抖之用的。
原厂生产芯片是全球合作造出来的。 晶圆是一个厂家，封装是另一个厂家。 芯片表面丝印上会有封装地标识。（当然，如果是假的，丝印肯定也会被改掉） 一般来说，都是靠正规授权经销商购买就好了。 楼主既然买的是开发板，那么连接到 STM32CUBEPROGRAMMER 试试，再跑两个例程， 简单对照手册能工作就好了。 如果量产的话，到ST授权的经销商购买就好了。
我刚才配置了下，使用CubeMx v6.13.0 ，可以配置成功。 你主要是对那个(boot)好奇吧。 我也好奇，查看了相关手册，应该是提示这些脚将来在使用 System bootloader做程序升级时可以用来做数据通信的相关外设管脚。这点，在以前的手册里 是没有在这个地方显式地标示出来的。
基于双缓冲做DMA接收时，第一次用哪个缓冲区，是可以配置的。 我这边查看了STM32 HAL库相关API函数，我们可以通过调整那两个目标内存地址的位置来 决定先用哪个内存区。你不妨结合代码再看看和验证。
STM32F411俺也一样。 2025年4月了，更新了HAL库文件到最新。还是在初始化4bit的时候失败。卡是SanDisk在售的当代高速卡。用在这里是法拉利上乡村土鳖路。 1B模式没问题，4B模式测试了很久不通，ChatGPT给的建议都试过没用～ MCU到卡槽连线只有20多毫米。数据线中间有33欧电阻减干扰，上拉47K。 这个问题问的人好多，官方好多年了也没辙～
这个现象是正常的，并非所有通道事件都能 同时 申请到独立的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
应该是没问题的，H573相比H563只是多了安全相关的功能，其它外设 基本功能和管脚安排上没有什么差别。我刚才也比较下两个料号的管脚安排，是一样的。你也可以再比较确认下。
微信公众号
手机版
