简谈 BlueNRG-LP 和-LPS 的代码空间优化

1.引言

客户在使用 BlueNRG-LP/LPS 芯片时，增加 OTA 服务后常常反馈说，编译代码区域超空间了，需要帮忙优化一下。后文主要通过下列步骤进行分析和优化 BlueNRG-LP/LPS 的代码空间：

a. 通过分析 BlueNRG-LP/LPS 的 OTA 方式，让客户可以选择合适的方式；
b. 通过整体分析 BlueNRG-LP/LPS 的链接文件（.icf/.sct/*.ld）了解默认工程的存储分布；
c. 通过裁剪协议栈，选择合适的协议栈功能，优化 BlueNRG-LP/LPS 的代码空间；
d. 通过使用静态协议栈，进一步优化 BlueNRG-LP/LPS 的代码空间；
e. 其他方案；

总的来说通过两个维度来节省空间：

一个是协议栈的裁剪维度：主要是通过修改宏配置实现编译对应应用需要的协议栈。

另一个是 OTA 和静态协议栈的维度：OTA 和静态协议栈的选择流程图如下图所示。
在这里插入图片描述

2.BlueNRG-LP/BlueNRG-LPS 的 OTA

2.1 OTA 的框架

手机或者电脑做 GATT Client，给带 OTA 服务的设备升级。
在这里插入图片描述

2.2 官方提供的 OTA 方式

默认提供的 OTA 应用和协议栈编译在一个固件上。

a. 不带备份的(右图中的右半部分)
升级服务程序在 Boot 端(OTA Service manager)。
省空间（存放了 2 份协议栈，1 份应用）
管理简单（只需管理一份应用）
b. 带备份的(右图中的左半部分)
升级服务程序在应用端
更消耗空间（存放了 2 份协议栈，2 份应用）
管理稍微麻烦（需要管理两份应用，Lower 区域应用
不能放置 Higher 区域运行）
更安全
a. 不带备份的方式由以下组件构成：
BLE_OTA_ServiceManager+ application
b. 带备份的由以下组件构成：
BLE_OTA_ResetManager +Lower Application (with BLE OTA service) or
BLE_OTA_ResetManager + Higher Application (with BLE OTA service)

对应在 SDK 中工程和配置如下图所示：
a. BLE_OTA_ServiceManager 配合 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager
b. BLE_OTA_ResetManger 配合 BLE_SerialPort 中的 Service_LowerApp_OTA 或者Service_LowerApp_OTA 使用
在这里插入图片描述

2.3 使用带备份类型 OTA 升级错误变砖头问题

编译器编译的 Higher Application 如果放置在 Lower Application 的位置，程序无法运行。

APP 程序可以知晓当前运行的固件是 Lower 还是 Higher APP。可以在编译固件 Higher Application 和 Lower Application 中加入一些标记，用于给升级工具识别，当前需要下载的是Higher Application 还是 Lower Application 或者是否混用。建议每次发布时两个应用程序都编译生成，不要人为来管理固件，否则容易造成混乱，应该让升级 app 自动选择对应的来升级。
在这里插入图片描述

3.BlueNRG-LP/LPS 的存储分析

3.1 linker 中宏定义作用范围

Linker 中可定义一些宏、用于指定链接脚本文件所需的配置。这些宏定义不作用于.c文件或者.h文件，只作用于链接文件（.icf 或者.sct 或者 *.ld）。

3.2 链接脚本文件分析（代码区域）

不同的 IDE 所使用的链接脚本文件的格式不同。比如，Keil 使用“.sct”文件，IAR 使用“.icf”文件，而 TrueStudio 使用 “*.ld”文件。

下面分析BlueNRG-LP最新SDK中BLE_SerialPort项目IAR工程目录下的BlueNRG_LP.icf文件, 其他IDE一样，可以进行类比。由于Flash的擦除必须是整页操作的，写Flash之前必须将对应的页擦除，所以Flash的划分需要2KB对齐。就算只使用到0.9KB，也需要划分2KB区域。

默认SDK中提供了4种程序的链接配置:

CONFIG_OTA_HIGHER
CONFIG_OTA_LOWER
.CONFIG_OTA_USE_SERVICE_MANAGER
其他

对于这四种链接配置编译后，代码区域放置在如下地址。BLE_OTA_ServiceManager 工程使用的是非 OTA 程序，而 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager 工程使用的是CONFIG_OTA_USE_SERVICE_MANAGER。

上述4种程序的链接配置由以下宏定义来指定：

MEMORY_FLASH_APP_SIZE: 定义程序使用Flash的大小。以工程BLE_OTA_ServiceManager为例子，在linker中定义了MEMORY_FLASH_APP_SIZE = 0x3000, 则表明LE_OTA_ServiceManager的大小不能超过0x3000（12*1024）字节。

BLE_OTA_ServiceManager是一个带OTA服务的启动程序，宏定义MEMORY_FLASH_APP_SIZE限制这个工程编译的程序空间大小不能超过这个范围。

如果在linker中没有定义MEMORY_FLASH_APP_SIZE，则对应的4种配置分别是：

• CONFIG_OTA_HIGHER ---> (((_MEMORY_FLASH_SIZE_ - RESET_MANAGER_SIZE -
FLASH_NVM_DATASIZE)/2)/2048)*2048
• CONFIG_OTA_LOWER ---> (((_MEMORY_FLASH_SIZE_ - RESET_MANAGER_SIZE -
FLASH_NVM_DATASIZE)/2)/2048)*2048
• CONFIG_OTA_USE_SERVICE_MANAGER ---> (_MEMORY_FLASH_SIZE_ -
SERVICE_MANAGER_SIZE - FLASH_NVM_DATASIZE)
• 其他 ---> (_MEMORY_FLASH_SIZE_ - FLASH_NVM_DATASIZE -

MEMORY_FLASH_APP_OFFSET)
MEMORY_FLASH_APP_OFFSET: 定义程序编译链接地址的偏移（非OTA程序）。

如果在linker中没有定义MEMORY_FLASH_APP_OFFSET，则对应的4种配置分别是：

• CONFIG_OTA_HIGHER ---> (RESET_MANAGER_SIZE + MEMORY_FLASH_APP_SIZE)
• CONFIG_OTA_LOWER ---> (RESET_MANAGER_SIZE)
• CONFIG_OTA_USE_SERVICE_MANAGER ---> (SERVICE_MANAGER_SIZE)
• 其他 ---> MEMORY_FLASH_APP_OFFSET (0)

前面提到默认SDK中提供了4种程序的链接配置，本质上只是计算MEMORY_FLASH_APP_OFFSET和MEMORY_FLASH_APP_SIZE的方式不同而已，如果应用需要，也可以改动这个链接脚本文件。

4.通过协议栈的初步裁剪与自定义优化空间

SDK 中默认提供了 4 种默认配置的协议栈加一种自定义的协议栈配置（BLE_STACK_CUSTOM_CONF），如下图所示。
在这里插入图片描述
上述 5 种不同协议栈的配置，本质上就是通过使用宏控制不同的特性功能是否打开。只是前面 4种提供了默认便捷的设置，而最后一种可以进行细粒度更细的自定义的协议栈。

可以在 Preprocesor Symbols 中定义相关的宏来配置使用哪种协议栈配置。
在这里插入图片描述
如果选用细粒度更细的 BLE_STACK_CUSTOM_CONF 协议栈配置，则在其中在头文件“custom_ble_stack_config.h”中开关不同功能特性，大致占用的代码如下图所示。

5.协议栈的进一步裁剪:使用静态协议栈

5.1 静态协议栈工程的 4 种默认的配置

ST 官方 SDK 中已经提供了静态协议栈的 Demo，分为协议栈工程和应用工程两部分，路径
为：
C:\Users\user name\ST\BlueNRG-LP DK 1.x.x\Projects\BLE_Examples\BLE_StaticStack
静态协议栈工程默认提供了 4 种配置：

• Release
• Basic
• OTA_BTL_ResetManager
• OTA_BTL_ResetManager_Basic
C:\Users\user name\ST\BlueNRG-LP DK 1.x.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack
• Release
• LowerApp_OTA
• HigherApp_OTA

那它们有什么区别呢？它们可以分为两组。

Release 和 Basic 是一组：它们运行时都是由协议栈程序直接跳转到一个固定的应用上；

Release 和 Basic 的区别： Basic 的协议栈配置是 BLE_STACK_BASIC_CONF，而 Release的协议栈配置是 BLE_STACK_FULL_CONF。

不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。

• 不同的协议栈配置包含的功能请查看 stack_user_cfg.h
• 占用的 Flash 空间可以通过编译的 Map 文件查看
• 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
• Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 是另外一组：它们都是由协议栈程序跳转到 Lower 应用程序或者 Higher 应用程序；
• OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 的区别：
OTA_BTL_ResetManager_Basic 的协议栈配置是 BLE_STACK_BASIC_CONF，而
OTA_BTL_ResetManager 的协议栈配置是 BLE_STACK_FULL_CONF
• 不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。
o 不同的协议栈配置包含的功能请查看 stack_user_cfg.h
o 占用的 Flash 空间可以通过编译的 Map 文件查看
o 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
o Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。

其中，一个工程负责生成协议栈，另一个工程负责应用，那么这里 BLE_StaticStack 中的Release or Basic 与 OTA_BTL_ResetManager or OTA_BTL_ResetManager_Basic 怎么和Release，LowerApp_OTA 和 HigherApp_OTA 组合呢？

• BLE_StaticStack 中的 Release or Basic + BLE_SensorDemo_StaticStack 中的Release //不带备份 OTA 的使用固定协议栈的方
• BLE_StaticStack 中的 OTA_BTL_ResetManager or OTA_BTL_ResetManager_Basic + BLE_SensorDemo_StaticStack 中的 LowerApp_OTA or HigherApp_OTA //带备份OTA 的使用固定协议栈的方法

5.2 将工程实例化为静态协议栈工程

将工程实例化为静态协议栈涉及比较多的步骤，可以参考官方的文档 :
BlueNRG-LP_LPS DK 1.2.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack\README.txt

以及 SDK 安装目录的 index.html 中的静态协议栈的介绍如下图所示。
在这里插入图片描述
如果在实例化 OTA 程序时，可能需要修改链接脚本和 Preprocesor Symbols 中下面几个宏（具体不同应用，不同 OTA 类型，具体需要定义的宏和宏的数值也不同）：
RESET_MANAGER_SIZE
SERVICE_MANAGER_OFFSET
SERVICE_MANAGER_SIZE
MEMORY_FLASH_APP_SIZE
MEMORY_RAM_APP_OFFSET