呵呵 这里不必拘泥于术语的称谓了，知道做什么用的即可。具体到这里，本质上就是一段代码，基于特定事件、条件才被调用的功能代码。 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 调用到的函数，以及会访问的相关数据/常量
厂家有现成的例程，可以跑跑或参考一下 STM32Cube_FW_L4_V1.18.2\Projects\NUCLEO-L476RG\Examples\FLASH\FLASH_EraseProgram
也没有什么莫名其妙的。 你说能正常执行到这个标志检查时，说明不是stall状态是对的。但待退出之后，再检查这个标志 就是很自然的一件事情。 就好像你在做一件事情，正在忙的时候不会理睬他人的要求，做完后方可以响应别人的要求一样。当你做完事情，别人问你此时忙不忙，你当然知道自己此刻忙不忙，或者说忙完没有。 在同区做flash擦、写时，的确是有这个临时堵塞问题。所以，这时候要特别注意这个过程中其它中断的处理问题，如何处理结合应用场景来。 有条件的话，可以选用双FLASH bank 芯片来操作，对于没有双BANK的，可以考虑将那部分不期望FLASH擦写影响的代码，主要是中断服务程序放到RAM也是可以的。
你估计要自己做一个基于STM32H743及你目前硬件线路的外部下载算法文件，即externalloader ,这个有很多资料可以参考。 做好后，你可以使用stm32cubeprogrammer单独烧录，也可以在VS CODE里的terminal 运行 STM32_Programmer_CLI 命令行来加载，你可以看看Help的相关操作。
两方面问题要注意： 1、数据缓冲是否安排到了DTCM，如是，普通DMA访问不到，需要另行安排位置； 2、还有可能因为DCache导致的缓存与实际内存数据不同步导致的问题，此时就需要做cahce维护操作。 此时可以先暂时关闭Dcache进行测试。
.png)
