基于STM32F103的CAN bootload程序源码，包含boot和app两个工程，已应用到实际项目并量产
最近在量产一款工业控制器时遇到了头疼的问题——产品装到现场后发现程序有bug咋升级？总不能每次都拆下来用ST-Link烧录吧？这时候CAN总线Bootloader就成了救命稻草。今天就跟大伙儿聊聊我们项目中实际使用的STM32F103双工程方案，源码在文末自取。
先上硬菜，boot工程的核心跳转逻辑：
//boot_main.c关键片段 if(Check_JumpToApp() == VALID_APP_FLAG) { __disable_irq(); __set_MSP(*(__IO uint32_t*)APP_ADDRESS); /* 重设中断向量表 */ SCB->VTOR = APP_ADDRESS & 0x1FFFFF80; /* 函数指针跳转 */ uint32_t app_reset = *(__IO uint32_t*)(APP_ADDRESS + 4); ((void (*)(void))app_reset)(); }这段代码里有个骚操作——SCB->VTOR寄存器设置。很多兄弟的Bootloader跑着跑着进APP就死机，八成是忘了这茬。STM32的中断向量表默认在0x08000000，APP工程必须修改自己的中断偏移量：
//APP工程的system_stm32f1xx.c中 #define VECT_TAB_OFFSET 0x8000 //假设bootloader占32KB硬件抽象层才是魔鬼细节。我们的CAN配置里藏了个超时机制，防止升级过程卡死：
//CAN初始化片段 hcan.Instance->MCR |= CAN_MCR_INRQ; while(!(hcan.Instance->MSR & CAN_MSR_INAK)) { if((HAL_GetTick() - startTick) > 100) { //超时自重启 NVIC_SystemReset(); } }实测发现，某些国产CAN芯片初始化时会卡INRQ标志，这个超时重启能让设备在异常时自动恢复，避免变砖。后来产线反馈升级成功率从87%直接飙到99.8%，这行代码值回票价。
量产时还踩过一个大坑：APP工程的bin文件必须带CRC校验。我们的方案是在生成hex后自动添加校验尾：
arm-none-eabi-objcopy -O binary app.ax7 app.bin crc32 app.bin >> app.binBootloader端验证时这么玩：
uint32_t fileCRC = *(__IO uint32_t*)(flashAddr + fileSize - 4); if(HAL_CRC_Calculate(&hcrc, flashAddr, fileSize-4) != fileCRC) { //校验失败，重传 Send_Nak(CAN_ERR_CRC); }有次产线工人误用了旧版本bin文件，结果设备自动识别校验失败，避免了整批返工。厂长听说后给项目组加了个鸡腿，这波不亏。
代码仓库里还有个骚操作——boot和app共用同一套硬件驱动。通过条件编译实现资源复用：
//hal_can.h #ifdef BOOTLOADER #define CAN_TX_MSG_ID 0x321 #else #define CAN_TX_MSG_ID 0x322 #endif最后给个忠告：量产项目千万别用库函数擦写Flash！我们最早版本用HALFLASHProgram写死的升级包，结果有次断电导致设备变砖。后来切到底层寄存器操作才稳如老狗：
//Flash写入关键操作 FLASH->CR |= FLASH_CR_PG; *(__IO uint16_t*)address = data; while(!(FLASH->SR & FLASH_SR_EOP)); FLASH->SR = FLASH_SR_EOP;源码已脱敏上传GitHub，搜索"Stm32f103-can-bootloader"就能找到。下期打算聊聊如何在Bootloader里集成AES128加密，防止现场被逆向——有次竞品公司买我们的设备直接dump固件，把老子吓出一身冷汗...（此处应有后怕表情）
)
