请选择 进入手机版 | 继续访问电脑版

你的浏览器版本过低,可能导致网站不能正常访问!
为了你能正常使用网站功能,请使用这些浏览器。

基于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)

11.jpg

接下来,我们看看无线的,空中升级的原理。升级对象是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

22.jpg

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

升级用户应用

33.jpg

我们先来升级用户应用,目标是从当前的心跳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没有什么区别。

44.jpg

对于Nucleo板,要把两个分别链接在两个不同flash地址的项目下载下去,可以使用IAR里的Download active application功能;当然STM32CubeProgrammer也有类似功能,大家按照自己的喜好使用不同工具都可以。
对于Dongle板,它只有USB口,没有jtag/swd调试口暴露出来,因此要使用它的系统bootloader,使用DFU的形式,把透传VCP的程序下载下去,上位机,就用我们的STM32CubeProgrammer即可。烧写好了之后,dongle板记得恢复到从用户flash启动。连到PC会看到一个虚拟串口。

启动 STM32CubeMonitorRF,并连接 Dongle 设备

55.jpg

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

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

66.jpg

启动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 协议栈

77.jpg

更新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即可。

再次检验当前版本

88.jpg

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

架构:用户bootloader – 用户application

99.jpg

通过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.

10.jpg

自定义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,建立连接之前的广播阶段,表达出来。

广播包自定义信息

111.jpg

广播报文包,在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通信流程

222.jpg

最后,我们来理一下整个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通信。

333.jpg

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

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

444.jpg

最后,我们总结一下本期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)小结

555.jpg

然后,以WB Nucleo为对象,上位机使用STM32CubeMonitor-RF搭配USBDongle板做透传,对WB Nucleo板子的BLE 协议栈和应用程序做了升级到演示。
希望本次讲解能帮助你更好的学习和理解关于STM32WB的协议栈和应用程序升级。



收藏 评论2 发布时间:2020-5-27 12:58

举报

2个回答
李康1202 回答时间:2020-5-28 08:54:30
谢谢分享
STMWoodData 回答时间:2021-9-10 11:19:45
打卡学习,好资料,蓝牙无线更新代码,很方便的
关于意法半导体
我们是谁
投资者关系
意法半导体可持续发展举措
创新和工艺
招聘信息
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
关注我们
st-img 微信公众号
st-img 手机版