1、在keil下识别id号，开头不是1的 99%的概率是假货 2、用ST的ISP软件下载hex如果失败，很可能遇到国产芯片打磨成st !(data/attachment/forum/202504/27/114119fkz9zauq9fkm84g3.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
基于双缓冲做DMA接收时，第一次用哪个缓冲区，是可以配置的。 我这边查看了STM32 HAL库相关API函数，我们可以通过调整那两个目标内存地址的位置来 决定先用哪个内存区。你不妨结合代码再看看和验证。
你在完成2个BANK的工程代码烧录之前，先保证DBANK=1,BFB2=0. 假设你先烧录了放在BANK1的第一个工程代码，地址位于0x800,0000开始的空间。然后在准备第二个将放到BANK2的工程时，请使用跟第1个工 程完全相同的链接配置，也保持 VTOR的0偏移。 第二个工程的调试OK后，将它的 BIN文件 烧写到0x804,0000开始的空间。 两个工程代码都写进芯片后。 此时复位，我们发现代码始终运行的都是BANK1的。 当我们将BFB2改为1时，此时系统就始终运行BANK2的代码了。 当然，如果BFB2=1而BANK2并未写进有效代码时，系统复位后依然会运行BANK1的代码。 这些我这边都做了实际验证的，可以参考。
!(data/attachment/forum/202504/27/101249zket82kq1z4o7lvk.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png") MX cube 里面没有办法配置成PA5
官方的Hal 库里有例程，不妨对照着配置一下。 不同系列的外设多少会有点差异。 另外I2C 同外部电路也有些相关，检查一下线路，看看外部上拉是否合适或内部上拉配置是否需要配置。 软件模拟I2C当然可以实现，了解时序都很容易写出来，网上也有很多参考例程，通常软件模拟跟型号无关了。 只是响应速度相比硬件稍慢一些，应用能满足也可以的。
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脚吧。 该引脚通常是固定的，恐怕不能随意更改。其实，你想下，如果可以随意自行定义，它这里肯定就不用固定下来了。 这样设计应该是基于信号完整性以及时序、硬件设计、系统可靠性等多方面的综合考虑。
从你描述的情况来看，程序卡死跟中断发生的频率强相关。 如果中断频率过高，系统可能会花费过多时间处理中断，导致任务无法及时执行。这可能导致任务队列积压，进而导致电机卡死。 建议尽量减少中断或降低中断频率。比方通过减少中断源或增加中断触发周期，可以有效降低中断频率，削减系统负荷。 同时，确保中断处理程序尽量短小精悍。复杂的处理尽量放在任务中进行，而不是在中断中直接处理。 另外，根据实际需求调整任务优先级，确保关键任务能够及时执行。 注意队列的长度和项大小适合你的应用需求。队列长度过短可能导致队列满无法发送新的事件，过长则可能内存浪费。 还有，注意配置合适的系统栈和任务栈，确保系统和任务有足够的堆栈空间，避免堆栈溢出导致异常。
微信公众号
手机版
