简介这份资源面向嵌入式开发工程师与STM32学习者聚焦通过HTTP协议实现设备固件远程升级这一实用场景帮助读者理解如何在无物理接触条件下完成固件更新提升设备可维护性。压缩包共202个文件约5.23MB以C源码与头文件为核心包含36个.c、38个.h文件另有编译产物.o、.d、.crf及Keil工程文件.uvproj、.uvopt并附带.hex、.map、.axf等烧录与调试文件以及少量备份与说明文档整体构成一个可编译验证的完整工程。资源围绕HTTP GET请求获取服务器固件、数据分块接收、完整性校验与闪存写入等关键环节展开涉及lwIP等网络库适配、请求头设置及安全模式处理适合具备一定TCP/IP与STM32网络编程基础的开发者参考。目前已有5087人学习下载可作为远程升级功能落地的实践蓝本。1. 从一次翻车现场说起为什么HTTP远程升级值得认真做去年帮一个做工业采集终端的朋友排查问题现场十几台设备分布在不同的机柜里固件有个小bug需要更新。当时他们的方案是派人带着笔记本和USB线一台一台刷结果折腾了整整两天还刷坏了两台。这件事之后我一直在想如果设备本身能通过HTTP从服务器拉取固件包自己完成升级这类问题根本不会发生。基于STM32的HTTP远程升级方案解决的就是这个场景设备通过GET请求从指定URL下载固件写入Flash校验后跳转运行。它适合做物联网终端、工业网关、智能硬件的同学也适合正在找嵌入式毕设或课设题目的同学——这个题目麻雀虽小但Bootloader、Flash操作、HTTP协议、固件校验这几个核心点全都能覆盖到。2. 需求分析与技术选型为什么是HTTP而不是其他方案2.1 远程升级的核心需求拆解先把需求理清楚不然后面选型全是拍脑袋。一个能用的远程升级方案至少要满足这几个条件固件来源可配置。服务器地址和固件路径不能写死在代码里否则换一个部署环境就得重新编译。通常的做法是把URL存在Flash的某个固定区域或者通过串口指令下发后保存。断点续传能力。设备可能部署在网络不稳定的环境里下载到一半断了不能从头再来。HTTP的Range头可以支持这个能力但STM32端要配合记录已下载偏移量。固件完整性校验。下载过程中任何一个字节出错刷进去就是砖。常见做法是CRC32校验或者MD5比对在Bootloader跳转前完成验证。升级失败可回滚。新固件启动失败时要能退回旧固件。这需要在Flash里保留两个固件区A/B分区或者至少保留一份备份。升级过程不掉电保护。写入Flash的过程中如果断电下次上电要能识别出升级未完成并重新进入下载流程。这五点里前三点是功能需求后两点是可靠性需求。很多同学做毕设只做了前三点答辩时被问到“升级到一半断电怎么办”就卡住了。2.2 HTTP GET方案与其他升级方式的对比嵌入式远程升级常见的有几种路子串口IAP、SD卡升级、HTTP/HTTPS升级、MQTT推送固件分片。这里重点说为什么选HTTP GET。串口IAP适合产线烧录不适合现场部署的设备因为你需要物理接触。SD卡升级需要人工插卡同样有现场操作成本。MQTT推送固件分片的方式对服务器和客户端都有较高要求实现复杂度大。HTTP GET的优势在于服务器端只需要一个静态文件服务Nginx、Apache甚至Python的http.server都行设备端用LwIP协议栈或者外接WiFi/4G模块就能发起请求整个链路简单可靠。STM32上跑HTTP通常有两种做法。一种是移植LwIP协议栈自己实现TCP连接和HTTP报文解析另一种是外接ESP8266/ESP32这类WiFi模块用AT指令让模块完成HTTP请求STM32只负责接收数据写Flash。前者对网络编程能力要求高但可控性强后者开发快但依赖模块固件版本AT指令的兼容性是个坑。我一般会建议如果毕设时间充裕、想体现网络协议栈的理解走LwIP方案如果重点是Bootloader和Flash管理走外接模块方案更稳。2.3 Flash分区规划与Bootloader设计Flash分区是整个方案的地基。以STM32F103C8T664KB Flash为例分区方案如下区域起始地址大小用途Bootloader0x0800000016KB启动判断、HTTP下载、Flash写入参数区0x080040002KB存储URL、固件长度、CRC值、升级标志App区0x0800480040KB用户应用程序备份区0x0800E8006KB旧固件备份可选Bootloader的启动逻辑是这样的上电后先读参数区的升级标志如果标志为“需要升级”则进入下载流程否则检查App区的固件有效性栈顶地址是否合法、CRC是否通过有效则跳转无效则停留在Bootloader等待升级。// Bootloader跳转前检查App有效性的核心逻辑 #define APP_ADDR 0x08004800 #define APP_VALID 0x5A5A5A5A typedef void (*pFunction)(void); void jump_to_app(void) { uint32_t app_stack *(volatile uint32_t*)APP_ADDR; uint32_t app_entry *(volatile uint32_t*)(APP_ADDR 4); uint32_t valid_flag *(volatile uint32_t*)(PARAM_ADDR FLAG_OFFSET); // 栈顶地址必须在SRAM范围内否则固件无效 if ((app_stack 0x2FFE0000) ! 0x20000000) { return; // 不跳转留在Bootloader } if (valid_flag ! APP_VALID) { return; } pFunction jump (pFunction)app_entry; __set_MSP(app_stack); // 重设主栈指针 jump(); // 跳转到App }这段代码里有两个关键点。第一app_stack的检查是判断固件是否有效的第一道门槛如果Flash里是空的0xFFFFFFFF栈顶地址肯定不在SRAM范围直接拦住。第二跳转前必须调用__set_MSP重设栈指针否则App的中断向量表偏移和栈空间都会出问题。很多同学跳转后程序跑飞八成是漏了这一步。参数区的读写需要先擦除再写入STM32F1的Flash擦除是按页1KB进行的。写参数前要解锁Flash写完再上锁这个流程不能省。3. HTTP下载与Flash写入的落地实现3.1 HTTP GET请求的构造与响应解析不管用LwIP还是AT指令HTTP GET请求的报文格式是一样的。一个典型的请求长这样GET /firmware/app_v2.bin HTTP/1.1\r\n Host: 192.168.1.100:8080\r\n User-Agent: STM32-IAP/1.0\r\n Range: bytes0-4095\r\n Connection: close\r\n \r\n这里有几个细节值得说。Range头用于断点续传第一次请求可以不带如果下载中断了下次带上已下载的字节范围。Connection: close告诉服务器响应完就关闭连接省得STM32端还要处理长连接的心跳。Host字段在HTTP/1.1里是必须的哪怕你直接用IP访问也得带上。响应报文的解析是容易翻车的地方。服务器返回的数据里前面是响应头后面才是固件二进制数据。你需要找到\r\n\r\n这个分隔符它后面的才是真正的固件内容。// 从HTTP响应中定位固件数据的起始位置 uint8_t* find_body_start(uint8_t* buf, uint32_t len) { for (uint32_t i 0; i len - 3; i) { if (buf[i] \r buf[i1] \n buf[i2] \r buf[i3] \n) { return buf[i4]; // 跳过空行指向body } } return NULL; // 没找到分隔符响应不完整 }这个函数看起来简单但实际项目中要考虑跨包的情况——响应头可能分布在两个TCP包里。稳妥的做法是维护一个状态机先收头、再收体而不是假设一次recv就能拿到完整响应。另外服务器返回的状态码也要检查。200表示完整返回206表示部分内容断点续传时404表示文件不存在500表示服务器内部错误。如果状态码不是200或206直接放弃本次升级并记录错误码。3.2 Flash擦除与写入的时序控制STM32F1的Flash操作有几个硬性约束擦除最小单位是页1KB写入必须是半字16位对齐擦除和写入期间CPU从Flash取指会暂停。这意味着你在写Flash的时候代码不能跑在同一个Flash块里否则程序就卡死了。通常的做法是把Flash操作函数放到RAM里执行或者确保写Flash期间不执行Flash中的代码。对于Bootloader来说因为Bootloader本身就在Flash里写App区的时候CPU会暂停取指但STM32的Flash控制器会自动插入等待周期只要不跨页操作一般不会出问题。不过为了保险我一般会在擦除和写入的关键步骤前后加看门狗喂狗防止操作时间过长导致复位。// Flash写入的核心流程解锁 - 擦除 - 写入 - 上锁 uint8_t flash_write(uint32_t addr, uint8_t* data, uint32_t len) { HAL_FLASH_Unlock(); // 先擦除目标页按1KB对齐 FLASH_EraseInitTypeDef erase; erase.TypeErase FLASH_TYPEERASE_PAGES; erase.PageAddress addr 0xFFFFF800; // 1KB对齐 erase.NbPages (len 1023) / 1024; uint32_t page_err 0; if (HAL_FLASHEx_Erase(erase, page_err) ! HAL_OK) { HAL_FLASH_Lock(); return 1; // 擦除失败 } // 半字写入 for (uint32_t i 0; i len; i 2) { uint16_t half data[i] | (data[i1] 8); if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, addr i, half) ! HAL_OK) { HAL_FLASH_Lock(); return 2; // 写入失败 } } HAL_FLASH_Lock(); return 0; }这段代码里addr 0xFFFFF800是1KB对齐操作因为STM32F1的页大小是1KB。NbPages根据数据长度算出需要擦除几页。写入时按半字组装注意小端序低字节在前高字节在后。写入速度方面STM32F1的Flash编程时间大约是每半字50微秒写40KB大概需要1.3秒左右。这个时间不算长但如果看门狗超时设得太短比如1秒就可能被复位。我一般会把看门狗超时设到3秒以上或者在写入循环里定期喂狗。3.3 固件校验与跳转前的最后一道防线固件下载完、写入Flash之后不能直接跳转。必须先做校验确认数据完整无误。常用的校验方式是CRC32在服务器端计算好固件的CRC值放在HTTP响应头里比如自定义一个X-Firmware-CRC头设备端下载完后重新计算CRC并比对。// CRC32校验多项式0xEDB88320与常见工具兼容 uint32_t crc32_calc(uint8_t* data, uint32_t len) { uint32_t crc 0xFFFFFFFF; for (uint32_t i 0; i len; i) { crc ^ data[i]; for (int j 0; j 8; j) { crc (crc 1) ^ (0xEDB88320 -(crc 1)); } } return ~crc; }校验通过后还要做一次“试跳转”把栈顶地址和入口地址读出来确认栈顶在SRAM范围内、入口地址在App区范围内然后再写升级标志、执行跳转。如果校验失败清除升级标志保留旧固件继续运行同时可以通过串口或日志记录失败原因。这里有个血泪经验不要在Bootloader里直接擦除旧固件。正确的顺序是先把新固件写到备份区或App区校验通过后再更新升级标志下次启动时才切换到新固件。这样即使新固件有问题旧固件还在设备不会变砖。4. 避坑与常见问题排查4.1 下载数据不完整或乱码现象固件写入后校验失败读出来的数据和服务器上的文件对不上。原因最常见的是TCP分包处理不当。HTTP响应可能分成多个TCP包到达如果代码假设一次recv就能拿到完整body后面的数据就丢了。另一个原因是Content-Length没解析对导致多收或少收数据。解决维护一个接收状态机先解析响应头拿到Content-Length然后循环recv直到收满指定字节数。每次recv后检查返回值如果是负数要判断是超时还是连接断开。收满后还要多收一次确认没有多余数据有些服务器会多发。4.2 跳转后程序跑飞或进HardFault现象Bootloader里一切正常跳转到App后直接死机或进HardFault。原因三个可能。一是跳转前没关中断App的中断向量表还没重映射中断一来就跑到Bootloader的向量表里去了。二是栈指针没重设App用的是Bootloader的栈空间一压栈就溢出。三是App的链接脚本没改编译出来的固件起始地址还是0x08000000和Bootloader重叠了。解决跳转前用__disable_irq()关总中断跳转后在App的main()开头重新开中断。App的链接脚本里ROM起始地址改成0x08004800并在system_stm32f1xx.c里设置VECT_TAB_OFFSET为0x4800。这三步缺一不可。4.3 Flash写入失败或数据错位现象HAL_FLASH_Program返回错误或者写进去的数据地址偏移不对。原因Flash没解锁就写、写入地址没按半字对齐、擦除页计算错误导致跨页写入、写入过程中被中断打断。解决写之前确认HAL_FLASH_Unlock()被调用且返回成功。地址必须2字节对齐数据长度必须是偶数。擦除时按1KB对齐计算页数和起始页。写入期间关中断防止中断服务程序里的Flash操作冲突。如果用的是HAL库注意HAL_FLASH_Program的第三个参数是半字数据不是字节指针。4.4 HTTP连接超时或服务器无响应现象设备发起HTTP请求后一直卡在连接阶段或者收到404/500错误。原因网络配置不对IP、网关、DNS、服务器防火墙拦截、URL路径写错、服务器没启动。解决先用PC上的curl或浏览器访问同一个URL确认服务器端没问题。然后在设备端加日志打印DNS解析结果、TCP连接状态、HTTP状态码。如果是用AT指令连WiFi模块检查模块是否已经获取到IP、是否成功连接到AP。超时时间建议设10秒以上给网络留足余量。4.5 升级过程中断电导致设备变砖现象升级到一半断电重新上电后设备不启动串口无输出。原因升级标志在固件写入前就被置位了断电后Bootloader认为需要升级但固件不完整又跳不回旧固件。解决升级标志的写入时机必须在固件完整写入并校验通过之后。Bootloader启动时先检查App区固件的有效性栈顶地址CRC无效则清除升级标志并停留在Bootloader等待重新下载。如果Flash空间够保留一份旧固件在备份区新固件启动失败时自动回滚。5. 验收与答辩怎么证明这套方案真的能跑验收不是看代码写了多少行而是看几个关键场景能不能过。我一般会按下面这个清单逐项测测试项操作预期结果正常升级服务器放新固件设备发起GET请求下载完成、校验通过、跳转后新功能生效断点续传下载到50%时断开网络恢复后重新请求从断点继续下载最终固件完整固件校验失败服务器放一个被篡改的固件校验不通过不跳转旧固件继续运行升级中断电写入Flash过程中拔电重新上电Bootloader检测到升级未完成等待重新下载服务器不可达关闭服务器设备发起升级超时后报错不影响旧固件运行重复升级同一固件连续升级两次第二次检测到版本相同跳过下载答辩时老师最常问的几个问题提前准备好答案Bootloader和App的地址怎么分配的中断向量表怎么重映射的CRC校验的多项式是什么断点续传的偏移量存在哪里升级失败怎么回滚这些问题答得上来基本就稳了。还有一个技巧答辩现场演示的时候不要只演示成功路径。故意制造一次下载中断然后展示设备如何恢复这比顺利跑完一遍更有说服力。老师看到你对异常流程有处理印象分直接拉满。从那以后我每次做升级相关的项目都会强制走一遍“断电测试”——在Flash写入的循环里随机拔电重复十次看设备能不能每次都恢复。这个习惯帮我拦住了至少三次潜在的变砖风险。希望这套方案和验收思路能帮到你少走一些我当年走过的弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/19 9:02:20 · 阅读 1.2k 基于STM32的HTTP远程升级方案：Bootloader、Flash操作与固件校验实战
简介这份资源面向嵌入式开发工程师与STM32学习者聚焦通过HTTP协议实现设备固件远程升级这一实用场景帮助读者理解如何在无物理接触条件下完成固件更新提升设备可维护性。压缩包共202个文件约5.23MB以C源码与头文件为核心包含36个.c、38个.h文件另有编译产物.o、.d、.crf及Keil工程文件.uvproj、.uvopt并附带.hex、.map、.axf等烧录与调试文件以及少量备份与说明文档整体构成一个可编译验证的完整工程。资源围绕HTTP GET请求获取服务器固件、数据分块接收、完整性校验与闪存写入等关键环节展开涉及lwIP等网络库适配、请求头设置及安全模式处理适合具备一定TCP/IP与STM32网络编程基础的开发者参考。目前已有5087人学习下载可作为远程升级功能落地的实践蓝本。1. 从一次翻车现场说起为什么HTTP远程升级值得认真做去年帮一个做工业采集终端的朋友排查问题现场十几台设备分布在不同的机柜里固件有个小bug需要更新。当时他们的方案是派人带着笔记本和USB线一台一台刷结果折腾了整整两天还刷坏了两台。这件事之后我一直在想如果设备本身能通过HTTP从服务器拉取固件包自己完成升级这类问题根本不会发生。基于STM32的HTTP远程升级方案解决的就是这个场景设备通过GET请求从指定URL下载固件写入Flash校验后跳转运行。它适合做物联网终端、工业网关、智能硬件的同学也适合正在找嵌入式毕设或课设题目的同学——这个题目麻雀虽小但Bootloader、Flash操作、HTTP协议、固件校验这几个核心点全都能覆盖到。2. 需求分析与技术选型为什么是HTTP而不是其他方案2.1 远程升级的核心需求拆解先把需求理清楚不然后面选型全是拍脑袋。一个能用的远程升级方案至少要满足这几个条件固件来源可配置。服务器地址和固件路径不能写死在代码里否则换一个部署环境就得重新编译。通常的做法是把URL存在Flash的某个固定区域或者通过串口指令下发后保存。断点续传能力。设备可能部署在网络不稳定的环境里下载到一半断了不能从头再来。HTTP的Range头可以支持这个能力但STM32端要配合记录已下载偏移量。固件完整性校验。下载过程中任何一个字节出错刷进去就是砖。常见做法是CRC32校验或者MD5比对在Bootloader跳转前完成验证。升级失败可回滚。新固件启动失败时要能退回旧固件。这需要在Flash里保留两个固件区A/B分区或者至少保留一份备份。升级过程不掉电保护。写入Flash的过程中如果断电下次上电要能识别出升级未完成并重新进入下载流程。这五点里前三点是功能需求后两点是可靠性需求。很多同学做毕设只做了前三点答辩时被问到“升级到一半断电怎么办”就卡住了。2.2 HTTP GET方案与其他升级方式的对比嵌入式远程升级常见的有几种路子串口IAP、SD卡升级、HTTP/HTTPS升级、MQTT推送固件分片。这里重点说为什么选HTTP GET。串口IAP适合产线烧录不适合现场部署的设备因为你需要物理接触。SD卡升级需要人工插卡同样有现场操作成本。MQTT推送固件分片的方式对服务器和客户端都有较高要求实现复杂度大。HTTP GET的优势在于服务器端只需要一个静态文件服务Nginx、Apache甚至Python的http.server都行设备端用LwIP协议栈或者外接WiFi/4G模块就能发起请求整个链路简单可靠。STM32上跑HTTP通常有两种做法。一种是移植LwIP协议栈自己实现TCP连接和HTTP报文解析另一种是外接ESP8266/ESP32这类WiFi模块用AT指令让模块完成HTTP请求STM32只负责接收数据写Flash。前者对网络编程能力要求高但可控性强后者开发快但依赖模块固件版本AT指令的兼容性是个坑。我一般会建议如果毕设时间充裕、想体现网络协议栈的理解走LwIP方案如果重点是Bootloader和Flash管理走外接模块方案更稳。2.3 Flash分区规划与Bootloader设计Flash分区是整个方案的地基。以STM32F103C8T664KB Flash为例分区方案如下区域起始地址大小用途Bootloader0x0800000016KB启动判断、HTTP下载、Flash写入参数区0x080040002KB存储URL、固件长度、CRC值、升级标志App区0x0800480040KB用户应用程序备份区0x0800E8006KB旧固件备份可选Bootloader的启动逻辑是这样的上电后先读参数区的升级标志如果标志为“需要升级”则进入下载流程否则检查App区的固件有效性栈顶地址是否合法、CRC是否通过有效则跳转无效则停留在Bootloader等待升级。// Bootloader跳转前检查App有效性的核心逻辑 #define APP_ADDR 0x08004800 #define APP_VALID 0x5A5A5A5A typedef void (*pFunction)(void); void jump_to_app(void) { uint32_t app_stack *(volatile uint32_t*)APP_ADDR; uint32_t app_entry *(volatile uint32_t*)(APP_ADDR 4); uint32_t valid_flag *(volatile uint32_t*)(PARAM_ADDR FLAG_OFFSET); // 栈顶地址必须在SRAM范围内否则固件无效 if ((app_stack 0x2FFE0000) ! 0x20000000) { return; // 不跳转留在Bootloader } if (valid_flag ! APP_VALID) { return; } pFunction jump (pFunction)app_entry; __set_MSP(app_stack); // 重设主栈指针 jump(); // 跳转到App }这段代码里有两个关键点。第一app_stack的检查是判断固件是否有效的第一道门槛如果Flash里是空的0xFFFFFFFF栈顶地址肯定不在SRAM范围直接拦住。第二跳转前必须调用__set_MSP重设栈指针否则App的中断向量表偏移和栈空间都会出问题。很多同学跳转后程序跑飞八成是漏了这一步。参数区的读写需要先擦除再写入STM32F1的Flash擦除是按页1KB进行的。写参数前要解锁Flash写完再上锁这个流程不能省。3. HTTP下载与Flash写入的落地实现3.1 HTTP GET请求的构造与响应解析不管用LwIP还是AT指令HTTP GET请求的报文格式是一样的。一个典型的请求长这样GET /firmware/app_v2.bin HTTP/1.1\r\n Host: 192.168.1.100:8080\r\n User-Agent: STM32-IAP/1.0\r\n Range: bytes0-4095\r\n Connection: close\r\n \r\n这里有几个细节值得说。Range头用于断点续传第一次请求可以不带如果下载中断了下次带上已下载的字节范围。Connection: close告诉服务器响应完就关闭连接省得STM32端还要处理长连接的心跳。Host字段在HTTP/1.1里是必须的哪怕你直接用IP访问也得带上。响应报文的解析是容易翻车的地方。服务器返回的数据里前面是响应头后面才是固件二进制数据。你需要找到\r\n\r\n这个分隔符它后面的才是真正的固件内容。// 从HTTP响应中定位固件数据的起始位置 uint8_t* find_body_start(uint8_t* buf, uint32_t len) { for (uint32_t i 0; i len - 3; i) { if (buf[i] \r buf[i1] \n buf[i2] \r buf[i3] \n) { return buf[i4]; // 跳过空行指向body } } return NULL; // 没找到分隔符响应不完整 }这个函数看起来简单但实际项目中要考虑跨包的情况——响应头可能分布在两个TCP包里。稳妥的做法是维护一个状态机先收头、再收体而不是假设一次recv就能拿到完整响应。另外服务器返回的状态码也要检查。200表示完整返回206表示部分内容断点续传时404表示文件不存在500表示服务器内部错误。如果状态码不是200或206直接放弃本次升级并记录错误码。3.2 Flash擦除与写入的时序控制STM32F1的Flash操作有几个硬性约束擦除最小单位是页1KB写入必须是半字16位对齐擦除和写入期间CPU从Flash取指会暂停。这意味着你在写Flash的时候代码不能跑在同一个Flash块里否则程序就卡死了。通常的做法是把Flash操作函数放到RAM里执行或者确保写Flash期间不执行Flash中的代码。对于Bootloader来说因为Bootloader本身就在Flash里写App区的时候CPU会暂停取指但STM32的Flash控制器会自动插入等待周期只要不跨页操作一般不会出问题。不过为了保险我一般会在擦除和写入的关键步骤前后加看门狗喂狗防止操作时间过长导致复位。// Flash写入的核心流程解锁 - 擦除 - 写入 - 上锁 uint8_t flash_write(uint32_t addr, uint8_t* data, uint32_t len) { HAL_FLASH_Unlock(); // 先擦除目标页按1KB对齐 FLASH_EraseInitTypeDef erase; erase.TypeErase FLASH_TYPEERASE_PAGES; erase.PageAddress addr 0xFFFFF800; // 1KB对齐 erase.NbPages (len 1023) / 1024; uint32_t page_err 0; if (HAL_FLASHEx_Erase(erase, page_err) ! HAL_OK) { HAL_FLASH_Lock(); return 1; // 擦除失败 } // 半字写入 for (uint32_t i 0; i len; i 2) { uint16_t half data[i] | (data[i1] 8); if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, addr i, half) ! HAL_OK) { HAL_FLASH_Lock(); return 2; // 写入失败 } } HAL_FLASH_Lock(); return 0; }这段代码里addr 0xFFFFF800是1KB对齐操作因为STM32F1的页大小是1KB。NbPages根据数据长度算出需要擦除几页。写入时按半字组装注意小端序低字节在前高字节在后。写入速度方面STM32F1的Flash编程时间大约是每半字50微秒写40KB大概需要1.3秒左右。这个时间不算长但如果看门狗超时设得太短比如1秒就可能被复位。我一般会把看门狗超时设到3秒以上或者在写入循环里定期喂狗。3.3 固件校验与跳转前的最后一道防线固件下载完、写入Flash之后不能直接跳转。必须先做校验确认数据完整无误。常用的校验方式是CRC32在服务器端计算好固件的CRC值放在HTTP响应头里比如自定义一个X-Firmware-CRC头设备端下载完后重新计算CRC并比对。// CRC32校验多项式0xEDB88320与常见工具兼容 uint32_t crc32_calc(uint8_t* data, uint32_t len) { uint32_t crc 0xFFFFFFFF; for (uint32_t i 0; i len; i) { crc ^ data[i]; for (int j 0; j 8; j) { crc (crc 1) ^ (0xEDB88320 -(crc 1)); } } return ~crc; }校验通过后还要做一次“试跳转”把栈顶地址和入口地址读出来确认栈顶在SRAM范围内、入口地址在App区范围内然后再写升级标志、执行跳转。如果校验失败清除升级标志保留旧固件继续运行同时可以通过串口或日志记录失败原因。这里有个血泪经验不要在Bootloader里直接擦除旧固件。正确的顺序是先把新固件写到备份区或App区校验通过后再更新升级标志下次启动时才切换到新固件。这样即使新固件有问题旧固件还在设备不会变砖。4. 避坑与常见问题排查4.1 下载数据不完整或乱码现象固件写入后校验失败读出来的数据和服务器上的文件对不上。原因最常见的是TCP分包处理不当。HTTP响应可能分成多个TCP包到达如果代码假设一次recv就能拿到完整body后面的数据就丢了。另一个原因是Content-Length没解析对导致多收或少收数据。解决维护一个接收状态机先解析响应头拿到Content-Length然后循环recv直到收满指定字节数。每次recv后检查返回值如果是负数要判断是超时还是连接断开。收满后还要多收一次确认没有多余数据有些服务器会多发。4.2 跳转后程序跑飞或进HardFault现象Bootloader里一切正常跳转到App后直接死机或进HardFault。原因三个可能。一是跳转前没关中断App的中断向量表还没重映射中断一来就跑到Bootloader的向量表里去了。二是栈指针没重设App用的是Bootloader的栈空间一压栈就溢出。三是App的链接脚本没改编译出来的固件起始地址还是0x08000000和Bootloader重叠了。解决跳转前用__disable_irq()关总中断跳转后在App的main()开头重新开中断。App的链接脚本里ROM起始地址改成0x08004800并在system_stm32f1xx.c里设置VECT_TAB_OFFSET为0x4800。这三步缺一不可。4.3 Flash写入失败或数据错位现象HAL_FLASH_Program返回错误或者写进去的数据地址偏移不对。原因Flash没解锁就写、写入地址没按半字对齐、擦除页计算错误导致跨页写入、写入过程中被中断打断。解决写之前确认HAL_FLASH_Unlock()被调用且返回成功。地址必须2字节对齐数据长度必须是偶数。擦除时按1KB对齐计算页数和起始页。写入期间关中断防止中断服务程序里的Flash操作冲突。如果用的是HAL库注意HAL_FLASH_Program的第三个参数是半字数据不是字节指针。4.4 HTTP连接超时或服务器无响应现象设备发起HTTP请求后一直卡在连接阶段或者收到404/500错误。原因网络配置不对IP、网关、DNS、服务器防火墙拦截、URL路径写错、服务器没启动。解决先用PC上的curl或浏览器访问同一个URL确认服务器端没问题。然后在设备端加日志打印DNS解析结果、TCP连接状态、HTTP状态码。如果是用AT指令连WiFi模块检查模块是否已经获取到IP、是否成功连接到AP。超时时间建议设10秒以上给网络留足余量。4.5 升级过程中断电导致设备变砖现象升级到一半断电重新上电后设备不启动串口无输出。原因升级标志在固件写入前就被置位了断电后Bootloader认为需要升级但固件不完整又跳不回旧固件。解决升级标志的写入时机必须在固件完整写入并校验通过之后。Bootloader启动时先检查App区固件的有效性栈顶地址CRC无效则清除升级标志并停留在Bootloader等待重新下载。如果Flash空间够保留一份旧固件在备份区新固件启动失败时自动回滚。5. 验收与答辩怎么证明这套方案真的能跑验收不是看代码写了多少行而是看几个关键场景能不能过。我一般会按下面这个清单逐项测测试项操作预期结果正常升级服务器放新固件设备发起GET请求下载完成、校验通过、跳转后新功能生效断点续传下载到50%时断开网络恢复后重新请求从断点继续下载最终固件完整固件校验失败服务器放一个被篡改的固件校验不通过不跳转旧固件继续运行升级中断电写入Flash过程中拔电重新上电Bootloader检测到升级未完成等待重新下载服务器不可达关闭服务器设备发起升级超时后报错不影响旧固件运行重复升级同一固件连续升级两次第二次检测到版本相同跳过下载答辩时老师最常问的几个问题提前准备好答案Bootloader和App的地址怎么分配的中断向量表怎么重映射的CRC校验的多项式是什么断点续传的偏移量存在哪里升级失败怎么回滚这些问题答得上来基本就稳了。还有一个技巧答辩现场演示的时候不要只演示成功路径。故意制造一次下载中断然后展示设备如何恢复这比顺利跑完一遍更有说服力。老师看到你对异常流程有处理印象分直接拉满。从那以后我每次做升级相关的项目都会强制走一遍“断电测试”——在Flash写入的循环里随机拔电重复十次看设备能不能每次都恢复。这个习惯帮我拦住了至少三次潜在的变砖风险。希望这套方案和验收思路能帮到你少走一些我当年走过的弯路。本文还有配套的精品资源点击获取