用HID玩转固件升级：不靠Bootloader的轻量级DFU实战
你有没有遇到过这样的场景？
一款基于STM32G0的小型IoT传感器节点，Flash只有64KB。为了支持远程维护，团队想加入固件升级功能。但传统的双Bank DFU方案光是Bootloader就占了12KB，几乎吃掉三分之一空间——这还怎么放业务逻辑？
更头疼的是，客户抱怨“每次升级要按住复位键再插USB”，操作门槛高、出错率大。而OTA又受限于无线稳定性，在工业现场频频失败。
面对资源紧张与用户体验的双重挑战，我们开始思考：能不能在不增加额外Bootloader的前提下，直接通过现有通信通道完成安全可靠的固件更新？
答案是：可以，而且还能用最“人畜无害”的方式实现——利用HID类设备。
为什么选HID？因为它天生适合“偷偷升级”
先说一个反常识的事实：HID不只是给键盘鼠标用的。
虽然它的全称是Human Interface Device，但USB协议从未限制它只能传按键码。只要主机和设备约定好数据格式，HID完全可以成为任意命令通道——包括刷写Flash。
更重要的是，HID具备几个让嵌入式开发者心动的特性：
- 免驱：Windows/Linux/macOS原生支持，插上即用。
- 免签名：不像自定义USB类需要INF文件或驱动签名，HID走的是白名单通道。
- 跨平台兼容性强：虚拟机、树莓派、甚至Android OTG都能识别。
- 中断传输机制：适合低延迟控制指令交互。
这意味着，哪怕你的设备主功能是温湿度上报，也可以悄悄内置一套“升级后门”——用户完全感知不到切换过程。
🔍 小知识：很多商业产品（如某些电竞外设）正是通过HID通道静默更新固件，无需进入特殊模式。
核心思路：把HID当“伪DFU”来用
传统DFU依赖专用的USB DFU类接口，设备必须重启进入Bootloader才能响应DNLOAD、UPLOAD等请求。这种方式结构清晰，但也带来了两个硬伤：
- 必须预留独立的Bootloader区（通常≥8KB）
- 用户需手动触发模式切换（如长按按键）
而我们的目标很明确：让应用程序自己处理升级流程，全程不下线。
怎么做？很简单——复用已有的HID端点，定义一组私有命令集，模拟完整的DFU操作流程。
你可以理解为：
“我本来是个键盘，但我听懂了一套暗语，一旦收到特定指令，我就暂时放下打字工作，开始烧录新程序。”
这套“暗语”就是我们自定义的HID DFU协议。
协议设计：小包传输也能搞定大文件
由于HID Report最大长度通常为64字节（全速USB），我们必须对固件进行分包处理。但这并不意味着效率低下——关键在于协议设计是否聪明。
数据包结构设计
我们采用紧凑的三段式结构：
+--------+--------+-----------------------------+ | CMD(1) | LEN(1) | PAYLOAD (up to 62 bytes) | +--------+--------+-----------------------------+CMD：命令类型（如0x04表示写入一页）LEN：后续有效数据长度PAYLOAD：参数或固件片段
例如，发送一页编程命令时，payload前4字节为地址，后面跟着实际数据：
// 示例：向0x08008000写入32字节数据 uint8_t report[64] = { 0x04, // CMD: Program Page 36, // LEN: 4(byte addr) + 32(data) 0x00, 0x80, 0x00, 0x08, // addr = 0x08008000 0xAA, 0xBB, ... // firmware data };主机将.bin文件按此格式拆解，逐包下发；设备接收后缓存到RAM，校验无误再写入Flash。
状态机驱动：让升级过程可控可回退
为了让整个流程有序进行，我们在设备端引入一个轻量级状态机：
typedef enum { APP_IDLE, // 正常运行 DFU_PREPARE, // 已认证，准备擦除 DFU_ERASING, // 正在擦除 DFU_PROGRAMMING, // 正在写入 DFU_VERIFYING, // 校验中 DFU_COMPLETE // 成功，等待重启 } dfu_state_t;每条命令的执行都受当前状态约束。比如只有在DFU_PREPARE及以上状态下才允许写Flash，防止误操作损坏代码。
更重要的是，这个状态保存在RAM中，断电即失——天然防滥用。
安全性不是儿戏：别让人随便刷你的芯片
开放升级接口等于打开了系统的“天窗”。如果不加防护，攻击者可能通过枚举命令注入恶意固件。
因此，我们在进入DFU模式前加入了双向认证机制：
case 0x02: // Enter DFU Mode if (authenticate_host(payload, payload_len)) { dfu_state = DFU_PREPARE; generate_session_token(); // 生成临时会话令牌 send_response(STATUS_OK); } else { send_response(STATUS_AUTH_FAIL); } break;authenticate_host()可以实现为简单的Challenge-Response流程：
- 主机请求进入DFU模式
- 设备返回一个随机数（Challenge）
- 主机使用预置密钥加密该数并回传（Response）
- 设备验证结果，匹配则放行
会话令牌（Token）存储在RAM中，后续所有敏感操作均需携带该Token，确保会话合法性。
💡 提示：密钥可烧录在Option Bytes或Secure Element中，避免明文暴露。
实战代码：从接收到写Flash
下面是简化版的HID回调处理函数，展示了核心逻辑流：
#define MAX_PAYLOAD_SIZE 62 uint8_t hid_rx_buffer[64]; dfu_state_t dfu_state = APP_IDLE; void USB_HID_Callback(uint8_t *data, uint32_t len) { if (len < 2) return; uint8_t cmd = data[0]; uint8_t plen = data[1]; uint8_t *payload = &data[2]; switch (cmd) { case 0x02: // Enter DFU Mode if (verify_challenge_response(payload, plen)) { dfu_state = DFU_PREPARE; send_status(STATUS_OK); } else { send_status(STATUS_AUTH_FAIL); } break; case 0x03: // Flash Erase if (dfu_state < DFU_PREPARE) break; uint32_t page_addr = *(uint32_t*)payload; if (flash_erase(page_addr) == OK) { send_status(STATUS_ERASE_DONE); } break; case 0x04: // Program Page if (dfu_state < DFU_PREPARE) break; uint32_t addr = *(uint32_t*)payload; uint8_t *fw_data = payload + 4; uint32_t size = plen - 4; if (flash_program(addr, fw_data, size)) { dfu_state = DFU_PROGRAMMING; send_status(STATUS_PROGRAM_OK); } else { send_status(STATUS_PROGRAM_FAIL); } break; case 0x05: // Verify CRC if (dfu_state == DFU_PROGRAMMING) { uint32_t expected_crc = *(uint32_t*)payload; if (crc32(fw_start, fw_size) == expected_crc) { dfu_state = DFU_VERIFYING; send_status(STATUS_CRC_PASS); } else { send_status(STATUS_CRC_FAIL); } } break; case 0x06: // Reset system_reset(); break; default: send_status(STATUS_UNKNOWN_CMD); break; } }这段代码虽然简洁，但涵盖了权限控制、Flash操作、状态迁移和反馈机制四大要素，足以支撑一次完整升级。
如何提升效率？这些技巧你得知道
尽管HID单包只有62字节可用空间，但我们可以通过以下方式优化整体性能：
✅ 合并擦除与写入操作
不要每收到一包就立即写Flash。可以在RAM中累积多个页的数据，统一发起擦除和编程。减少Flash寿命损耗的同时也提升了吞吐。
✅ 使用Feature Report传输大块元数据
除了标准Input/Output Report，HID还支持Feature Report，可用于传输加密密钥、版本信息、差分补丁索引等非实时数据。
// 主机发送Feature Report设置升级参数 hid_send_feature_report(dev, config_report, 64);部分MCU（如nRF52系列）对Feature Report有良好支持，可作为配置通道独立使用。
✅ 开启端点最大包长64字节
确保在USB描述符中设置：
.bMaxPacketSize = 64,否则可能被系统限制为8或16字节，严重影响速度。
✅ 加入断点续传能力
在SRAM或保留页中记录已成功写入的最后一个地址。升级中断后，主机可查询进度并从中断处继续，而非重头再来。
实际应用场景：哪些设备最适合？
这套方案特别适合以下几类设备：
| 设备类型 | 应用优势 |
|---|---|
| 智能键盘/游戏手柄 | 本就是HID设备，天然适配；用户期望频繁更新键位配置或灯光效果 |
| TWS耳机充电盒 | 通过USB通信升级主控固件，无需额外串口 |
| 工业HMI面板 | 免驱接入PC即可升级界面固件，现场维护更便捷 |
| 可穿戴健康设备 | 小Flash容量常见，且需定期修复算法bug |
尤其在无法容纳双Bank Bootloader（<64KB Flash）或强调用户体验（拒绝复杂按键组合）的项目中，该方案几乎是唯一选择。
常见坑点与避坑指南
❌ 问题1：升级过程中USB断开，变砖？
对策：在写入前禁用全局中断，确保关键操作原子性；使用看门狗监控通信超时，异常时自动复位回应用模式。
❌ 问题2：主机发太快，设备来不及处理？
对策：采用“应答驱动”机制——每包数据发送后等待设备返回ACK，形成半双工流水线控制。
❌ 问题3：和其他HID功能冲突（如同时上报按键）？
对策：划分不同的Report ID，或在命令层区分功能域。例如：
- Report ID 1：标准按键上报
- Report ID 2：DFU命令通道
也可通过Usage Page隔离：
Usage Page (Vendor Defined 0xFF00)避免与操作系统默认行为冲突。
进阶方向：让它变得更智能
当前方案已能满足基本需求，但仍有很大扩展空间：
🔐 固件签名验证
在设备端集成轻量级ECDSA验签库（如micro-ecc），只接受合法签名的固件，彻底杜绝非法刷机。
📦 差分升级（Delta Update）
仅传输新旧版本之间的差异部分，大幅减少传输数据量。适用于网络带宽受限或频繁迭代的场景。
🔄 与BLE HID联动
对于支持蓝牙的设备（如nRF52），可设计双模HID DFU：
- 日常通过BLE HID进行无线升级
- 故障时插入USB，走有线HID恢复
真正实现“永不离线”的固件维护体系。
写在最后：这不是妥协，而是进化
有人可能会说：“这不是真正的DFU，只是个模拟方案。”
但我想反问：如果它能以1/5的资源消耗，实现90%的功能，并且用户体验更好，那它到底算不算成功？
在嵌入式世界里，从来都不是“标准至上”，而是“解决问题优先”。
基于HID的固件升级方案，本质上是一种资源精打细算的艺术。它教会我们如何在有限的空间里，用最少的代价构建最大的价值。
下次当你面对“Flash不够”、“用户不会操作”、“驱动装不上”这些问题时，不妨试试这条路——
也许，你只需要多定义一条命令，就能让设备拥有“自我进化”的能力。
如果你正在做类似项目，欢迎留言交流具体实现细节。我可以分享一份可用于STM32/Nordic平台的开源参考实现框架。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
