根本原因

stm32在IAP擦除sector时会停止取指操作，也就是MCU卡住了，这是根本的问题，导致我在研发产品过程中遇到过很多难点。

问题：

我做的都是工业产品，STM32基本不用内部看门狗，要外挂硬件看门狗，常用的硬件看门狗DS1832的复位时间是1秒多，而且这个看门狗是不能关闭的，也就是一上电就一直运行，无论任何情况下，如果喂狗不及时，就会复位。

我的产品支持远程升级功能，也就预示着要做IAP操作，STM32内部的FLASH擦除时间如下：

按最快的32位擦除来算，典型值1秒，最慢达2秒，而在擦除期间FLASH的取指令操作会中止，当然喂狗也就停止了，要命的来了，STM32会在擦除内部块时复位，

解决方法1：

STM32一些高端的单片机，内部都是有2M FLASH空间的，其中分成2部分，比如下面的STM32H7XX的框图，虽然它内部也是2M FLASH，但是从物理上就分成了2块FLASHA? ?FLASHB。

于是我猜测，如果程序在FLASHA中运行，是不是就可以对FLASHB进行擦除操作呢？答案是肯定的，我程序运行在FLASHA，对FLASHB擦除块，在擦除的1秒时间内，SysTick_Handler()中断服务函数可以执行，uwTick记数器变化正常，也就是说FLASHB擦除操作不影响FASHA的取指令，因此为了在擦除FLASH期间，也能够正常喂狗，我在SysTick_Handler()函数中增加了在擦除FLASH时的喂狗操作，擦除完毕后就不再在SysTick_Handler()中喂狗了。

引申：

既然2个物理块FLASH之间可以可以擦除，不影响的对方的取指执行，那么，相信普通STM32内部FLASH也不是铁板一块，应该也是一个个sector组成的，如果2个sector离的比较远，那么有没有可能彼此擦除也是不影响对方的取指令呢？试验证明，答案是肯定的，

如上图，我的boot程序运行在扇区0~3，如果应用程序运行在扇区5及以上扇区，boot程序在擦除应用区的同时可以正常取指令，但是如果APP放在扇区4，boot程序擦除APP区时就会“卡住”boot程序的运行。(这种方法会存在内部FLASH空间的浪费！)

上面的测试只是经验，没有任何理论依据，也许stm32f407是这样，stm32f405就不是这样，所以要根据你使用的stm32种类来做测试确认。

终极解决方法2：

? ? 根本思路，当stm32擦除内部FLASH时会停止从FLASH取指，这个也好理解：自己擦除自己的时候，怎么还可能从自己内部取数据呢？? 但是我STM32自己擦除自己的时候，能不能响应一个位于内部RAM空间的SysTick_Handler()中断函数，而在SysTick_Handler()内执行喂狗操作。如果这样能够实现就不用再看内部FLASH块的眼色了，只要是stm32内部flash 扇区，想怎么分配就怎么分配。就可以充分利用stm32内部FLASH的空间了，

? 这种方法也是可以的，这种方法最大的难点在于，

把中断向量表重新搬移到RAM区，如果中断向量表位于FLASH区，那么擦除内部FLASH时，连中断也进不去，因此取不到中断服务函数的地址，

把中断服务函数也要定位在RAM中，这些都可以在编译时，增加__attribute__((section("RAMCODE")))修饰来实现。

我在测试过程中，参考了官方的一个例子。《KEIL中让程序在RAM中运行的办法.pdf》里面有详细的文档，与例程。

如果要我自己实现，我肯定是手动的把FLASH区的中断向量表一个一个的拷贝到RAM区，但是中这个文档中给出了一个更为简洁的方法，它新建了一个一个汇编文件，文件中定义了一个RESET_ram，把所有的中断向量import到此文件中，这样程序在编译的时候，就会在RAM里自动生成一个备份的中断向量表，我们要做的只是在system_stm32f4xx.c初始化时，重定向一个中断向量表到0x20000000就行了。