如何将普通应用更改为 OTA APP

1. 引言

客户在基于 BlueNRG-LP 设计产品时，code base 用的是 SDK 中某些不带 OTA 升级功能的参考示例，当客户完成其基本设计功能后，想要添加 OTA 的软件升级功能。在这个过程中往往会碰到一些问题。基于上述考虑，本文尝试阐述在 BlueNRG-LP_LPS DK 1.2.0 中默认参考示例“BLE_Security”添加 OTA 功能的过程，及其中需要注意的相关细节。

IDE 工具使用的是 KEIL。

2. BlueNRG-LP 方案中 OTA 软件升级功能简介。

BlueNRG-LP 方案中提供了 2 种 OTA 的软件框架，分别是 OTA Reset Manager 框架和OTA Service Manager 框架。不同框架下程序在 Flash 的分别位置和区域图 1 所示。

图1. OTA 软件升级框架

图 1 中中间部分代表 OTA Reset Manager 框架，由三段程序构成，分别是：

Reset Manager，负责程序的跳转，根据有效标志选择执行 Higher APP 还是 LowerAPP。
Higher APP 和 Lower APP 是客户不同版本的应用程序，同一时间运行其后一个升级的版本。Higher APP 和 Lower APP 都集成的 OTA 升级相关的 Service 和Characteristic，与支持 OTA 功能的主机端或手机 APP 进行交互，进行软件升级。也就是通过 Lower APP 可以将 Higher App 升级到芯片中并在后续芯片重启后一直运行的有效用户程序为 Higher APP, 反之，可通过 Higher App 来升级 LowerAPP。

图 1 中右边部分代表 OTA Service Manager 框架，由两段程序构成，分别是

OTA Service Manager：支持 OTA 功能，用来升级用户应用程序 User APP
User APP : 正常的 BLE 应用程序，不带 OTA 升级功能。
NVM(4K) 区域是 Flash 给协议栈保留的存储区域，客户程序不能用。

2.1. OTA Reset Manager 和 OTA Service Manager 两种框架的优缺点

下图 2 中阐述了 OTA Reset Manager 和 OTA Service Manager 两种框架下的软件升级流程。

图2. OTA 软件升级流程
在这里插入图片描述

2.1.1. OTA Reset manager

优点：在升级新版本软件时，芯片中同时保存着老版本的软件，即使程序升级失败，模块还能正常工作。
缺点：相比于 Service Manager 方式应用程序的可用 Flash 空间较小。

2.1.2. OTA Service Manager

优点：程序空间相比于 Reset Manager 方式较大。
缺点：软件升级失败后，模块无法正常运行。

2.1.3. 如何选择合适的 OTA 升级方式？

根据客户程序的大小，优先使用 OTA Reset manager 框架的 Higher/Lower App 方式。

3. 软件更改前的准备

建议客户在实施软件更改前仔细阅读文档 AN5463 - The BlueNRG-LP (over-the-air) Firmware upgrade, 里面有关于 OTA 功能相关的详细介绍和不同 OTA 框架下软件更改的必要步骤。

4. 软件更改步骤

本例软件更改基于 SDK 中 BLE_Security 示例代码，在 Buliding Target “Slave_PassKey_Random”中添加 Higher/Lower APP OTA 功能。

4.1. 配置项目，添加相关宏定义：

a. 如要生成 Lower APP :
-i. 添加预处理宏：CONFIG_OTA_LOWER 和CONFIG_SW_OTA_DATA_LENGTH_EXT.
-ii. 在 Link 标签页中添加链接宏定义 : --predefine="-DCONFIG_OTA_LOWER=1 "
b. 如要生成 Higher APP :
-i. 添加预处理宏：CONFIG_OTA_HIGHER 和CONFIG_SW_OTA_DATA_LENGTH_EXT.
-ii. 在 Link 标签页中添加链接宏定义 : --predefine="-DCONFIG_OTA_HIGHER=1 "

图 3.项目配置窗口

在这里插入图片描述

4.2. 在项目中添加 OTA 代码文件

a. 添加模块 Middleware/OTA, 并在模块中添加 OTA_btl.c。
b. 在下图中“Include Paths”包含 OTA_btl.h 所在的路径。
c. OTA_btl.c/h 文件在 SDK 中目录
“Middlewares\ST\BLE_Application\OTA\src”和
“Middlewares\ST\BLE_Application\OTA\inc”下。

图 4. 添加 OTA 代码文件
在这里插入图片描述

4.3. 代码更改步骤：

a. 代码文件 P_main.c 中添加 :
-i. 包含头文件 OTA_btl.h
-ii. 在主循环中添加 OTA 的处理函数。
b. 代码文件 BLE_Security_Peripheral.c 中添加：
-i. 包含头文件 OTA_btl.h，同上
-ii. 修改函数 DeviceInit 函数，添加 OTA 相关的 service 和 characteristic。
-iii. 修改 Make_Connection 函数中，增加主设备扫描时发送 scan response 返回 OTA 相关 UUID 功能。
-iv. 修改 hci_disconnection_complete_event 函数，添加 BLE 断开连接后关闭OTA 跳转标志相关函数。
-v. 在函数 aci_gatt_srv_attribute_modified_event 和aci_gatt_srv_read_event 中添加 OTA 功能相关数据交互函数。
-vi. 在代码文件末尾添加事件回调函数：
1. aci_hal_end_of_radio_activity_event
2. aci_att_exchange_mtu_resp_event
3. hci_le_data_length_change_event
4. aci_gatt_srv_write_event
c. 为了加快 OTA 升级速度，必须支持数据长度扩展功能。
-i. 由于原始项目中协议栈配置选项使用了“BLE_STACK_CUSTOM_CONFIG”
-ii. 需要在协议栈配置头文件 custom_ble_stack_conf.h 使能编译开关CONTROLLER_DATA_LENGTH_EXTENSION_ENABLED
d. 增加 OTA 功能，就必须要在 GATT Database 中添加 OTA 相关的 Service、characteristic，但由于原始项目的配置头文件
“BLE_Security_Peripheral_config.h”并未分配足够的 RAM 空间，会导致编译时出错。需要在配置头文件中做相应更改。

【注】：上述更改说明简单列举的更改的文件、函数及更改的原因内容，具体代码请参考附件代码压缩包。用户可比较 SDK1.2.0 中的原始代码和附件代码压缩包以找到对应更改的位置和响应代码。

5. 软件更改验证

1)验证 Lower APP:
使用 FLASH UTILITY 工具，分别烧录程序：BlueNRG-LP_LPS DK
1.2.0\Firmware\BLE_Examples\BLE_OTA_ResetManager\STEVAL-IDB011V1
BLE_OTA_ResetManager.hex 和生成的 Lower APP.
PC 端通过串口工具获取程序运行时的打印信息判断程序是否正常运行？
2)验证 OTA 功能：
使用另一块 ST 评估板 STEVAL_IDB011V1，烧录 DTM 程序，通过 BlueNRG-GUI 工具来完成 Higher APP 的升级，从而验证 Lower APP 的 OTA 功能是否正常？
3)验证 Higher APP :
如第(2)步验证通过，则说明 Higher APP 升级成功，此时通过 PC 端串口工具获取程序运行时的打印信息判断程序是否正常运行？
(4) 可重复第(2)步过程，完成 Lower APP 的升级，验证 Higher APP 的 OTA 功能是否正常？

6. 小结

本文档说明了 BlueNRG-LP 设计方案中在不带 OTA 功能的应用程序中添加 OTA 功能所需要做的相关步骤，这些更改逻辑同样适用于 BlueNRG 系列中的其他芯片，如BlueNRG-1/2/LPS 以及后续的 LPF 芯片。唯一需要注意的是协议栈 API 的命令规则随着不同版本 SDK 的升级可能存在的变化。