Nordic的nRF5x系列芯片固件升级(DFU)手机APP开发攻略

    最近公司业务需求给设备提供OTA升级, 其主要核心是根据设备的具体型号提供不同类型的DFU(Device Firmware Update). 由于碰到不少坑, 所以记录下来以备后期查阅和参考.
    固件升级的基本流程无非几个: 让设备切换到DFU模式->发送升级文件->激活升级文件并重启. 但是由于使用了不同的蓝牙芯片及其配备的SDK, 开发出来的板子也得提供不同的适配流程.
    值得庆幸的是, 同一家公司开发的某个系列的蓝牙芯片, 基本使用了相同的(或者向前兼容的)蓝牙发现/交互服务, 所以在某个阶段, 你只需要开发一套流程即可基本复用这套业务流程. 如果涉及到不同系列蓝牙芯片或者不同公司, 那么你需要使用设计模式来完善你的业务架构, 这点就不赘述了.
    目前业界比较常采用的是Nordic公司的nRF5x系列芯片, 其配套的SDK最新版本已经提供到11.x, 但我暂时提供的流程是基于5.x版本的SDK. 所以需要新流程的童鞋们只能暂时找Google协助了.
    该设备的蓝牙服务搜索ID:"00001530-1212-EFDE-1523-785FEABCD123";

    控制点(发送和接收指令)特征ID:"00001531-1212-EFDE-1523-785FEABCD123";

    数据包(发送升级文件包等)特征ID:"00001532-1212-EFDE-1523-785FEABCD123";

    版本(读取该设备的固件版本号)特征ID:"00001534-1212-EFDE-1523-785FEABCD123".

固件升级流程图如下:

DFU固件升级时序图

其中, 需要说明的几个坑:

1. 固件切换到DFU模式前, 如果已经进行了ANCS配对绑定, 那么连接必然失败, 需要手动到蓝牙设置界面将绑定关系取消. 暂时还没有更好的办法, 希望有知道的童鞋提供一下解决思路.

2. 固件反馈使用了周边设备的delegate进行回调. 如果你的蓝牙框架已经接管了这些delegate, 那么意味着你在应用层拿不到这些通知. 目前我使用的是Notification的方式进行数据反馈.

3. 切换到DFU模式前需要"使能"(即Make it usable)控制点通道的通知, 而每次发送启动DFU的指令前(包括旧式的DFU)都需要"使能"该控制点通道的通知, 否则你会发现设备完全无反馈了. 据称设备的SDK在每次接收到启动DFU时, 都会切换一下, 重新执行main函数, 所以之前的状态无法保留.

4. 启动DFU命令是两条指令: 启动DFU指令和发送文件大小指令. 切记! 只发送一条指令你就会跟我一样抓瞎很久...

5. 重启系统指令基本不生效. 这是因为设备的flash有限. 所以大部分蓝牙设备开发商为了节约成本考虑, 基本不会实现这类功能. 所以你看看就好了, 如果非要提供更完善的体验, 就意味着你要在别人身上割肉了(奸商XD).

6. 升级过程中会因为设备电量不足/丢包等导致失败. 一般建议50%以上的电量才做升级. 而丢包导致失败的问题, 暂时无力吐槽, 协议定义得太糟糕了(都不知道能不能重发数据包 = =!).

7. 升级完成后, 蓝牙设备识别的名称还没更新, 需要重连一次后设备才会更新设备名称. 所以通过蓝牙名称过滤的童鞋要注意了, 这也是个不大不小的坑.