呵呵 这里不必拘泥于术语的称谓了，知道做什么用的即可。具体到这里，本质上就是一段代码，基于特定事件、条件才被调用的功能代码。 STM32 库里面的回调函数，准确地讲，库里并没有完整的现存的回调函数，只是准备了些有名无实的空壳或函数指针。 是的，那些回调函数主要是为各种中断服务准备的，但不是全部。因为还有些回调函数是为各种初始化事件准备的。 另外，STM32 库里的回调函数其实有两套，一套是weak 替换型，使用时将weak 拿掉填写相关代码即可；还有一套就是实时注册型，即使用函数指针绑定相关的回调函数。 这里刚好有篇文章专门介绍STM32 库的回调函数的，你可以阅读参考。 [LAT1241 浅谈STM32库里的回调函数 | STMCU中文官网
在 Flash 擦除/编程期间，只要 CPU还要访问正在忙的 Flash，就会发生 bus stall（总线停顿）；代码取指、数据读取、向量表取址都会被阻塞，直到擦除/编程完成后才恢复执行。 如果想在 Flash擦写期间继续执行，必须把相关内容 全部放到 RAM，包括： 启动擦写的代码所有相关中断处理函数中断向量表 否则即使你把中断处理函数和向量表搬到了SRAM，如果发起Flash 擦写的代码本身还在Flash 中，执行仍可能因为Flash 忙而停住。 主要风险是“暂停/卡住/响应超时”，而不是“因为中断发生就必然运行错误”。但在工程上，这种停顿仍然可能间接引发功能异常，例如： 1.实时中断来不及处理 2.通信超时 3.看门狗喂狗不及时 4. 控制环中断抖动或失步这些属于 由长时间 stall 带来的系统级后果； 通常处理的方式有两类：1. 在 Flash 擦写期间禁用中断，在编程/擦除期间关闭中断，避免中断打断后又去访问 Flash。2. 必须并行运行的代码全部搬到RAM如果你必须在擦除期间继续响应某些中断，那么需要把下面内容都放到RAM： Flash 擦写发起代码 中断向量表 ISR ISR 调用到的函数，以及会访问的相关数据/常量
也没有什么莫名其妙的。 你说能正常执行到这个标志检查时，说明不是stall状态是对的。但待退出之后，再检查这个标志 就是很自然的一件事情。 就好像你在做一件事情，正在忙的时候不会理睬他人的要求，做完后方可以响应别人的要求一样。当你做完事情，别人问你此时忙不忙，你当然知道自己此刻忙不忙，或者说忙完没有。 在同区做flash擦、写时，的确是有这个临时堵塞问题。所以，这时候要特别注意这个过程中其它中断的处理问题，如何处理结合应用场景来。 有条件的话，可以选用双FLASH bank 芯片来操作，对于没有双BANK的，可以考虑将那部分不期望FLASH擦写影响的代码，主要是中断服务程序放到RAM也是可以的。
今天看了下 有个函数的内容是写flash 写的过程中会关中断 测试无果 发现ST官方曾发表过一篇与我的情况类似 都是关DMA顺序不对导致的偶发性bug 文章编号为LAT1236 看似无法唤醒的一种异常现象分析 不同点可能就是它关DMA用的是把DMA时钟关掉 我使用的是HAL_DMA_Abort 遗憾的是上面并未提出导致BUG的真正原因以及复现思路 希望可以获取官方当时处理bug的笔记或者思路 求助求助
