STM32生态系统第三期（一）STM32WB无线协议栈和用户应用升级的准备工作

80 阅读 0 评论 53 点赞

我是靠谱客的博主长情御姐，最近开发中收集的这篇文章主要介绍STM32生态系统第三期（一）STM32WB无线协议栈和用户应用升级的准备工作，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

STM32生态系统第三期（一）STM32WB无线协议栈和用户应用升级的准备工作
STM32_STM8_MCU2019-10-31 阅读数：2032
以往普通的一颗STM32，拿到芯片空片后，我们可以通过ISP的方式通过usb、uart等常用接口，给芯片下程序；或者通过JTAG/SWD这样的调试接口下程序。运行一段时间后，要做用户应用程序的更新，除了继续使用JTAG/SWD调试接口外，可以通过ISP和IAP的方式来更新程序。ISP和IAP原理类似，都是通过运行在芯片上程序，通过约定的通信端口，比如usb、uart来接收上位机程序，再烧到芯片内部。只不过ISP的这段程序，运行在STM32出厂预置在系统flash里；而IAP的这段程序，是用户自己开发并下载到用户的flash里。（所谓有线升级）

进一步，随着IoT时代的到来，无线升级成为嵌入式设备的必备功能之一：之前的STM32没有片上RF模块，通常外接wifi，nb-iot、lora等这种无线模块，把它们作为通道，从空中接收要更新的程序，然后写到芯片里做更新。（所谓无线升级，或者空中（FOTA））

那么现在STM32WB来了，首先它自带BLE接口，可以通过BLE上位机或者手机来给芯片做无线升级。

但是它自身的双核架构（一个M4核跑用户应用程序，一个M0+核跑RF 协议栈）、它的片上flash结构（安全flash区域、非安全flash区域），使得它片上内容的升级和往常有点不一样。对于M4上运行的用户应用程序，倒是没啥区别，主要是如何安装、升级由M0+内核运行的RF协议栈，还有如何升级一个叫做“FUS”，firmware update service服务的特殊代码。这是以往STM32 MCU没有涉及的新东西。这期我们就来讲一讲。

协议栈和应用程序的更新

这是上一期STM32WB生态系统概览里介绍的，围绕着STM32WB芯片，我们提供给大家的从文档、到工具、到软件包、到培训、到方案的一系列生态系统。

对于今天要谈的协议栈和用户应用程序升级的话题，我们会用到图中红色标亮的这些部分内容。

首先是ST官方出品的STM32WB工具套件（里面两颗STM32WBx5G芯片，分别在nucleo板和usb dongle板上）。基于它，我们会使用STM32Cube工具里的CubeProgrammer的命令行，通过usb接口，升级芯片的FUS版本，安装BLE蓝牙协议栈。

然后，在Nucleo板上运行STM32CubeWB固件包里的ota相关例程。做协议栈和用户应用程序的无线升级时，上位机可以使用STM32Cube工具包里的CubeMonitor-RF，也可以使用ST BLE Sensor手机app操作。

协议栈和应用程序的更新-所需的技术资料

第一个文档AN5185，介绍STM32WB芯片里的FUS这段服务。FUS，就是firmware update service的意思，就是专门为firmware升级来服务的一段程序，但是这里的“firmware”是专指由M0+内核运行的FUS本身和RF协议栈，不是指的M4内核上运行的用户应用程序哦。第二个文档AN5247，就是搭配下面三个黄色标注的软件项目，来说明如何使用FUS来对自身，或者RF协议栈升级；也包括如何对WB上的用户程序升级。

在整个操作过程中，还需要使用灰色标注的这些工具软件、和app。我们会在后面使用的时候详细来讲。所以，现在请大家把表格中所列的这些文档、软件包、工具、手机app都下载后。所用的硬件板子就是STM32WB套件板，在STM32天猫旗舰店有卖。

STM32WB. RF协议栈

STM32WB这颗芯片和往常的STM32芯片有一点不一样：除了都出厂预装了供ISP所用的bootloader在系统flash里，WB芯片，虽然它支持多种协议（比如ble、thread、zigbee），但是出厂并没有把协议栈预先烧到芯片里，而是把这些协议栈的二级制分别由ST签名加密，然后这些image，随STM32CubeWB 固件包一起发布，不断更新。WB芯片出厂的时候，没有预置RF协议栈，但是预装了FUS，就是为了客户把芯片拿到手后，按照自己的应用需求，选取对应的RF stack烧录进去。FUS对客户所选的RF 协议栈进行解密和验签，合法的RF 协议栈，即确定是来自ST发布的，且没有被篡改的RF stack才会被烧到WB芯片里。当然，客户还可以对某一个版本的ST的RF 协议栈进行二次签名，FUS也会根据对应烧录在WB 安全flash里的认证key来验签，这是另外一个话题，这里不详细展开。

因此，STM32CubeWB 固件包也和以往的STM32CubeF4、F7这些固件包有一点不一样，它不仅包含了指定板子上的大量预编译好的项目例程，还在Projects目录下有一个专门的文件夹：STM32WB_Copro_Wireless_Binaries，来存放最新版的RF协议栈和最新版的FUS。从现在的文档看来，目前所有出厂的WB芯片，都是预装了0.5.3版本的FUS。

现在国内主要用的比较多的还是BLE低功耗蓝牙应用，因此我们就以BLE stack为例进行说明。红框高亮的就是待会儿，我们会用到的两个二进制image。

四种方式，更新协议栈和用户应用

我们的目标是更新WB芯片里的RF 协议栈，和用户应用程序。统共说下来，有四种方式。其中近程有线方式两种，通过USB通信接口、和JTAG/SWD调试接口，分别搭配STM32CubeProgrammer和STLINK Utility这两种上位机软件的命令行使用。由于Nucleo板子上有STLINK连接了WB的JTAG/SWD，我们在Nucleo板子上演示通过JTAG/SWD升级RF 协议栈；在USB dongle板子上演示使用USB升级RF 协议栈。如何使用这两种近程方式烧写用户flash里的用户应用程序，这个和以往STM32没有任何区别，不在此累述。

另外一大类就是使用BLE接口的空中升级方式。条件是：WB芯片里面已经有合适的BLE 协议栈和带BLE ota功能的bootloader程序；那么就可通过手机或者装有STM32CubeProgrammer的上位机作为ota 客户端发起OTA请求，被提供新版RF stack或者新版的用户应用程序。

刚才提到的STM32WB和以往STM32芯片不一样的一点，比如F4，左边，芯片出厂前就在system-flash即系统flash里预装了bootloader，它通常支持usb、uart这些常用通信接口。于是可以通过ISP，直接往裸片里写user application；或者先通过ISP或者其他JTAG调试接口把【用户bootloader】写进main flash，再通过【用户bootloader】做IAP，来烧写或者更新后面的user application。这是非常常规的做法，大家都很熟悉了。

STM32WB是双核结构，M0+跑协议栈，M4跑用户应用，由于支持多种协议栈，因此芯片出厂前并未烧录协议栈，而是放了一个FUS，就是用来，让客户自主选择并烧录协议栈的。RF Stack呢，在STM32CubeWB包里，通常拿到WB芯片后，大家总归会去使用最新版本的BLE stack，而最新版本的BLE stack是和0.5.3版本的FUS不匹配的，因此通常的做法是，使用最新版本的STM32CubeWB固件包里，最新的RF stack和最新的FUS同步更新。那么可以通过ISP，使用芯片出厂内置的bootloader，先更新FUS，再通过FUS更新RF stack。同样的，这样的功能也可以用户自己写出来，放在用户flash中，使用IAP来更新要么用户自己的应用，要么FUS，要么RF stack。

红线说明：所有对RF stack的操作，都用通过FUS来做。因此为了匹配最新版本的RF stack，FUS通常都要更新。

RF stack和FUS随STM32CubeWB包一起发布

目前，到2019.10月初，ST官网上出现了四个版本的STM32CubeWB，从1.0.0、1.1.0， 1.1.1到1.2.0。
在这四个CubeWB固件包里，衍生了4个版本的BLE stack，1.0.0， 1.1.0， 1.1.1， 1.2.0；2个版本的FUS版本，1.0.1和1.02。大家可以查看存储这些二进制image的文件夹下的relase note来区分版本的变化。

总的来说，FUS 1.0.1版本，增加了对CKS的支持（CTM key service，即用户秘钥管理，这个在下一期来讲，和OTA没有直接关系）。到了1.0.2，首次支持256K和512K flash的WB5x芯片。所以如果你手上是STM32WB5xxC或者E，那么必须先把FUS更新到1.0.2版本。我们手里要操作的STM32WB套件中的两个板子上都是STM32WB5xG，因此可以升到1.0.1，也可以直接升到1.0.2。
绿色标明的就是，后面我们要用到的两个二级制image，它们的版本，以及将要安装的地址，待会儿命令行输入命令时，需要这些参数。

芯片出厂预装

因此，如果你手上有一颗STM32WB样片，那它就是左边图一的样子，芯片里出厂只内置了系统bootloader和0.5.3版本的FUS。通常你们需要先升级FUS到最新版本，比如当前的1.0.2；然后有了合适的FUS，就可以通过它来安装最新版本和匹配FUS的RF stack了，比如这里的1.2.0版本的BLE stack。之后可以通过和以前一样的方式来下载用户应用程序了。

细心的朋友，可能已经发现：FUS即以下部分，main-flash后面有个（s），表示是secured flash，即是专门由M0运行、RF stack和FUS所在的安全用户闪存区域。它不能通过jtag/swd这样的外部调试接口访问，内部访问它也需要经过FUS。因此才比较特别。其上的main flash是非安全用户闪存区，和以往的STM32片上用户闪存一样的读、写、擦除。

逻辑是：出厂芯片里没有RF stack，因此要下载。RF stack一般会用最新的STM32CubeWB包里的，而那里的RF stack，对应也要新版本的FUS。因此先要升级FUS到最新STM32CubeWB中的版本，再同步版本的RF stack，再同步版本的用户应用程序。

板子出厂预装

好了，我们手上是STM32WB套件板。它上面的芯片除了浅蓝色部分标出的芯片出厂预烧的系统bootloader和FUS，还预烧了某个版本的BLE RF 协议栈，以及用户应用程序。
在Nucleo板里的应用程序是P2P server，在USBDongle板里的是P2P client。也就是说这两个板子从套件里拿出来的时候，是可以彼此通过P2P协议通信的。具体对整个预装程序的描述，和使用，请参考文档《UM2551》。

检验当前版本（FUS/RF Stack）

我们先来看一下两个板子里预装的FUS和BLE stack版本：将它们分别设置成系统flash启动，和PC相连；使用STM32CubeProgrammer命令行，去读取内存地址0x2003 0024处开始的50个字节。从图中读到的结果，可知USBDongle板子，当前的FUS和BLE stack版本分别是0.5.3和0.5.1；而Nucleo板上的情况也是一样。
转自http://news.eeworld.com.cn/mp/STM32/a75404.jspx