基于STM32WB的低功耗蓝牙应用（三）用户应用程序的无线更...

[复制链接]

STMCU-管管发布时间：2020-5-27 12:58

技术帖
文章封面:	-
文章简介:	-

1、STM32 生态系统|基于STM32WB的低功耗蓝牙应用（一）：https://www.stmcu.org.cn/module/forum/thread-621995-1-1.html

2、基于STM32WB的低功耗蓝牙应用（二）RF协议栈的有线和无线更新：https://www.stmcu.org.cn/module/forum/thread-625173-1-1.html

基于STM32WB的低功耗蓝牙应用（三）用户应用程序的无线更新（OTA空中升级）

无线/空中升级

无线/空中升级（FOTA）

接下来，我们看看无线的，空中升级的原理。升级对象是Nucleo板子。它的FUS已经是1.0.1，可以不用在升级了；我们把BLE stack从1.1.0升到最新的1.2.0；用户程序就更加直观了，从心跳 profile，升级成P2P server profile。上位机采用PC上的STM32CubeProgrammer，并搭配运行TransparentVCP（虚拟串口透传功能）的USB dongle板，一起工作。

使用 STM32CubeMonitorRF 触发 BLE 连接的 OTA

左边是上位机，FOTA客户端，通过BLE，发起OTA请求，并提供新版本image；右边是Nucleo板，FOTA server端，通过BLE，接收OTA请求，并接收新版本的image。可以升级用户程序本身，也可升级RF stack，如图中两个红色箭头所示。

升级用户应用

我们先来升级用户应用，目标是从当前的心跳profile，升级到P2P server，升级成功后，效果非常直接，运行手机app， ST BLE sensor，连接设备，界面完全不同。为了达到这个目标，使用STM32CubeWB固件包中的三个项目。先把BLE_OTA和BLE_HeartRate_ota下载到nucleo板子上；把BLE_heartrate_ota下载到0x0800 7000处。ble_ota是编译链接在0x0800,0000地址处，是Nucleo板子上电就运行的；它要是没有查到ota请求标志，并且0x0800,7000处有有效代码，则跳转到0x800,7000运行，执行heart rate的心跳profile了。否则继续执行ota本身，开始准备接收来自FOTA 客户端的新固件。这样看下来，整个过程，逻辑上跟我们以前的IAP by USB， IAP by Ethernet没有什么区别。

对于Nucleo板，要把两个分别链接在两个不同flash地址的项目下载下去，可以使用IAR里的Download active application功能；当然STM32CubeProgrammer也有类似功能，大家按照自己的喜好使用不同工具都可以。

对于Dongle板，它只有USB口，没有jtag/swd调试口暴露出来，因此要使用它的系统bootloader，使用DFU的形式，把透传VCP的程序下载下去，上位机，就用我们的STM32CubeProgrammer即可。烧写好了之后，dongle板记得恢复到从用户flash启动。连到PC会看到一个虚拟串口。

启动 STM32CubeMonitorRF，并连接 Dongle 设备

打开STM32CubeMonitor-RF，在首页选择BLE协议；然后在Select device这里的下拉菜单中，选择Dongle板子对应的COM口，这里是COM14，然后点击connect。这个连接动作，实际是上位机发一条“获取版本信息”的命令给到dongle板。如果它正常工作，就会返回信息，如图右上角。

启动 OTA Updater，更新用户应用程序

启动OTA Update功能，搜寻OTA设备，找到之后选中它；

我们现在先来更新用户应用程序，因此Target CPU，使用默认的CPU1：M4即可；固件下载目标地址，使用默认的0x7000即可，这个值是和待更新的用于程序P2P_server_ota的链接地址保存一致的。然后通过browse按钮，给出新应用程序p2pserver_ota的bin文件地址。最后点击update即可。

升级完成后，会显示done的提示。nucleo板子当前已经是P2P sever了。使用手机app的STBLE Sensor可以连接并控制它上面的LED灯。

启动 OTA Updater，更新BLE 协议栈

更新BLE stack也是一样的操作。现在我们要把nucleo板子上的BLE stack1.1.0更新到最新的1.2.0。

也是启动OTA Update功能，搜寻OTA设备，找到之后选中它；因为要更新BLE协议栈，因此Target CPU，选择CPU2：M0+；image下载目标地址，使用默认的0xF000即可。这个地址是和OTA bootloader的代码搭配好的。然后指定1.2.0 版本BLE stack image的地址，点击Update即可。

再次检验当前版本

最后，为了验证，我们按照之前的方式，把Nucleo板子设置到系统bootloader启动，通过STM32CubeProgrammer的命令行，读出当前Nucleo板子上的BLE stack版本，已经从1.1.0升级到了1.2.0，符合预期。

架构：用户bootloader – 用户application

通过BLE接口，空中无线升级用户应用程序，和BLE 协议栈，体验完毕后，我们现在来讨论一下BLE FOTA的原理和实现。和普通的IAP一样，STM32CubeWB固件包里的ota例子，也是采用“用户bootloader和用户应用程序这种架构”。板子上电，先运行用户bootloader，即图中绿色OTA部分。因为之前没有收到来自外界的fota请求，并且0x0800,7000这里也已经烧好了用户应用，就跳到蓝色部分执行，heart rateprofile。heart rate心跳应用，除了常规的把测量到的心跳值，这里用的是一个模拟值，定期通过BLE发出去。我们使用手机app，STBLE sensor可以连接该设备，看到心跳的界面。除了这个常规业务功能，为了实现OTA功能，需要在现有的BLE service中，比如现在这个heart rate service里，增加一个名为OTA reboot request的characteristic。它用来接受发自OTA client，比如手机app，或者这里的CubeMonitor-RF上位机的固件升级请求。并且用户应用程序，在收到OTA请求后，在SRAM1的起始位置打上标记并复位。

复位后，先运行绿色的ota bootloader。这次它检查到了ota请求标志，于是就不跳转到蓝色的用户应用执行了，而是继续运行otabootloader的接收新固件程序。这是通过一个ST自定义的BLEservice实现的。

也就是说，这个BLE FOTA，相比以往传统的IAP，就是分别在bootloader和用户application，各自增加了一个自定义BLE service，和一个自定义的的characteristics。我们来看一下细节。

自定义BLE service/char.

自定义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的方式，要擦除的起始扇区编号、以及要擦除的扇区个数。这样一个支持rebootrequest/重启请求的能力，会在该设备和客户端AP，建立连接之前的广播阶段，表达出来。

广播包自定义信息

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

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

BLE通信流程

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

设备上电，最先运行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通信。

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

WB固件升级总结

近程升级FUS、RF Stack小结

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

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

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

无线/空中升级（FOTA）小结