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

你可能感兴趣的:(硬件开发,软件开发)