避开这些坑！在NRF52832上实现DIS服务时，硬件版本和固件版本到底该怎么填？
NRF52832开发实战：DIS服务版本管理的三大黄金法则
当你用nRF Connect扫描设备时，是否曾被那一堆版本号搞得晕头转向？硬件版本、固件版本、软件版本——这三个看似简单的字符串，实际上藏着产品迭代的关键密码。作为NRF52832开发者，正确处理这些字段不仅关乎调试效率，更直接影响OTA升级的可靠性。本文将揭示版本管理的深层逻辑，让你避开80%开发者都会踩的坑。
1. 版本字段的本质区别与行业惯例
在DIS服务的九个特征值中，Hardware Revision、Firmware Revision和Software Revision最容易引发混淆。许多开发者习惯性地将它们统一设置为相同的版本号，这其实埋下了重大隐患。
1.1 硬件版本（Hardware Revision）
硬件版本对应的是PCB的迭代记录。想象这样一个场景：你的智能手环第一版使用了NRF52832-QFAA芯片，第二版为了降低成本换成了NRF52832-CIAA，这时就必须更新硬件版本号。行业常见的命名规范包括：
- 语义化版本：
主版本.次版本.修订号（如1.2.3）- 主版本：硬件架构重大变更（如更换MCU型号）
- 次版本：外围电路调整（如传感器接口变更）
- 修订号：PCB布线优化等微小改动
// 正确示例 - 基于硬件BOM的版本定义 #define HW_REVISION "2.1.0" // 第二代产品，第一次改版，初始版本提示：硬件版本应该与生产BOM单严格对应，每次PCBA改版都需要升级版本号
1.2 固件版本（Firmware Revision）
这里藏着最大的认知误区——固件版本特指蓝牙协议栈版本，而非应用程序版本。例如使用SoftDevice S132时的正确写法：
| SDK版本 | 对应SoftDevice | 推荐固件版本格式 |
|---|---|---|
| SDK 17.1 | S132 v7.2.0 | s132_7.2.0 |
| SDK 15.3 | S132 v6.1.1 | s132_6.1.1 |
// 典型错误 - 将应用程序版本误用作固件版本 #define FW_REVISION "1.0.0" // 错误！这应该是软件版本 // 正确写法 - 明确标识协议栈 #define FW_REVISION "s132_nrf52_7.2.0"1.3 软件版本（Software Revision）
这才是你的应用程序版本号，也是OTA升级时真正需要比较的字段。建议采用以下结构：
[产品线代码]-[主版本].[功能版本].[热修复版本]+[构建类型]例如：
FIT-3.2.1+release：健身产品线正式发布的3.2.1版本MED-1.0.0+debug：医疗产品线调试中的1.0.0版本
2. 版本管理的工程实践
2.1 自动化版本注入
手动维护版本号极易出错。推荐在构建系统中集成自动生成机制：
# Makefile示例 - 自动生成版本信息 GIT_HASH := $(shell git rev-parse --short HEAD) BUILD_DATE := $(shell date +%Y%m%d) CFLAGS += -DSW_REVISION=\"$(PRODUCT_LINE)-$(VERSION)+$(BUILD_TYPE)\" CFLAGS += -DBUILD_INFO=\"$(BUILD_DATE)_$(GIT_HASH)\"2.2 版本号与OTA升级的关联
当设备收到OTA包时，应该按照以下逻辑校验：
- 比较硬件版本：必须完全匹配
- 检查固件版本：新包协议栈需兼容当前版本
- 验证软件版本：新包版本号必须高于当前版本
# OTA版本校验伪代码 def validate_ota(hw_current, fw_current, sw_current, hw_new, fw_new, sw_new): if hw_current != hw_new: raise Exception("硬件版本不匹配") if not is_compatible(fw_current, fw_new): raise Warning("协议栈可能需要更新") if version_parse(sw_current) >= version_parse(sw_new): raise Exception("软件版本需更高")2.3 生产环节的版本追溯
在量产阶段，建议将版本信息写入芯片的UICR区域：
// 将版本信息固化到Flash nrf_nvmc_write_bytes(UICR_CUSTOM_OFFSET, (const uint8_t*)HW_REVISION, strlen(HW_REVISION)); nrf_nvmc_write_bytes(UICR_CUSTOM_OFFSET+32, (const uint8_t*)FW_REVISION, strlen(FW_REVISION));这样即使应用程序损坏，仍能通过bootloader读取基础版本信息。
3. 调试技巧与常见问题排查
3.1 使用nRF Connect进行验证
连接设备后，重点检查三个关键点：
- 特征值权限：确保所有版本特征为"Read"且不需要认证
- 字符串编码：确认显示内容无乱码（UTF-8编码）
- 值长度：不超过DIS服务规定的最大长度（通常20字节）
3.2 典型错误案例分析
案例一：OTA后设备无法启动
现象：升级后设备不断重启
原因：硬件版本未更新（新旧版硬件不兼容）
解决方案：在dis_init中严格校验硬件版本
// 硬件版本校验示例 if(strcmp(hw_revision, EXPECTED_HW_REV) != 0) { NRF_LOG_ERROR("硬件版本不匹配"); NVIC_SystemReset(); }案例二：苹果设备无法识别服务
现象：iOS设备找不到DIS服务
原因：特征值未按苹果要求排序
修复方案：调整特征值顺序为Manufacturer → Model → Serial → HW Rev → FW Rev → SW Rev
4. 进阶：版本管理的扩展应用
4.1 多组件版本管理
对于复杂系统（如主控+传感器模块），可采用复合版本格式：
主控版本@传感器版本@通信协议版本示例：2.1.0@1.3.2@ble4.2
4.2 版本信息的安全扩展
在需要防伪的场景，可以在版本字符串中加入加密校验：
// 带签名的版本信息生成 char* gen_secure_version(const char* raw_ver) { uint8_t sig[16]; nrf_crypto_hash_compute(NRF_CRYPTO_HASH_ALG_SHA256, raw_ver, strlen(raw_ver), sig, sizeof(sig)); static char buf[64]; snprintf(buf, sizeof(buf), "%s|%02x%02x...", raw_ver, sig[0], sig[1]); return buf; }4.3 版本信息的动态更新
某些情况下需要运行时更新版本信息（如FPGA动态重配置），可通过以下方式实现：
// 动态更新DIS特征值 void update_dis_version(ble_dis_init_t* dis_init, const char* new_ver) { ble_gatts_value_t gatts_val = { .len = strlen(new_ver), .offset = 0, .p_value = (uint8_t*)new_ver }; sd_ble_gatts_value_set(dis_init->service_handle, dis_init->char_handles.sw_rev_handle, &gatts_val); }在最近的一个智能家居项目中，我们因为硬件版本管理不当导致3000台设备需要返厂重刷。这个惨痛教训让我深刻理解到：版本号不是简单的字符串，而是产品生命周期的DNA序列。现在我们的硬件版本管理精确到PCB的每一次微调，甚至为不同批次的电阻电容变化建立版本分支。