呵呵 这里不必拘泥于术语的称谓了，知道做什么用的即可。具体到这里，本质上就是一段代码，基于特定事件、条件才被调用的功能代码。 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也是可以的。
关于前段时间SDADC卡死的那个问题 我想了想 结合目前的现象 推导出的合理机制是 在溢出的同时擦除flash会导致溢出位无法正常清零 卡住置1 而手册上明确指出 当溢出位置为1的时候 SDADC无法响应新的触发请求 这就会导致SDADC无法正常更新而主循环及其他中断可正常触发的现象 原工程代码中4h写一次flash 也符合几个月撞上一次的这个触发频率 在没有擦除Flash操作时，SDADC中断回调函数内里有一个函数会自动等待转换完成，同时使得状态寄存器复位，溢出位清零。 但现在，由于SDADC溢出位卡住置1使得无法响应触发请求，导致： 程序无法进入SDADC中断； 溢出位一直卡死为1； 最终造成中断失效和ADC无法采集数据。 目前的现象完全符合之前的描述，而关于SDADC溢出的原因，推测是由MCU内部的通讯或其他控制任务以及长时间运行导致溢出。 同时观察到如果在调试模式下是无法稳定复现该bug的，需上电时全速运行可稳定复现。
