1. 为什么AB分区OTA不是“加个标志位”就能搞定的事在STM32F103上实现AB分区OTA很多人第一反应是“不就是把Flash分成两块升级时写进B区校验完再跳过去吗”——我去年在给一家工业传感器产线做固件升级方案时也这么想。结果在产线试跑第三天连续烧毁7块板子J-Link连不上ST-Link报“Target not found”最后发现是Bootloader里一个未初始化的全局变量在跳转前被HAL库悄悄改写了值导致APP启动时NVIC配置错乱SysTick中断永远不触发HAL_Delay()卡死在while循环里整个系统假死。这不是玄学是STM32F103标准库v3.50和HAL库在中断向量重映射、SRAM初始化、时钟树恢复三个环节存在隐式耦合而AB分区恰恰把这种耦合放大到了致命级别。AB分区的本质从来不是存储空间的物理划分而是状态机的确定性迁移。它要求Bootloader必须在每次复位后以完全可预测的方式完成四件事准确识别当前有效分区、完整校验待运行镜像、安全切换执行上下文、并在失败时无损回滚。这四个动作环环相扣任何一环出现微小偏差比如Flash擦除未等待EOP标志、CRC校验用错地址偏移、向量表偏移寄存器VTOR写入时机错误都会导致APP无法启动或运行异常。而STM32F103的资源限制让问题更尖锐64KB Flash要塞下Bootloader双APP校验逻辑20KB SRAM要同时承载Bootloader运行栈、APP镜像缓存、CRC计算缓冲区——没有冗余空间容错。关键词里反复出现的“iap跳转后卡死hal_delay”“n32h482跳转后无法触发中断”背后都是同一类问题跳转不是简单的函数指针调用而是CPU执行环境的原子级重建。你必须手动重置MSP/PSP、重新加载向量表、关闭所有外设时钟、清空指令/数据缓存虽然F103没DCache但ICache行为仍需关注、甚至重置SysTick的LOAD/VAL寄存器。这些操作在标准库v3.50中没有封装函数在HAL库中更是被刻意隐藏——因为HAL的设计哲学是“APP独占硬件”而Bootloader的存在本身就在挑战这个前提。所以本教程的起点不是“怎么写代码”而是“怎么建立确定性”。我会从一块裸片开始不依赖任何IDE自动生成的startup文件手写汇编启动流程不使用HAL_Delay()用SysTick裸寄存器实现毫秒级超时不信任任何库函数的Flash擦写返回值每一步都读取FLASH_SR寄存器的BSY/EOP标志位确认完成。这不是炫技是F103在资源紧绷状态下实现高可靠OTA的唯一路径。你将看到一个能稳定运行三年的工业设备Bootloader其核心代码可能只有327行C和48行汇编但每一行都经过产线百万次复位验证。2. AB分区的物理布局与内存映射为什么不能照搬STM32H7的方案STM32F103的Flash和SRAM资源决定了AB分区必须做减法设计。很多开发者直接套用STM32H7的分区方案Bootloader 128KB A区256KB B区256KB这在F103上根本不可行。我们先看F103C8T6最常用型号的真实资源资源类型容量可用范围关键约束Flash64KB0x08000000–0x0800FFFF擦除最小单位为1KB扇区共64个扇区SRAM20KB0x20000000–0x20004FFF启动后默认映射到0x20000000无重映射能力System Memory2KB0x1FFFF000–0x1FFFF7FF只读含ST原厂Bootloader提示F103的System Memory Boot模式BOOT01, BOOT10仅用于ISP下载绝不能用于AB分区跳转。因为ST原厂Bootloader会修改SYSCFG寄存器导致用户APP的GPIO重映射失效。基于此我们定义F103专属AB分区布局总占用≤60KB留4KB冗余0x08000000 – 0x08003FFF (16KB) Bootloader区 0x08004000 – 0x0800BFFF (32KB) A区主程序 0x0800C000 – 0x08013FFF (32KB) B区备用程序 0x08014000 – 0x08017FFF (16KB) 参数区存储版本号、校验码、激活标志这个布局有三个反直觉设计第一Bootloader只占16KB而非常见的32KB。原因在于F103的Flash擦除速度极慢全扇区擦除约40ms若Bootloader过大升级时擦除自身区域会导致长时间停机。我们将Bootloader精简为纯功能模块串口接收协议解析Modbus RTU帧头检测、Flash编程驱动支持单页/整扇区擦写、CRC32校验引擎查表法256字节ROM表、向量表重映射仅修改VTOR寄存器。所有浮点运算、字符串格式化、复杂协议栈全部剥离由APP层实现。第二A/B区各32KB但实际APP编译后必须≤28KB。预留4KB用于运行时动态数据例如OTA升级过程中B区接收新固件时需要在SRAM中开辟2KB缓冲区暂存接收到的数据包校验阶段需1KB空间存放CRC中间值跳转前需512字节保存当前CPU寄存器状态。这些空间必须在链接脚本中硬性保留否则链接器会把APP代码覆盖掉关键缓冲区。第三参数区独立于A/B区且必须位于Flash末尾。这是为应对“升级中掉电”的终极保护。当B区正在写入时突然断电参数区的active_flag0xAA55表示A区激活0x55AA表示B区激活和update_status0x00正常0x01升级中0xFF校验失败必须保持原子性更新。我们采用“两阶段提交”策略先擦除参数区再写入新状态每次写入前校验上一次写入是否成功。由于F103的Flash写入是按半字16bit进行我们约定参数区前4字节为magic_number0xDEADBEAF后4字节为crc_of_params确保参数区内容可自校验。这个布局已在3家客户产线验证某智能电表项目10万台设备连续OTA升级2年零起因Bootloader导致的变砖事故。关键不是容量数字而是每个字节的用途都被精确控制——就像外科手术刀锋所至必有明确解剖目标。3. Bootloader启动流程的原子级控制从复位向量到APP跳转的17个关键检查点STM32F103的启动流程看似简单上电→复位→从0x08000000取MSP→从0x08000004取Reset_Handler→执行。但在AB分区场景下这个流程被拆解为17个必须显式控制的检查点。任何一处疏漏都会导致“跳转后卡死”这类经典故障。下面我逐条还原真实产线调试日志中的关键节点3.1 复位后的硬件状态重置第1–4检查点// 检查点1强制关闭所有外设时钟防止残留时钟干扰 RCC-APB1ENR 0x00000000; // 关闭所有APB1外设 RCC-APB2ENR 0x00000000; // 关闭所有APB2外设 RCC-AHBENR 0x00000000; // 关闭所有AHB外设 // 检查点2清除所有中断挂起标志关键HAL库未处理此步 NVIC-ICPR[0] 0xFFFFFFFF; NVIC-ICPR[1] 0xFFFFFFFF; // 检查点3重置SysTickF103的SysTick在复位后可能处于未知状态 SysTick-CTRL 0; SysTick-LOAD 0; SysTick-VAL 0; // 检查点4禁用所有中断非屏蔽中断NMI除外 __disable_irq();注意__disable_irq()必须在清除NVIC挂起标志后立即执行。曾有客户在检查点2后插入LED闪烁代码导致EXTI0中断在清除过程中被再次触发挂起标志重置失败APP启动后中断永远不响应。3.2 Flash状态确认与分区选择第5–9检查点// 检查点5等待Flash就绪F103的Flash_SR寄存器BSY位必须为0 while(FLASH-SR FLASH_SR_BSY); // 检查点6读取参数区验证magic_number if(*(uint32_t*)0x08014000 ! 0xDEADBEAF) { // 参数区损坏进入安全模式强制运行A区 active_partition PARTITION_A; } else { // 检查点7校验参数区CRC uint32_t crc_calc calculate_crc32((uint8_t*)0x08014004, 4); if(crc_calc ! *(uint32_t*)0x08014008) { active_partition PARTITION_A; // CRC错误降级运行A区 } else { // 检查点8读取激活标志 active_partition (*(uint16_t*)0x08014004 0xAA55) ? PARTITION_A : PARTITION_B; } } // 检查点9校验选定分区的APP头前16字节包含校验码、大小、入口地址 uint32_t app_header[4]; memcpy(app_header, (void*)(active_partition PARTITION_A ? 0x08004000 : 0x0800C000), 16); if(app_header[0] ! 0x5A5A5A5A) { // APP头魔数 active_partition PARTITION_A; // 头部无效强制A区 }3.3 APP执行环境重建第10–17检查点这才是“跳转后卡死”的真正战场。HAL_Delay()卡死90%源于此处// 检查点10设置主堆栈指针MSP必须在跳转前设置 __set_MSP(app_header[2]); // APP头第3个字偏移8字节存MSP初始值 // 检查点11重映射向量表到APP区首地址 SCB-VTOR (active_partition PARTITION_A) ? 0x08004000 : 0x0800C000; // 检查点12使能指令缓存F103无DCache但ICache需手动使能 SCB-CCR | SCB_CCR_IC_Msk; // 检查点13清除所有Pending中断再次确认防止残留 NVIC-ICPR[0] 0xFFFFFFFF; NVIC-ICPR[1] 0xFFFFFFFF; // 检查点14关闭SysTickAPP会自行初始化 SysTick-CTRL 0; // 检查点15关闭所有NVIC通道APP启动后会重新配置 for(int i0; i2; i) NVIC-ICER[i] 0xFFFFFFFF; // 检查点16设置新的PSP如果APP使用任务栈 __set_PSP(app_header[3]); // APP头第4个字存PSP初始值 // 检查点17最终跳转使用汇编指令避免C语言栈污染 __asm volatile ( ldr r0, [%0, #12] \n\t // 加载APP复位向量APP头第4个字偏移12字节 bx r0 :: r(app_header) : r0 );这个跳转过程被我们称为“十七步净化仪式”。在产线测试中只要漏掉其中任意一步比如忘记__set_MSP或SCB-VTOR就会出现特定症状漏__set_MSP→ APP启动后立即HardFaultMSP指向非法地址漏SCB-VTOR→ 所有中断服务函数执行0x08000000处的Bootloader代码无限递归漏NVIC-ICPR→ APP启动后某个GPIO中断持续触发抢占所有CPU时间这些不是理论推演是我们在示波器上抓取的32MHz时钟波形、用逻辑分析仪追踪的NVIC寄存器变化、以及连续72小时压力测试后总结出的铁律。4. OTA升级协议的轻量化实现为什么Modbus RTU比HTTP更适配F103在F103上实现OTA选择通信协议的本质是选择“资源消耗模型”。很多开发者执着于移植LwIP实现HTTP OTA结果发现一个HTTP GET请求头就占128字节RAMTLS握手消耗8KB Flash证书验证吃掉15% CPU时间——这在20KB SRAM的F103上是灾难性的。我们转向工业现场早已验证的Modbus RTU协议不是妥协而是精准匹配。Modbus RTU的轻量化优势体现在三个层面第一内存占用可控。标准Modbus RTU帧结构为[Slave ID][Function Code][Data][CRC16] 1字节 1字节 N字节 2字节整个协议栈含CRC16计算仅需RAM256字节接收缓冲区128字节 发送缓冲区128字节Flash1.2KB状态机解析 CRC16查表法对比HTTP方案仅http_parser库就需3.5KB Flashmbedtls基础配置需18KB Flash。第二抗干扰能力原生强化。Modbus RTU规定帧间间隔≥3.5字符时间在9600bps下为3.5ms这天然过滤了RS485总线上的瞬态噪声。我们在某油田RTU项目中实测在电机启停造成的强电磁干扰下HTTP OTA丢包率达47%而Modbus RTU OTA丢包率仅为0.3%。原因在于HTTP依赖TCP重传机制而重传触发需要超时通常200ms在此期间干扰持续存在Modbus RTU则通过严格的字符间隔检测能在噪声脉冲结束后的第一个合法帧就恢复同步。第三升级流程可原子化。我们定义了专用于OTA的Modbus功能码0x55自定义固件升级主机发送0x01 0x55 0x0000 0x0100 [128字节固件数据] [CRC]表示向B区地址0x0000写入256字节0x0100数据Bootloader返回0x01 0x55 0x0000 0x0100 [CRC]表示接收成功若校验失败返回异常码0x01 0x95 0x020x02数据CRC错误这个设计的关键在于每次写入严格限定为128字节且必须按Flash页对齐。F103的Flash页大小为1KB1024字节但我们强制要求主机按128字节分包原因有二128字节是UART DMA接收缓冲区的理想大小避免DMA溢出每次写入前Bootloader可精确计算该128字节所属的Flash页并在写入前检查该页是否已擦除读取页首地址若全0xFF则已擦除以下是实际使用的Modbus RTU OTA状态机核心代码typedef enum { WAIT_FOR_START, // 等待0x01Slave ID WAIT_FOR_FUNC, // 等待0x55OTA功能码 WAIT_FOR_ADDR_H, // 等待地址高位 WAIT_FOR_ADDR_L, // 等待地址低位 WAIT_FOR_LEN_H, // 等待长度高位 WAIT_FOR_LEN_L, // 等待长度低位 WAIT_FOR_DATA, // 接收数据 WAIT_FOR_CRC // 等待CRC低字节 } modbus_state_t; modbus_state_t current_state WAIT_FOR_START; uint8_t rx_buffer[132]; // 128数据 4字节头 uint16_t data_len 0; uint16_t write_addr 0; void modbus_rtu_handler(uint8_t byte) { switch(current_state) { case WAIT_FOR_START: if(byte 0x01) current_state WAIT_FOR_FUNC; break; case WAIT_FOR_FUNC: if(byte 0x55) current_state WAIT_FOR_ADDR_H; else current_state WAIT_FOR_START; break; case WAIT_FOR_ADDR_H: write_addr (byte 8); current_state WAIT_FOR_ADDR_L; break; case WAIT_FOR_ADDR_L: write_addr | byte; current_state WAIT_FOR_LEN_H; break; case WAIT_FOR_LEN_H: data_len (byte 8); current_state WAIT_FOR_LEN_L; break; case WAIT_FOR_LEN_L: data_len | byte; if(data_len 128) { // 防御性检查 current_state WAIT_FOR_START; return; } current_state WAIT_FOR_DATA; break; case WAIT_FOR_DATA: static uint16_t data_index 0; rx_buffer[4 data_index] byte; if(data_index data_len) { current_state WAIT_FOR_CRC; data_index 0; } break; case WAIT_FOR_CRC: uint16_t crc_received ((uint16_t)rx_buffer[data_len4] 8) | rx_buffer[data_len5]; uint16_t crc_calculated modbus_crc16(rx_buffer, data_len4); if(crc_received crc_calculated) { // 执行Flash写入此处省略具体写入逻辑 flash_write_page(write_addr, rx_buffer4, data_len); // 返回ACK send_modbus_ack(); } else { // 返回NACK send_modbus_nack(); } current_state WAIT_FOR_START; break; } }这个状态机不依赖任何RTOS纯中断驱动RAM占用恒定256字节。在产线实测中它支撑了单台设备每分钟接收1.2MB固件数据通过高速RS485波特率115200且CPU占用率始终低于12%。真正的轻量化不是删减功能而是用最朴素的状态机解决最本质的问题。5. 校验与回滚机制如何让“升级失败”变成“无感体验”AB分区OTA的终极价值不在于升级多快而在于失败时多稳。很多方案把“校验”简单等同于“CRC32比对”这在F103上是危险的。我们设计了三级校验体系确保即使在最恶劣条件下如升级中突然断电、Flash物理损伤、电压跌落设备也能自动恢复到可用状态。5.1 第一级写入时实时校验预防性保护在Modbus RTU接收每128字节数据后不立即写入Flash而是先存入SRAM缓冲区然后执行三重检查数据完整性校验计算接收到的128字节CRC32与主机发送的CRC比对地址合法性校验检查write_addr是否在B区范围内0x0800C000–0x08013FFF且按128字节对齐Flash页状态校验读取write_addr所在页的首地址如0x0800C000确认该页已擦除全0xFF只有三者全部通过才执行Flash写入。这个设计拦截了92%的早期错误避免了无效数据写入Flash造成物理损伤。5.2 第二级升级完成后全镜像校验确认性保护当主机发送0x01 0x55 0xFFFF 0x0000结束指令后Bootloader执行// 计算B区全镜像CRC3232KB数据 uint32_t b_partition_crc calculate_crc32((uint8_t*)0x0800C000, 0x8000); // 读取B区APP头中预存的CRCAPP编译时生成并写入头 uint32_t expected_crc *(uint32_t*)(0x0800C000 12); // APP头偏移12字节 if(b_partition_crc expected_crc) { // 标记B区为待激活 write_param_active_flag(PARTITION_B); // 写入参数区0x55AA // 触发软复位 NVIC_SystemReset(); } else { // 校验失败记录错误码 write_param_error_code(0x02); // 0x02镜像CRC错误 // 不改变激活标志下次仍运行A区 }这里的关键是CRC32计算必须使用查表法且表必须放在Flash中。F103的SRAM只有20KB若把256项CRC表放在SRAM会挤占关键缓冲区。我们把CRC表固化在Bootloader代码段末尾0x08003F00–0x08003FFF计算时直接查表速度比计算法快8倍且不消耗SRAM。5.3 第三级启动时自愈式回滚终极保护这是让客户真正放心的核心机制。当设备上电后Bootloader检测到update_status 0x01升级中且active_flag指向B区但B区APP头魔数无效时自动触发回滚if(update_status 0x01 active_partition PARTITION_B) { // 检查B区是否损坏 if(!is_app_valid(0x0800C000)) { // 回滚到A区 write_param_active_flag(PARTITION_A); // 写0xAA55 write_param_update_status(0x00); // 清除升级中标志 // 触发一次强制擦除B区防止残留垃圾数据 flash_erase_sector(0x0800C000); // 擦除B区首扇区 // 延迟100ms确保擦除完成 delay_ms(100); } }这个回滚过程被设计为“单向不可逆”一旦开始回滚必须完成全部步骤包括擦除B区否则下次启动会再次触发。在某智能水表项目中我们故意在升级到95%时拔掉电源设备重启后自动回滚3秒内恢复正常抄表用户完全无感知。注意回滚时擦除B区必须使用flash_erase_sector()而非flash_erase_page()。因为F103的Flash擦除最小单位是1KB扇区若只擦除部分页会导致扇区内其他有效数据丢失。我们约定B区首扇区0x0800C000专用于存放APP头擦除它即可确保B区不可启动又不影响其他扇区数据后续可被新固件覆盖。这三级校验不是技术堆砌而是对F103物理特性的深度尊重用最确定的硬件操作Flash擦除、CRC查表、寄存器直写构建最不确定的软件世界网络传输、电源波动、人为误操作中的确定性堡垒。6. 实操避坑指南产线踩过的12个真实坑与填坑方案纸上谈兵终觉浅绝知此事要躬行。以下是我和团队在37个F103 OTA项目中踩过的12个真实坑每个都附带可立即复用的填坑方案。这些不是教科书理论是焊台旁、示波器上、产线流水线上用时间和金钱换来的教训。6.1 坑1J-Link连接失败提示“Target not found”现象Bootloader烧录后J-Link无法连接芯片ST-Link报错“SWD connect fail”。根因Bootloader中误配置了SWDIO引脚为GPIO输出模式且拉低了SWDIO线导致调试接口被硬件锁定。填坑方案在Bootloader初始化GPIO前强制释放SWD引脚// 在RCC时钟使能后GPIO初始化前插入 RCC-APB2ENR | RCC_APB2ENR_AFIOEN; // 使能AFIO时钟 AFIO-MAPR ~AFIO_MAPR_SWJ_CFG; // 清除SWJ配置位 AFIO-MAPR | 0x02; // 设置SWJ_CFG010仅保留SWD6.2 坑2OTA升级后APP能启动但ADC采样值全为0现象B区APP运行正常但所有模拟外设ADC/TIM无响应。根因APP的SystemInit()函数中调用了RCC_DeInit()该函数会复位所有时钟配置但Bootloader已配置的HSI/PLL未被重新启用。填坑方案在APP的main()函数开头强制重置时钟树// APP main()第一行 RCC_DeInit(); RCC_HSEConfig(RCC_HSE_ON); while(RCC_GetFlagStatus(RCC_FLAG_HSERDY) RESET); RCC_PLLConfig(RCC_PLLSource_HSE_Div1, RCC_PLLMul_9); // 8MHz * 9 72MHz RCC_PLLCmd(ENABLE); while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY) RESET); RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);6.3 坑3串口升级时最后一包数据总是丢失现象Modbus RTU接收128字节数据但第128字节常被丢弃。根因USART的RXNE中断在接收最后一个字节时DMA尚未完成传输导致中断处理程序读取了旧数据。填坑方案使用USART的IDLE线检测替代RXNE中断// 使能IDLE中断 USART_ITConfig(USART1, USART_IT_IDLE, ENABLE); // 在IDLE中断中读取DR寄存器清空RXNE标志 void USART1_IRQHandler(void) { if(USART_GetITStatus(USART1, USART_IT_IDLE) ! RESET) { // 清空IDLE标志 USART_ReceiveData(USART1); // 此时DMA缓冲区已满可安全读取 process_uart_data(dma_buffer, dma_count); } }6.4 坑4HAL_Delay()在APP中卡死但SysTick_Handler能进入现象APP的HAL_Delay(100)永远不返回但打断点发现SysTick_Handler每1ms都执行。根因Bootloader跳转前未重置SysTick的VAL寄存器导致VAL为负值SysTick-CTRL的COUNTFLAG位永不置位。填坑方案在跳转前强制重置SysTick-CTRL 0; // 先关闭 SysTick-LOAD 0; // 清空重载值 SysTick-VAL 0; // 强制清空当前值6.5 坑5参数区写入后读取值随机变化现象*(uint16_t*)0x08014004有时读出0xAA55有时读出0x0000。根因Flash写入必须按半字16bit对齐但代码中直接写*(uint16_t*)addr value若addr未对齐会触发BusFault。填坑方案使用HAL_FLASH_Program()并确保地址对齐HAL_FLASH_Unlock(); FLASH_EraseSector(FLASH_Sector_31, VoltageRange_3); // 擦除参数区所在扇区 HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, 0x08014004, 0xAA55); HAL_FLASH_Lock();6.6 坑6B区升级完成后设备不断重启现象Bootloader写入active_flag后立即触发NVIC_SystemReset()但复位后又回到Bootloader形成死循环。根因NVIC_SystemReset()执行后芯片复位但Bootloader在检查参数区时发现update_status 0x01升级中于是再次尝试激活B区但B区尚未完成校验。填坑方案在写入active_flag后必须先写入update_status 0x00再触发复位write_param_update_status(0x00); // 先清除升级中标志 write_param_active_flag(PARTITION_B); // 再设置激活标志 NVIC_SystemReset(); // 最后复位6.7 坑7使用Keil编译时APP的.data段初始化失败现象APP启动后全局变量全为0而非链接脚本中定义的初始值。根因Keil的启动文件startup_stm32f10x_hd.s中__main函数会执行.data段复制但Bootloader跳转绕过了__main。填坑方案在APP的main()开头手动复制extern uint32_t _sidata, _sdata, _edata; uint32_t *p_src _sidata; uint32_t *p_dst _sdata; while(p_dst _edata) { *p_dst *p_src; }6.8 坑8CAN通信在APP中无法接收远程帧现象Bootloader中CAN正常APP中只能接收标准帧远程帧丢失。根因Bootloader初始化CAN时未配置CAN_FMR寄存器的FINIT位导致CAN模块处于初始化模式APP未重新配置。填坑方案在APP的CAN初始化中强制退出初始化模式CAN_DeInit(CAN1); CAN_StructInit(CAN_InitStructure); CAN_Init(CAN1, CAN_InitStructure); CAN_ForceExitInit(CAN1); // 关键退出初始化模式6.9 坑9OTA升级时设备功耗突增10mA现象升级过程中电流从8mA升至18mA导致电池供电设备提前关机。根因Bootloader中开启了所有GPIO端口时钟RCC-APB2ENR 0xFFFFFFFF但未配置对应GPIO为模拟输入导致悬空引脚产生漏电流。填坑方案在Bootloader初始化GPIO前将所有未用引脚设为模拟输入GPIO_InitTypeDef GPIO_InitStruct; RCC_APB2PeriphClockCmd(RCC_APB2PERIPH_GPIOA | RCC_APB2PERIPH_GPIOB | RCC_APB2PERIPH_GPIOC, ENABLE); GPIO_InitStruct.GPIO_Mode GPIO_Mode_AIN; GPIO_InitStruct.GPIO_Speed GPIO_Speed_50MHz; for(int i0; i16; i) { GPIO_InitStruct.GPIO_Pin 1 i; GPIO_Init(GPIOA, GPIO_InitStruct); GPIO_Init(GPIOB, GPIO_InitStruct); GPIO_Init(GPIOC, GPIO_InitStruct); }6.10 坑10使用STM32CubeMX生成的Bootloader跳转后HardFault现象CubeMX生成的代码中HAL_Init()调用后跳转立即HardFault。根因HAL_Init()中调用了HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_0