基于STM32WB的低功耗蓝牙应用（三）OTA空中升级

只看该作者 · 2021-4-22 12:37

自定义BLE service/char.用户bootloader需要实现一个自定义BLE service，来管理FOTA的流程，它由三个characteristic组成：第一个，base address，属性为写，由OTA上位机，即OTA client发过来的，被OTA server上运行的这个用户bootloader接收，写到我们自定义的这个BLE service的第一个characteristic；第二个，是升级文件image的具体内容，理所当然，它的属性也是写；第三个是一个indication属性的characteristic，它是在OTA bootloader完成了固件升级后，要复位重启设备端的一个通知，给到OTA上位机。通过这样一个自定义的BLE service，ota bootloader就可以实现来自上位机的新固件文件的接收，烧写、以及过程结束后的状态回复。

另外一方面，用户的业务应用，要在已有的BLE service中新增一个具有写属性的characteristic：“Reboot Request”，它包含三个信息：reboot的方式，要擦除的起始扇区编号、以及要擦除的扇区个数。这样一个支持reboot request/重启请求的能力，会在该设备和客户端AP，建立连接之前的广播阶段，表达出来。

只看该作者 · 2021-4-22 12:38

广播包自定义信息

广播报文包，在PDU字段，可以表达很多广播信息，根据不同的AD type，封装不同的AD 信息。比如常见的有设备发射功率，以0x0A为广播类型；完整设备名称，以0x09为广播类型；当广播类型为0xff时，后面可以封装厂商自定义设备信息。我们借此机会，在4字节的Feature mask字段，表达该设备实现了的属性。支持OTA reboot的能力，就是在这里有相应的位来表示。具体的厂商自定义规范，可以查阅文档《AN5247》，以及ST github上的STBlue这个协议。

只看该作者 · 2021-4-22 12:38

有了这样的广播信息，以及用户应用中新增了reboot request这个characteristic后，在常规的BLE应用，比如Heart rate profile之上，手机APP ST BLE Sensor可以识别出来该应用可以支持OTA，如图：Heart Rate 设备的footer，第二个图标“ota config”。如果nucleo板运行的是STM32CubeWB 固件包里的普通heart rate profile demo，手机端识别出来的心跳应用，footer是没有这个图标的。

只看该作者 · 2021-4-22 12:39

BLE通信流程

最后，我们来理一下整个BLE的通信流程。被升级的Nucleo板子就是图中的 Server，Client是OTA上位机，可以是STM32CubeMonitor-RF，或者ST BLE Sensor这样的手机APP。Server侧，绿色的线段表示在运行ota bootloader，蓝色的线段表示在运行user application。

只看该作者 · 2021-4-22 12:40

设备上电，最先运行ota bootloader，如果没有ota请求标志置位，并且后面的扇区有应用程序代码，就跳转到user application执行。user application通常也是一个BLE应用，在广播的时候，它通过厂商自定义信息字段，告诉OTA 上位机它支持ota reboot请求。这样上位机，比如STM32CubeMonitor-RF才可以scan来找到符合要求的BLE设备。上位机发起OTA请求，往设备写入reboot相关信息，reboot模式、要擦除的扇区；user applicatioin收到后，在SRAM的起始地址打上标记，然后设备重启。起来之后，运行ota bootloader，即绿色的线条。根据SRAM上留下的印记，先擦除对应扇区，然后开始ota bootloader的 ble通信。

只看该作者 · 2021-4-22 12:41

只看该作者 · 2021-4-22 12:41

和上位机建立连接后，上位机获得wb设备service能力和相关character。然后就通过这个OTA service，来进行更新文件image起始地址、image内容的下发；并在文件更新完成后，由WB设备回传过程结束的信息，并在此复位设备。重启之后，SRAM中不再有ota请求，于是直接跳到应用程序部分开始执行。

只看该作者 · 2021-4-22 12:42

WB固件升级总结
近程升级FUS、RF Stack小结

只看该作者 · 2021-4-22 12:42

最后，我们总结一下本期WB固件升级的内容。

STM32WB有两个独立的内核，分别运行RF协议栈和用户的应用程序。我们要升级的目标文件是RF协议栈和用户应用程序，但是由于WB特有的安全特性，运行在M0+内核上的RF协议栈都是以被ST签名加密过的image形式提供给用户，因此需要一个额外的FUS来负责对RF协议栈的更新。由于FUS本身有和RF协议栈的版本对应要求，因此在STM32WB芯片上，还需要一个额外的FUS的更新。

我们通过USB和JTAG/SWD两种接口，以有线、近程的方式，分别对USB dongle板子和WB Nucleo板，做了FUS、和BLEstack的升级。