01

引言

客戶在使用 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 和靜態協議棧的選擇流程圖如下圖所示

02

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) orBLE_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 自動選擇對應的來升級。

03

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, 則表明BLE_OTA_ServiceManager的大小不能超過0x3000（12*1024） 字節。BLE_OTA_ServiceManager是一個帶OTA服務的啟動程序，宏定義MEMORY_FLASH_APP_SIZE限制這個工程編譯的程序空間大小不能超過這個范圍。

如果在linker中沒有定義MEMORY_FLASH_APP_SIZE，則對應的4種配置分別是：

MEMORY_FLASH_APP_OFFSET: 定義程序編譯鏈接地址的偏移（非OTA程序）。如果在linker中沒有定義MEMORY_FLASH_APP_OFFSET，則對應的4種配置分別是：

前面提到默認SDK中提供了4種程序的鏈接配置，本質上只是計算MEMORY_FLASH_APP_OFFSET和MEMORY_FLASH_APP_SIZE的方式不同而已，如果應用需要，也可以改動這個鏈接腳本文件。

04

通過協議棧的初步裁剪與自定義優化空間

SDK 中默認提供了 4 種默認配置的協議棧加一種自定義的協議棧配置（BLE_STACK_CUSTOM_CONF），如下圖所示。

上述 5 種不同協議棧的配置，本質上就是通過使用宏控制不同的特性功能是否打開。只是前面 4種提供了默認便捷的設置，而最后一種可以進行細粒度更細的自定義的協議棧。

可以在 Preprocesor Symbols 中定義相關的宏來配置使用哪種協議棧配置。

如果選用細粒度更細的 BLE_STACK_CUSTOM_CONF 協議棧配置，則在 其中在頭文件“custom_ble_stack_config.h”中開關不同功能特性，大致占用的代碼如下圖所示。

05

協議棧的進一步裁剪:使用靜態協議棧

5.1 靜態協議棧工程的 4 種默認的配置

ST 官方 SDK 中已經提供了靜態協議棧的 Demo，分為協議棧工程和應用工程兩部分，路徑為：C:Usersuser nameSTBlueNRG-LP DK 1.x.xProjectsBLE_ExamplesBLE_StaticStack 靜態協議棧工程默認提供了 4 種配置：

? Release

? Basic

? OTA_BTL_ResetManager

? OTA_BTL_ResetManager_Basic

C:Usersuser nameSTBlueNRG-LP DK 1.x.0ProjectsBLE_ExamplesBLE_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.0ProjectsBLE_ExamplesBLE_SensorDemo_StaticStackREADME.txt

以及 SDK 安裝目錄的 index.html 中的靜態協議棧的介紹如下圖所示。

如果在實例化 OTA 程序時，可能需要修改鏈接腳本和 Preprocesor Symbols 中下面幾個宏（具體不同應用，不同 OTA 類型，具體需要定義的宏和宏的數值也不同）：

RESET_MANAGER_SIZESERVICE_MANAGER_OFFSETSERVICE_MANAGER_SIZEMEMORY_FLASH_APP_SIZEMEMORY_RAM_APP_OFFSET

5.3 使用默認配置的協議棧

如果使用了 OTA，發現空間不夠，可以考慮將應用協議棧和 OTA 協議棧合并使用如下圖所示。

上圖列舉的是基于 BlueNRG-LP 的默認提供的工程的大致數值（BlueNRG-LPS 類似，這里不再舉例）。如果遇到不同的應用，可以實際裁剪協議棧適配不同的應用需求。

5.4 使用自定義配置的協議棧

使用靜態協議棧可以實現更為精確的函數級別的裁剪:通過注釋協議棧工程中的 bluenrg_lp_cmd_if.c 中的 cmd_call_table 中對應的函數，編譯時可以將不使用的協議棧函數裁減出協議棧。

5.5 使用靜態協議棧這種模式如何支持升級協議棧

當使用靜態協議棧，默認協議棧就無法升級。為了能夠支持協議棧也升級。需要增加一段 boot代碼，當升級協議棧時，先放置在 APP 區域，當升級完協議棧后，將 APP 區域的協議棧拷貝到協議棧區域。接著繼續升級被擦除的應用程序。Boot 代碼決定搬運協議棧和跳轉到下一級。

06

優化后空間仍不足的其他方法

如果使用靜態協議棧和空間仍然不足，可以考慮將一些常用而不需修改的通用模塊編譯進協議棧的工程。如果空間仍然差距比較遠則考慮用片外 Falsh 或者選用 STM32WB 系列，再或者使用 STM32+協處理器模式。

審核編輯：劉清