做STM32H750的IAP升级，十个里面有八个会被“片外App卡死”按在地上摩擦。这颗芯片本身没问题，问题在于它的内置Flash只有128KB——对，你没看错，一颗跑480MHz的M7内核，内置存储却抠门到这种程度。所以真正做产品的人，几乎都会把App放在片外Flash上跑（XIP），或者上电后拷贝到RAM里跑。而一旦涉及“片外App”，IAP的复杂度就直接翻倍：Bootloader要管存储初始化、存储器映射、Cache一致性、中断向量表重映射，还要处理跳转瞬间外设状态的残留问题。
这篇我按自己做产品时的实际踩坑经历来写，主要覆盖Bootloader设计、APP接收端怎么配合、片外Flash执行时为什么总是卡死、以及AB分区回滚和固件版本管理怎么落地。适合已经把H750点亮、但想给产品加远程升级或串口升级功能的工程师看。代码和思路可以直接抄，但更重要的是看清楚每一步背后的“为什么”，否则换个板子还是会翻车。
1. 方案选型与整体设计思路
1.1 H750的特殊性：128KB内置Flash带来的连锁问题
先明确一个事实：STM32H750的内置Flash分区里，实际可用的用户区大约是128KB，代码稍微加点图形界面、算法库或者文件系统就顶满了。所以H750的常规玩法是“外挂一片QSPI Flash”，典型型号是W25Q128（16MB）或者W25Q256（32MB），挂在QUADSPI接口上，通过内存映射模式映射到0x90000000地址段。
这一下就把IAP的问题拉高了一个维度。以前在F103上写Bootloader，App放在0x08008000附近，跳转只需要改个向量表和栈顶指针就够了。H750要做片外升级，Bootloader得先初始化QSPI、配置好映射关系，确认外部Flash能读能写，然后才能谈“跳转”这两个字。
另一个容易被忽略的点是：QSPI Flash的读速度远低于内置Flash，如果不在Bootloader和App里慎重处理Cache和时序参数，App跑着跑着突然卡死或者HardFault是家常便饭。很多人第一次调H750 IAP，flash了Bootloader和App，一按复位，板子直接“死给你看”，问题往往就出在这里。
1.2 升级通道怎么选：串口、USB、网络还是SD卡
IAP只是“在应用编程”的统称，真正的传输通道要根据产品形态来定。我的经验是：先定通道，再定协议，最后才写代码。
串口是最常见的，简单可靠，调试方便。Y-Modem协议在IAP里用得非常多，因为它自带校验和重传，PC端工具（SecureCRT、Xshell）都支持，调试时非常省事。缺点是速度一般，115200波特率下升级1MB固件要一分多钟，适合小固件或者有线调试场景。
CAN升级在车载、工控设备里很常见。如果Bootloader已经跑在CAN网络上，升级软件可以通过CAN总线广播升级包，设备端一包一包接收并写入Flash，校验通过后复位运行新固件。注意CAN单帧数据只有8字节，协议分包管理比串口复杂，帧计数和丢失重传机制一定要设计清楚。
USB升级有两条路。一条是DFU模式，STM32原厂自带，但H750的DFU只认内置Flash，片外App还得自己扩展。另一条是把H750的USB Host接口做成U盘模式，用户把固件拷贝到U盘插上去，Bootloader检测到U盘就自动升级。这个体验最好，但对Bootloader的USB协议栈要求较高，代码量会明显上升。
如果有以太网或WiFi模块，OTA升级就是另一套逻辑了，核心还是HTTP或私有协议下载固件到缓冲区，然后走Flash写入流程。热词里提到的“ota升级”“esp32 ota升级”本质都绕不开同一个闭环：下载、校验、写入、回滚。通道只是入口，存储管理和跳转策略才是真正的难点。
1.3 XIP直接执行还是拷贝到RAM：两条路线怎么选
片外App有两种跑法，这是H750 IAP最容易糊涂的地方。
第一种是XIP（Execute in Place），把QSPI Flash内存映射到0x90000000，App编译地址直接指向这个段，上电后Bootloader初始化QSPI，然后直接跳过去执行。优点是实现简单，App代码不用搬，掉电也不丢。缺点是QSPI读速度比内部Flash慢，如果Flash时序配置不对，跑复杂逻辑时容易出问题。一般来说，打开ICache之后性能基本够用，但DCache相关的问题会伴随整个调试过程。
第二种是“拷贝到RAM执行”。Bootloader上电后把外部Flash里的App搬到AXI SRAM（0x24000000）或者外部SDRAM，然后从RAM启动。优点是执行速度快，不受QSPI时序影响，卡死几率低很多。缺点是需要保证RAM空间足够，而且每次上电都要做一次拷贝，App的主频和功耗也会略有增加。
我的建议是：产品MCU主频在400MHz以上、Flash读取速度跟得上的，优先选XIP，代码改动最少；如果App对实时性要求很高、又经常出现随机卡死，可以考虑RAM执行方案。我自己做产品时，小规模固件用XIP，稳定性和速度都能接受。但不管选哪条路，Bootloader里QSPI的初始化和时序配置必须稳，这是片外App能不能跑起来的基石。
2. Bootloader设计：从启动流程到跳转逻辑
2.1 Bootloader该管哪些事
Bootloader不是简单地在启动时问一句“你要不要升级”，它的职责比你想象的多。
从功能上划分，至少要包含这几块：通信模块（串口/CAN/USB/网络）、固件接收与校验、Flash擦写管理、启动项判断与跳转、异常恢复与回滚。如果是片外Flash方案，还要加上QSPI初始化和内存映射配置。每一个模块都有各自的坑，但最重要的其实是后两项：判断该跳App还是进入固件升级流程，以及跳转时能不能把现场收拾干净。
Bootloader本身要尽量小而稳，不要依赖复杂外设，不要开太多中断，更不要在Bootloader里做业务逻辑。它的生命周期很短，要么升级固件，要么跳转App，做完事就赶紧交棒。用H750做Bootloader，如果不加复杂通信协议，一般10KB～20KB就够用，没必要往里面塞一堆用不上的HAL驱动。
2.2 启动流程设计：上电后先干哪一步
一个典型的H750 IAP启动流程可以拆成这样：
- 上电，系统时钟初始化。使用内部HSE或者外部晶振配好锁相环，此时QSPI相关时钟必须保证稳定。
- 初始化串口，打印Bootloader版本号。
- 检测升级触发条件：按键电平、某个标志位（例如备份寄存器里的Magic Number）、或者通信接口是否有升级指令。只要有一个成立，就进入升级模式。
- 如果不需要升级，检查App区有效性：读取App首地址的栈顶指针（MSP）、复位向量，校验CRC或版本号。
- 校验通过，跳转App；校验失败或者App区为空，停留在Bootloader，等待升级指令。
整个过程听起来简单，但每一步都可能出问题。比如时钟配置：如果App里用CubeMX重新配置了时钟，把PLL又改写一遍，而QSPI的时钟源也被重新配置了，外部Flash映射可能当场失效，这在XIP模式下是致命级别的错误。所以Bootloader和App必须约定好：时钟怎么配、哪些外设Bootloader初始化后要保留、哪些必须清干净，这些都需要在接口文档里写清楚。
2.3 跳转App的代码与隐藏的坑
跳转代码网上很多，但80%的写法都少了一些必要的保护。我一般是这样写的：
typedef void (*pFunction)(void); void JumpToApp(uint32_t ulAppAddr) { uint32_t ulMspVal; uint32_t ulResetVal; pFunction jumpFunc; /* 检查App首字是否为合法的栈顶地址 */ ulMspVal = *(volatile uint32_t *)ulAppAddr; if ((ulMspVal & 0xFFF00000) == 0x20000000 || (ulMspVal & 0xFFF00000) == 0x24000000 || (ulMspVal & 0xFFF00000) == 0x30000000) { /* 栈顶地址确认在RAM范围 */ } else { Error_Handler(); } /* 取第二条向量：Reset_Handler */ ulResetVal = *(volatile uint32_t *)(ulAppAddr + 4); /* 跳转前关闭全局中断，避免外设中断残留 */ __disable_irq(); /* 关闭RTT、串口等用到的外设，避免中断干扰App */ HAL_UART_DeInit(&huart1); __HAL_FMC_EXTENDEDMEMORY_DISABLE(); /* 如果用了外部存储器，按需处理 */ /* 设置主栈指针，然后跳转 */ __set_MSP(ulMspVal); jumpFunc = (pFunction)ulResetVal; jumpFunc(); }这段代码有几个要点必须说清楚。
第一，MSP的校验不是摆设。如果你跳转到的地址根本不是一个有效的App，栈顶指针大概率是个非法值，你强行跳过去，马上HardFault。所以跳转之前的防御性检查很关键。
第二，__disable_irq()只关闭了中断使能，不代表外设状态就干净了。比如你在Bootloader里开了串口DMA，DMA还在搬运数据，跳转过去之后DMA中断触发，App的向量表根本不知道这个中断是什么，结果是灾难性的。所以跳转前要主动去初始化Bootloader用过的外设，尤其是UART、DMA、定时器和USB。
第三，如果你用的是XIP方案，QSPI外设绝对不能DeInit，更不能把时钟关了。你一旦把QSPI停了，外部Flash映射直接断开，App的PC指针在0x90000000地址去取指，立刻HardFault。很多人在Bootloader里习惯性调用HAL_QSPI_DeInit清理外设，结果刚跳转就死在入口，找半天找不到原因。正确的做法是：QSPI保持初始化状态，只是把相关中断关闭。
第四，Cortex-M7和Cortex-M3/M4不太一样，它默认可能使用PSP（如果之前跑过RTOS）。跳转App之前，要确保当前使用的是MSP，也就是主栈指针。如果你从FreeRTOS环境里跳转，当前SP是PSP，直接调用__set_MSP后跳转，App的启动代码可能被绕过去。稳妥做法是在跳转前强制使用MSP，再把控制寄存器里CONTROL.SPSEL清零。
3. APP接收端设计：串口升级协议与Flash写入
3.1 自定义升级协议：帧格式、校验、分包与重传
如果你不想依赖Y-Modem，自己写一个简单的升级协议是很有必要的，尤其是走CAN或自定义网络通道时，没有现成协议可用。我习惯用自定义帧格式，结构大致如下：
帧头(2B) 帧类型(1B) 包序号(2B) 数据长度(1B) 数据(NB) CRC32(4B) 0xAA55 0x01 0x0001 0x00 ... ...帧头固定0xAA55，用来做字节对齐和帧同步。帧类型区分三类：固件数据帧（0x01）、结束帧（0x02）、应答帧（0x03）。包序号是当前包在整个固件中的序号，从1开始计数。数据长度一包最好不要超过1KB，因为QSPI按页编程（通常256B一页），接收缓冲区太大反而占用RAM。
每一包发送后，Bootloader必须返回ACK或NAK。上位机收到ACK再发下一包，收到NAK重发当前包，如果超时没收到应答，连续重试三次后中断升级。千万不要把发送速率拉满不管对端，QSPI擦写需要时间，你不做流控，数据就丢在缓冲区里。
在固件传输前，最好先发一个固件头信息：固件总长度、CRC校验、目标地址、设备型号、固件版本号。Bootloader收到头信息后先擦除目标分区，再开始接收数据。这样能避免“传了半天，最后一校验发现版本不匹配”的尴尬情况。
3.2 QSPI Flash写入流程：擦除、编程、校验、掉电保护
很多人一上来就在App里直接调用HAL_QSPI_Transmit往W25Q128写数据，写完发现数据是乱的，或者复位的瞬间板子直接变砖。原因很简单：QSPI Flash写入之前必须先擦除，而且擦除的单位通常是4KB扇区或64KB块，不能只擦一个字节。所以完整的写入流程是这样的：
- 退出内存映射模式。QSPI在内存映射模式下，CPU可以直接读取0x90000000地址，但这时候芯片不能对Flash发出编程或擦除指令。所以写之前，要把QSPI切成间接模式。
- 按扇区擦除目标区域。如果升级的是完整固件，直接把整个App分区擦掉；如果做AB分区，只擦目标B分区。
- 按页编程。W25Q系列一页256字节，编程前要确保写地址偏移和页边界对齐，跨页的数据要拆成两笔写。
- 读回校验。写完一页读一页，CRC或逐字节比较，有错误立即报告，不要等到最后才发现。
- 写完成后再切回内存映射模式，这样Bootloader和App都能重新从0x90000000读取固件。
掉电保护的关键在于写入顺序。我的实践是：先把固件写到“暂存区”或“备份区”，全部写完后验证CRC，验证通过后把状态字（一个Magci Number）写入Flash的状态区，告诉Bootloader“这个分区可用”。如果写入过程中掉电，状态字没有被更新，Bootloader就知道这个分区不完整，不会尝试跳转，而是重新等待升级或者从另一个分区启动。
3.3 APP端必须配合的三件事
App不是只要被Bootloader跳转过去就万事大吉。如果不做下面三件事，片外App卡死是必然的。
第一，向量表重映射。Cortex-M7的向量表地址可以通过SCB->VTOR设置。XIP方案下，最简单的方式是在App启动代码最前面加：
SCB->VTOR = 0x90000000;如果App在RAM里执行，就要写RAM段的首地址。注意向量表地址必须按中断向量表大小对齐，H750如果用全量中断表，一般按0x400对齐就够了。
第二，编译地址要改。App工程里的Link Script必须把Flash段起始地址改成0x90000000（XIP）或0x08020000（内置Flash偏移）。很多人Bootloader写好了，App编译还是从0x08000000开始，跳过去之后PC取到的第一条指令根本不是App，板上所有的表现都令人崩溃。
第三，时钟和外设初始化千万别乱来。App如果使用CubeMX生成代码，启动后SystemInit和main里的时钟配置可能重新初始化PLL，这会把Bootloader配好的QSPI时序打乱。如果Bootloader确实配置了外部Flash并处于内存映射模式，App启动初期应避免重新配置与QSPI相关的时钟树。如果必须配置，一定要先确认QSPI重新初始化能正常工作，否则就等着看随机卡死。
4. 片外App卡死排查：从现象定位到根因
4.1 卡死现象的四种典型表现
片外App卡死不是一种原因，形形色色的现象对应完全不同的根因，必须分类讨论。
第一种，跳转后直接HardFault。这种最常见，原因通常是栈顶指针校验不过、向量表没重映射、或者外部Flash映射没建立。你可以在HardFault_Handler里读SCB->HFSR和SCB->CFSR寄存器，看是哪类错误：如果是总线错误，多半是PC访问了非法地址；如果是指令访问错误，很可能是PC取址到了0x90000000但QSPI根本没有映射。
第二种，上电能跑，几秒到几分钟后不定时卡死。这种随机卡死，优先怀疑Cache一致性和QSPI时序。H750开了DCache之后，如果读取外部Flash的数据区时发生了Cache未命中或写回冲突，就会出现不可预期的卡死。最简单粗暴的验证办法：把DCache关了测试，如果卡死消失了，基本就是Cache一致性问题。
第三种，复位后反复卡在Bootloader或者App跳转死循环。这种大多是升级标志位没清干净，Bootloader每次上电都认为App无效，停在等待升级状态，或者App里立即请求重启。
第四种，App正常运行，但跑着跑着看门狗复位。这个原因常常出在App初始化里外设配置耗时太长，喂狗线程还没跑起来，看门狗已经超时。或者是升级完成后没有及时更新有效标志，Bootloader把新固件判成无效，又切回旧固件，看起来就像每隔几秒重启一次。
4.2 高效排查三段式方法
我排查片外App卡死时，一般按这个顺序来：
第一步，看跳转前状态。用调试器连接H750，在跳转点断点，执行到跳转前，读取QSPI映射的首地址，确认0x90000000处确实有App的数据，且首字是合法的栈顶值（0x20000000或0x24000000段）。这一步能排除90%的“什么都还没跑就死”问题。
第二步，看走没走进App。在App的Reset_Handler第一行设断点，在main第一行设断点。如果Reset_Handler能进但main进不了，问题大概率在启动代码里；如果main进了又死掉，问题在外设初始化或Cache配置。
第三步，看卡死在哪个外设或哪条指令。HardFault发生时，通过调试器读取LR和PC，定位到故障指令。如果是LDR指令访问某地址触发总线错误，检查地址是否落在外部Flash的映射范围内；如果是DMA访问冲突，回到外设配置检查。
这个思路适用于绝大多数现场，比盲猜省太多时间。
4.3 一个实测案例：QSPI采样边沿导致的随机卡死
说个我自己调过的案例。板子用的是W25Q256，Bootloader和App都正常，上电能跑，但是只要环境温度稍微升高或者操作界面切换得频繁，电脑上测试时隔几分钟就卡死一次。
一开始怀疑代码逻辑问题，加了大量打印也看不出规律。后来怀疑Cache，把DCache关掉，卡死频率明显下降但偶尔还是复现。最后用逻辑分析仪抓QSPI时序，发现Flash读指令的采样边沿设置不对，在时序余量不足的临界状态下，偶尔会读回错误数据。
解决办法是把QSPI的采样边沿改成“下降沿采样”，同时把Dummy Cycles从4调到6，降低一点Flash读取时钟频率，让时序余量更充足。这个案例说明，很多“随机卡死”最终是时序余量问题，不是软件逻辑问题。如果你也遇到那种“换一块板子就好了”的玄学问题，建议先用示波器或逻辑分析仪看一遍QSPI时序，再回头怀疑代码。
5. 升级安全与回滚：AB双分区策略落地
5.1 为什么要做AB分区而不是原地刷写
最基础的IAP是“原地升级”：Bootloader接收固件，直接擦写当前App区，写完后跳转。这种做法最省Flash空间，但有个致命弱点：如果升级过程中掉电、擦写失败、或者固件本身有bug，设备就彻底变砖，只能拆机用烧录器救回来。
产品量产之后，“变砖”是不可接受的。所以更稳妥的做法是AB双分区：把Flash分成两个App区，Slot A和Slot B，一个放当前运行的固件，另一个放新固件。升级时把新固件写入不活跃的那个分区，全部写完后校验通过，再切换启动标志。下次复位后，Bootloader从新分区启动；如果新固件启动失败，Bootloader再自动回滚到旧分区。
H750外挂一片16MB的W25Q128，完全有条件做两个4MB甚至更大的App分区。每个分区头部放一个状态字：VALID表示分区可用，INVALID表示分区不完整或已被放弃。
5.2 AB分区升级与回滚的状态机
升级流程可以概括成一张状态机：
- Bootloader检查Slot A和Slot B的状态字，选择有效的一个启动。
- 上位机发送新固件头，Bootloader把固件写入“非当前启动”的那个分区。
- 写入完成，CRC校验通过，把新分区状态字置为
VALID，同时把旧分区状态字保留为VALID作为备份。 - 复位。
- Bootloader再次启动，发现新分区
VALID，跳转到新分区。 - App启动后，开始喂独立看门狗。如果30秒内没有喂狗成功（例如App崩溃），看门狗复位。
- Bootloader检测到“启动尝试次数”超过设定阈值（比如3次），自动把新分区状态字置为
INVALID，回滚到旧分区启动。
这个流程的关键在于“尝试次数”标志。如果只用一个状态字，App启动失败后状态字已经是VALID，Bootloader每次都会尝试启动新App，又每次失败，陷入死循环。所以要在备份寄存器或者Flash里存一个“启动失败计数”，每次跳转前递增，App正常启动后清零。
关于版本管理，我再加一条：每个固件头部不要只放版本号，还要放“设备型号ID”。否则一个产品系列里有多个硬件版本，固件内核一致但外设配置不同，刷错型号的固件会导致外设初始化异常。我在实际项目里吃过这个亏：一条产线上的两种板子共用一套IAP流程，有人拿A板的固件刷了B板，结果屏幕不亮、CAN不通，查了半天才发现是版本型号没匹配上。所以即便做的是小批量产品，设备型号ID的检查和版本号一样重要。
5.3 掉电保护与升级过程的“原子性”
AB分区解决的是“升级后启动失败”的回滚问题，但升级过程中掉电是另一回事。我见过不少方案，升级写到一半断电，结果Bootloader被迫重刷，客户体验很差。
要提升升级过程的抗掉电能力，核心原则是“状态先置无效，数据写完再置有效”。具体做法：
- 升级开始前，把目标分区状态字清为
INVALID。 - 接收固件数据，逐包写入目标分区。
- 全部写完，CRC校验通过，再把状态字置为
VALID。 - 如果中间掉电，目标分区状态字保持
INVALID，Bootloader会直接忽略这个分区，继续从另一个分区启动。
这里要注意的是“状态字写入”本身也要防止掉电导致写一半。W25Q系列的状态字一般放在单独的扇区，写入前先擦除，再写一页。如果担心异常，可以把状态字连续写两遍甚至三遍，读取时以多数为准。这个“冗余写”的技巧虽然原始，但对防止Flash半写状态非常有效。
6. 调试工具与个人经验分享
6.1 串口日志和J-Link RTT怎么配合
调试IAP最痛苦的阶段是“不知道卡在哪一步”。我强烈建议Bootloader从一开始就带串口日志，而且日志前缀要和App区分开。比如Bootloader打印[B] Bootloader v1.0，跳转前打印[B] Jump to App 0x90000000，App启动后打印[A] App v2.1.3 started。这样用串口助手一拉日志，就能判断是Bootloader的问题还是App的问题。
J-Link RTT也很有用。RTT不占用串口引脚，而且速度快，可以在RTOS环境里直接输出日志。缺点是RTT需要调试器连着，不适合产线测试，但开发阶段排查随机卡死时，RTT加SEGGER SystemView的组合能看到实时任务调度情况和异常发生时的调用栈，比串口日志更直观。
我自己常用的调试套路是：开发阶段串口日志和RTT一起开，串口看Bootloader阶段，RTT看App阶段；量产时关闭RTT，只留串口错误日志，日志量压缩到只记录关键事件。
6.2 我会用的上位机与命令行小工具
做IAP升级，上位机可以简单也可以复杂。如果只是调试，我用Python写一个几十行的小脚本就够，核心功能就是读bin文件、分包、发送、等待ACK、计算CRC。类似这样：
import serial, struct, binascii ser = serial.Serial('COM10', 115200, timeout=1) firmware = open('app.bin', 'rb').read() pack_size = 1024 seq = 1 for offset in range(0, len(firmware), pack_size): data = firmware[offset:offset + pack_size] frame = struct.pack('<HBBH', 0xAA55, 0x01, seq, len(data)) + data crc = binascii.crc32(frame) & 0xFFFFFFFF frame += struct.pack('<I', crc) ser.write(frame) ack = ser.read(1) if ack != b'\x06': print('NAK at packet', seq) break seq += 1如果不想写代码，Y-Modem工具也可以，配合SecureCRT就能手动传固件。我在实验室调试时经常直接用它，省时省力。Linux下用sb命令也可以发Y-Modem。
bin转hex、hex转bin这类格式转换，多用arm-none-eabi-objcopy，一次搞定，不用另装工具。
6.3 我的个人踩坑清单和习惯
做H750 IAP久了，我总结出几条铁律：
新打样的板子，先不要跑任何业务代码，先把Bootloader跑通，确认QSPI读写没问题、跳转没问题，再开始写App。这个顺序不能反，否则你调试时根本分不清是硬件问题还是软件问题。
每次跳转前，干三件事：检查App栈顶地址合法性、关闭全局中断、清理非必要外设。这三步少一步，后面都会加倍还回来。
全片擦除只在新板才用。正常升级时，严格按目标分区擦除，千万别把整个Flash擦了，否则另一分区的备份固件也没了，一旦新固件失败就没有回滚的机会。
最后，关于QSPI时序参数，如果对Flash型号没有十足把握，就用保守配置：时钟频率先降到50MHz左右，Dummy Cycles设大一点，等跑稳定了再慢慢提升。时序余量这个东西，不是每个板子都一样的，批量生产时PCB走线差异会让临界参数直接变成事故现场。
升级功能本身不难，难的是把升级做到“升级失败也不怕”。我自己的体会是：把最坏情况都想到并处理掉，产品才敢真正发到客户手里。如果你也正在调H750的IAP，建议先把AB回滚和掉电保护做完，再去优化升级速度和体验。稳定压倒一切，这句话在固件升级这件事上永远不会过时。
