01引言
0 L" X$ s+ D3 C; U客户在使用 BlueNRG-LP/LPS 芯片时，增加 OTA 服务后常常反馈说，编译代码区域超空间了，需要帮忙优化一下。后文主要通过下列步骤进行分析和优化 BlueNRG-LP/LPS 的代码空间：
; N& ]3 \3 \- a. |8 _a. 通过分析 BlueNRG-LP/LPS 的 OTA 方式，让客户可以选择合适的方式；
  [1 Y  S7 B9 R+ Q  Qb. 通过整体分析 BlueNRG-LP/LPS 的链接文件（*.icf/*.sct/*.ld）了解默认工程的存储分布；
. ?0 q0 `6 _: Z. j) M8 f8 dc. 通过裁剪协议栈，选择合适的协议栈功能，优化 BlueNRG-LP/LPS 的代码空间；
: T  ^! Y$ [+ ]: |' Y2 ]d. 通过使用静态协议栈，进一步优化 BlueNRG-LP/LPS 的代码空间；
- s" w+ l# R3 ]6 |. y- E. re. 其他方案；
( U1 O$ R0 K, H1 H5 J- d, Y
, W, b6 H* v$ r( t  z

% }/ D( F' U, W" v% i9 K. M总的来说通过两个维度来节省空间：一个是协议栈的裁剪维度：主要是通过修改宏配置实现编译对应应用需要的协议栈。另一个是 OTA 和静态协议栈的维度：OTA 和静态协议栈的选择流程图如下图所示

: o6 y8 H. O  k! P; A* }02BlueNRG-LP/BlueNRG-LPS的OTA
2.1 OTA 的框架
手机或者电脑做 GATT Client，给带 OTA 服务的设备升级。

, B7 f1 Z/ q; s' o
1 ^$ C, ?8 w% \, N5 y
2.2 官方提供的 OTA 方式
默认提供的 OTA 应用和协议栈编译在一个固件上。
a. 不带备份的(右图中的右半部分)
升级服务程序在 Boot 端(OTA Service manager)。
0 Q9 T) N( h" E省空间（存放了 2 份协议栈，1 份应用）
管理简单（只需管理一份应用）
, ?6 }' }( Y( tb. 带备份的(右图中的左半部分)
: J& v6 k% D# x. i8 z+ T. ?$ G; t6 u升级服务程序在应用端
更消耗空间（存放了 2 份协议栈，2 份应用）
1 P, N' ]/ @7 X! ]- w- {9 J管理稍微麻烦（需要管理两份应用，Lower 区域应用不能放置 Higher 区域运行）
, O# Q6 S9 {! M更安全
. W2 e3 B+ d, I$ r' x


. g# c* E# t' T6 V  C/ Qa. 不带备份的方式由以下组件构成：
BLE_OTA_ServiceManager+ application
. A6 ]; n6 w: db. 带备份的由以下组件构成：
BLE_OTA_ResetManager +Lower Application (with BLE OTA service) orBLE_OTA_ResetManager + Higher Application (with BLE OTA service)

对应在 SDK 中工程和配置如下图所示：
0 R3 h) }! b3 qa.BLE_OTA_ServiceManager 配合 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager
1 h! z" z7 s- [. d) N5 _$ o: t% n, [b.BLE_OTA_ResetManger 配合 BLE_SerialPort 中的 Service_LowerApp_OTA 或者Service_LowerApp_OTA 使用
8 i2 n' P) E) H# M' p" J

3 Y- m- x5 M4 @; F9 A" Z
2.3 使用带备份类型 OTA 升级错误变砖头问题
编译器编译的 Higher Application 如果放置在 Lower Application 的位置，程序无法运行。APP 程序可以知晓当前运行的固件是 Lower 还是 Higher APP。可以在编译固件 Higher Application 和 Lower Application 中加入一些标记，用于给升级工具识别，当前需要下载的是Higher Application 还是 Lower Application 或者是否混用。建议每次发布时两个应用程序都编译生成，不要人为来管理固件，否则容易造成混乱，应该让升级 app 自动选择对应的来升级。
# |$ ]+ g" \+ J  i0 T* Y
5 w9 P+ N& I# m, p( `& m
) T* P! S/ e7 n& G8 g

" R! \5 z4 z, |+ D  D4 W
& R, V: u) ~; A5 z- m7 x03BlueNRG-LP/LPS的存储分析
4 l7 y' q0 a9 i3.1 linker 中宏定义作用范围
Linker 中可定义一些宏、用于指定链接脚本文件所需的配置。这些宏定义不作用于.c文件或者.h文件，只作用于链接文件（.icf 或者.sct 或者 *.ld）。


3.2 链接脚本文件分析（代码区域）
; R) T) ~  A: @, B' @0 V1 N不同的 IDE 所使用的链接脚本文件的格式不同。比如，Keil 使用“*.sct”文件，IAR 使用“*.icf”文件，而 TrueStudio 使用 “*.ld”文件。
  D+ L, ?+ ?1 p4 q7 ]
下面分析BlueNRG-LP最新SDK中BLE_SerialPort项目IAR工程目录下的BlueNRG_LP.icf文件, 其他IDE一样，可以进行类比。由于Flash的擦除必须是整页操作的，写Flash之前必须将对应的页擦除，所以Flash的划分需要2KB对齐。就算只使用到0.9KB，也需要划分2KB区域。

' y7 R' c, u( q0 @, g' f默认SDK中提供了4种程序的链接配置:
1.CONFIG_OTA_HIGHER
4 x% ]2 h9 r2 i7 }' V' k0 O2.CONFIG_OTA_LOWER
3.CONFIG_OTA_USE_SERVICE_MANAGER
4.其他
8 g7 a8 B( S9 ^' I- m, d
" A. y7 X) r7 E9 s
, d, O& [) r" M* ?# T% n9 u" d
2 M6 c. Z$ w& Y2 P. l对于这四种链接配置编译后，代码区域放置在如下地址。BLE_OTA_ServiceManager 工程使用的是非 OTA 程序，而 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager 工程使用的是CONFIG_OTA_USE_SERVICE_MANAGER。
# ^# l* i& G  q' i  P$ V/ H- _


. r% I( \: B9 V% T( O" _上述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限制这个工程编译的程序空间大小不能超过这个范围。

# Z& K- D* v0 r$ v如果在linker中没有定义MEMORY_FLASH_APP_SIZE，则对应的4种配置分别是：

% N& J( [4 O' O, C' V! u$ c* R7 J$ o

MEMORY_FLASH_APP_OFFSET: 定义程序编译链接地址的偏移（非OTA程序）。如果在linker中没有定义MEMORY_FLASH_APP_OFFSET，则对应的4种配置分别是：

/ f' M: Y7 K, g6 n0 Y

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

  e" h$ I9 z4 u$ l
7 b5 z# O1 X: s9 x04通过协议栈的初步裁剪与自定义优化空间
SDK 中默认提供了 4 种默认配置的协议栈加一种自定义的协议栈配置（BLE_STACK_CUSTOM_CONF），如下图所示。

) P4 D# R+ q7 ?6 [

上述 5 种不同协议栈的配置，本质上就是通过使用宏控制不同的特性功能是否打开。只是前面 4种提供了默认便捷的设置，而最后一种可以进行细粒度更细的自定义的协议栈。

' K  H+ x! Y, U3 X可以在 Preprocesor Symbols 中定义相关的宏来配置使用哪种协议栈配置。
, r  `% [& |9 t$ B" o! P- z: U
) ^; \. B! D( W3 S, P/ ~$ X
; `& d( d) g2 W, z
( s. g  _8 \. R9 k& J$ i6 `! n如果选用细粒度更细的 BLE_STACK_CUSTOM_CONF 协议栈配置，则在 其中在头文件“custom_ble_stack_config.h”中开关不同功能特性，大致占用的代码如下图所示。

  U& ?8 q* y* c0 |1 x3 V+ Z
5 @% v% y! m( w( O  [" M
4 O1 V& \6 e; \; A% S) X9 I3 h3 {6 R$ [
) Z$ x  L& I( J05协议栈的进一步裁剪:使用静态协议栈
5.1 静态协议栈工程的 4 种默认的配置
" d. R6 l5 k/ {: nST 官方 SDK 中已经提供了静态协议栈的 Demo，分为协议栈工程和应用工程两部分，路径为：C:\Users\user name\ST\BlueNRG-LP DK 1.x.x\Projects\BLE_Examples\BLE_StaticStack 静态协议栈工程默认提供了 4 种配置：
• Release
• Basic
• OTA_BTL_ResetManager
: L  r9 I9 y* Q8 X+ v! n  K• OTA_BTL_ResetManager_Basic

C:\Users\user name\ST\BlueNRG-LP DK 1.x.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack
& m6 ^1 I* n0 q, r7 ?2 j* i6 I2 t• Release
• LowerApp_OTA
" z  J; z8 ?0 ]0 T& Q2 ~5 z- Z7 |• HigherApp_OTA


: n! z! h( \2 ]- n" ?: E2 [
那它们有什么区别呢？它们可以分为两组。

- w; t$ A* d- A' i3 {8 |5 o( gRelease 和 Basic 是一组：它们运行时都是由协议栈程序直接跳转到一个固定的应用上；
8 M1 c" L* \* K  }0 `
, @( y5 U) e+ e7 DRelease 和 Basic 的区别：Basic 的协议栈配置是 BLE_STACK_BASIC_CONF， 而 Release的协议栈配置是 BLE_STACK_FULL_CONF。
1 T. |, z4 j8 R8 @5 V$ p
% h( U6 q( {6 n' q# O7 L$ d不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。
• 不同的协议栈配置包含的功能请查看 stack_user_cfg.h
• 占用的 Flash 空间可以通过编译的 Map 文件查看• 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
% W6 R6 r# F) ^: @• Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。

0 o5 D3 C! }4 d; ]1 o; r' E' VOTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 是另外一组：它们都是由协议栈程序跳转到 Lower 应用程序或者 Higher 应用程序；
$ Z: n5 b3 H. q4 _1 ]5 a7 X
' s# S: }3 d5 {) @% d  q. q• OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 的区别：OTA_BTL_ResetManager_Basic 的协议栈配置是 BLE_STACK_BASIC_CONF， 而OTA_BTL_ResetManager 的协议栈配置是 BLE_STACK_FULL_CONF
9 U1 u& e  A; O
• 不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。
o 不同的协议栈配置包含的功能请查看 stack_user_cfg.h
  ]+ l. U6 H: ^3 h/ o9 v) Zo 占用的 Flash 空间可以通过编译的 Map 文件查看
( N" V8 c/ W& oo 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
/ I6 s7 Y0 ]- |- Y9 Eo Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
4 K" V* ?* C7 V" T
其中，一个工程负责生成协议栈，另一个工程负责应用，那么这里 BLE_StaticStack 中的Release or Basic 与 OTA_BTL_ResetManager or OTA_BTL_ResetManager_Basic 怎么和Release，LowerApp_OTA 和 HigherApp_OTA 组合呢？
% a5 a5 Q& `5 c: ^• 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 的使用固定协议栈的方法
+ k2 R: c+ g% Y0 B
5.2 将工程实例化为静态协议栈工程编程基础
6 |% k9 b2 d2 n: e" {& }% j9 m将工程实例化为静态协议栈涉及比较多的步骤，可以参考官方的文档 :BlueNRG-LP_LPS DK 1.2.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack\README.txt
7 R% J1 p/ L" u, o$ ^4 w2 c
8 Z& W" W6 I7 @, m1 X% ?) P1 m5 p以及 SDK 安装目录的 index.html 中的静态协议栈的介绍如下图所示。
0 z1 V! ?( b" g9 F* x5 j


0 M- }8 R+ y& X+ ~* W; D  O, O如果在实例化 OTA 程序时，可能需要修改链接脚本和 Preprocesor Symbols 中下面几个宏（具体不同应用，不同 OTA 类型，具体需要定义的宏和宏的数值也不同）：

RESET_MANAGER_SIZESERVICE_MANAGER_OFFSETSERVICE_MANAGER_SIZEMEMORY_FLASH_APP_SIZEMEMORY_RAM_APP_OFFSET
: K" w& K; {8 c4 X
# p3 U' E4 o, K/ ?& V' @0 M, I5.3 使用默认配置的协议栈
" V5 }+ y$ M5 E# h7 o- Z如果使用了 OTA，发现空间不够，可以考虑将应用协议栈和 OTA 协议栈合并使用如下图所示。
5 e3 T: j0 j9 @# Z$ T4 Q) a


7 ^, J. F; n5 h" E8 _$ J9 A上图列举的是基于 BlueNRG-LP 的默认提供的工程的大致数值（BlueNRG-LPS 类似，这里不再举例）。如果遇到不同的应用，可以实际裁剪协议栈适配不同的应用需求。

) j; R2 G) ^1 p3 {% ^  ^0 h3 W) m( Y5.4 使用自定义配置的协议栈
使用静态协议栈可以实现更为精确的函数级别的裁剪:通过注释协议栈工程中的 bluenrg_lp_cmd_if.c 中的 cmd_call_table 中对应的函数，编译时可以将不使用的协议栈函数裁减出协议栈。

9 N% a6 K; u/ {8 a

4 J) K+ G1 A- [( A# U/ _: R5 i5.5 使用静态协议栈这种模式如何支持升级协议栈
当使用静态协议栈，默认协议栈就无法升级。为了能够支持协议栈也升级。需要增加一段 boot代码，当升级协议栈时，先放置在 APP 区域，当升级完协议栈后，将 APP 区域的协议栈拷贝到协议栈区域。接着继续升级被擦除的应用程序。Boot 代码决定搬运协议栈和跳转到下一级。

, V. A, H) E& K
' C- K4 x* B1 W7 E* A: k: b
06优化后空间仍不足的其他方法
7 s* P% ^0 k( e( _% E如果使用静态协议栈和空间仍然不足，可以考虑将一些常用而不需修改的通用模块编译进协议栈的工程。如果空间仍然差距比较远则考虑用片外 Falsh 或者选用 STM32WB 系列，再或者使用 STM32+协处理器模式。
9 A* [/ i% S: Z3 F7 e

转载自：记帖
如有侵权请联系删除
: i9 D/ M1 a2 y& f* ?7 T2 h" m2 G
( {. v' r  ~0 n
: h/ w) P9 v- C- c% ~