01引言
客户在使用 BlueNRG-LP/LPS 芯片时，增加 OTA 服务后常常反馈说，编译代码区域超空间了，需要帮忙优化一下。后文主要通过下列步骤进行分析和优化 BlueNRG-LP/LPS 的代码空间：
% i1 ]- `. P  |0 ka. 通过分析 BlueNRG-LP/LPS 的 OTA 方式，让客户可以选择合适的方式；
b. 通过整体分析 BlueNRG-LP/LPS 的链接文件（*.icf/*.sct/*.ld）了解默认工程的存储分布；
! s- n  e4 G! z1 `6 f4 Wc. 通过裁剪协议栈，选择合适的协议栈功能，优化 BlueNRG-LP/LPS 的代码空间；
d. 通过使用静态协议栈，进一步优化 BlueNRG-LP/LPS 的代码空间；
4 B/ O' v+ N/ W. P. z" Z2 De. 其他方案；



总的来说通过两个维度来节省空间：一个是协议栈的裁剪维度：主要是通过修改宏配置实现编译对应应用需要的协议栈。另一个是 OTA 和静态协议栈的维度：OTA 和静态协议栈的选择流程图如下图所示
: p- r+ J6 R: L; w
02BlueNRG-LP/BlueNRG-LPS的OTA
9 i2 x6 K6 ]9 h/ h! K3 ^2.1 OTA 的框架
* D- z  E" z+ V手机或者电脑做 GATT Client，给带 OTA 服务的设备升级。
8 a: Y1 t$ N; g. ^2 D

: g+ J. J2 _3 h; o8 _) `9 ]
( [, Z) j( i. _( v. U2.2 官方提供的 OTA 方式
默认提供的 OTA 应用和协议栈编译在一个固件上。
6 `4 Y) O& n$ E0 b# B; ?7 ea. 不带备份的(右图中的右半部分)
升级服务程序在 Boot 端(OTA Service manager)。
省空间（存放了 2 份协议栈，1 份应用）
管理简单（只需管理一份应用）
b. 带备份的(右图中的左半部分)
升级服务程序在应用端
更消耗空间（存放了 2 份协议栈，2 份应用）
管理稍微麻烦（需要管理两份应用，Lower 区域应用不能放置 Higher 区域运行）
更安全
- W# }( \- q( Z9 W' J

3 k1 v# n" U/ t8 b
a. 不带备份的方式由以下组件构成：
0 @. E% U( g" o, NBLE_OTA_ServiceManager+ application
. T, \6 `8 B2 A. n# q! |b. 带备份的由以下组件构成：
9 E$ e" H* d' g7 cBLE_OTA_ResetManager +Lower Application (with BLE OTA service) orBLE_OTA_ResetManager + Higher Application (with BLE OTA service)
( ]" D: a+ s  |2 X( O
/ I6 x* u8 t6 x: Z对应在 SDK 中工程和配置如下图所示：
a.BLE_OTA_ServiceManager 配合 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager
7 H1 ]/ F& A+ K2 yb.BLE_OTA_ResetManger 配合 BLE_SerialPort 中的 Service_LowerApp_OTA 或者Service_LowerApp_OTA 使用
5 C, M& _! G7 m) x( f


2.3 使用带备份类型 OTA 升级错误变砖头问题
编译器编译的 Higher Application 如果放置在 Lower Application 的位置，程序无法运行。APP 程序可以知晓当前运行的固件是 Lower 还是 Higher APP。可以在编译固件 Higher Application 和 Lower Application 中加入一些标记，用于给升级工具识别，当前需要下载的是Higher Application 还是 Lower Application 或者是否混用。建议每次发布时两个应用程序都编译生成，不要人为来管理固件，否则容易造成混乱，应该让升级 app 自动选择对应的来升级。



% x2 \. ^; y; R2 z: ^
/ ~+ Q0 ]4 S% _0 V" f. F
03BlueNRG-LP/LPS的存储分析
  j" E% T6 f, y& ?2 U3.1 linker 中宏定义作用范围
: y% x2 r* b4 V! L& ~Linker 中可定义一些宏、用于指定链接脚本文件所需的配置。这些宏定义不作用于.c文件或者.h文件，只作用于链接文件（.icf 或者.sct 或者 *.ld）。
: N' d% B  |. K+ k

6 h% X3 a" g! n2 e: @% B3.2 链接脚本文件分析（代码区域）
不同的 IDE 所使用的链接脚本文件的格式不同。比如，Keil 使用“*.sct”文件，IAR 使用“*.icf”文件，而 TrueStudio 使用 “*.ld”文件。
6 P2 U6 X7 b- ^8 o% w
下面分析BlueNRG-LP最新SDK中BLE_SerialPort项目IAR工程目录下的BlueNRG_LP.icf文件, 其他IDE一样，可以进行类比。由于Flash的擦除必须是整页操作的，写Flash之前必须将对应的页擦除，所以Flash的划分需要2KB对齐。就算只使用到0.9KB，也需要划分2KB区域。

默认SDK中提供了4种程序的链接配置:
1.CONFIG_OTA_HIGHER
2.CONFIG_OTA_LOWER
& p2 {; P; r+ ^+ }( X3.CONFIG_OTA_USE_SERVICE_MANAGER
5 y5 J, C. h& h, d& U4.其他
  Y+ U) x/ @7 }+ I) F! G
3 ~, G2 U3 C1 X- }: u) n

对于这四种链接配置编译后，代码区域放置在如下地址。BLE_OTA_ServiceManager 工程使用的是非 OTA 程序，而 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager 工程使用的是CONFIG_OTA_USE_SERVICE_MANAGER。
, v7 K+ j* p* e" p2 U2 e
0 B6 \6 b$ r! C( A4 w
9 V, B6 _+ I* H* l0 s' v- }* m
( h, Q' n, ]+ D( N. W& M! A* e上述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限制这个工程编译的程序空间大小不能超过这个范围。
% |" Q! w: K& v) T
如果在linker中没有定义MEMORY_FLASH_APP_SIZE，则对应的4种配置分别是：

9 v% \2 m9 w% B; Q8 T
9 [8 E, o3 [! x4 h+ B2 O- b
2 h/ J6 o0 U4 t7 y' u0 uMEMORY_FLASH_APP_OFFSET: 定义程序编译链接地址的偏移（非OTA程序）。如果在linker中没有定义MEMORY_FLASH_APP_OFFSET，则对应的4种配置分别是：
# _! _$ p' C5 ~

: C: D* n1 \* F1 L; h$ q
! _, k7 [. z7 {& J前面提到默认SDK中提供了4种程序的链接配置，本质上只是计算MEMORY_FLASH_APP_OFFSET和MEMORY_FLASH_APP_SIZE的方式不同而已，如果应用需要，也可以改动这个链接脚本文件。

; A  R9 P6 U1 J  C, v
& x+ V/ X, }5 n# W04通过协议栈的初步裁剪与自定义优化空间
$ E& j3 A# B4 z" a2 _! [; N+ j5 ~SDK 中默认提供了 4 种默认配置的协议栈加一种自定义的协议栈配置（BLE_STACK_CUSTOM_CONF），如下图所示。
5 d7 a8 u/ ~' [) \3 I

% i3 H8 n" o6 l
上述 5 种不同协议栈的配置，本质上就是通过使用宏控制不同的特性功能是否打开。只是前面 4种提供了默认便捷的设置，而最后一种可以进行细粒度更细的自定义的协议栈。
+ ?" u9 H9 O2 o; j! C
' u6 a0 Y, y0 m4 s可以在 Preprocesor Symbols 中定义相关的宏来配置使用哪种协议栈配置。
+ s* M: o- c2 m5 \9 J. j; m


$ L' F1 C- R4 ]5 \. J( Q4 A1 A; C如果选用细粒度更细的 BLE_STACK_CUSTOM_CONF 协议栈配置，则在 其中在头文件“custom_ble_stack_config.h”中开关不同功能特性，大致占用的代码如下图所示。
$ }. I) u' P$ U  l7 Y! O

( p8 T+ A9 x& Q  _8 |0 R& J! C; X' u

1 _4 f" k: h% @4 s' R9 z% T05协议栈的进一步裁剪:使用静态协议栈
' ~( `& t: \8 i& {1 `7 P8 }5.1 静态协议栈工程的 4 种默认的配置
ST 官方 SDK 中已经提供了静态协议栈的 Demo，分为协议栈工程和应用工程两部分，路径为：C:\Users\user name\ST\BlueNRG-LP DK 1.x.x\Projects\BLE_Examples\BLE_StaticStack 静态协议栈工程默认提供了 4 种配置：
• Release
( m% w$ D1 o9 i) v; x• Basic
2 q# {  L/ a6 k/ X5 m6 `& A• OTA_BTL_ResetManager
• OTA_BTL_ResetManager_Basic
+ o, O8 c8 |3 Q3 e& H5 C
3 a  B* e$ V8 N4 U& f( AC:\Users\user name\ST\BlueNRG-LP DK 1.x.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack
• Release
9 S, _* E) `) n8 ]0 o6 z  a' i• LowerApp_OTA
• HigherApp_OTA


9 V% ~1 S7 }& K$ J" V0 E
那它们有什么区别呢？它们可以分为两组。

1 ^  I- B4 W; I1 z& H; m1 QRelease 和 Basic 是一组：它们运行时都是由协议栈程序直接跳转到一个固定的应用上；

( `& j8 i' J* U; T) kRelease 和 Basic 的区别：Basic 的协议栈配置是 BLE_STACK_BASIC_CONF， 而 Release的协议栈配置是 BLE_STACK_FULL_CONF。
( q. o" v4 j/ X
不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。
+ `- {' i7 o( k6 z; J• 不同的协议栈配置包含的功能请查看 stack_user_cfg.h
• 占用的 Flash 空间可以通过编译的 Map 文件查看• 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
* y3 Z1 C) l. H$ q9 r7 W4 a# n• Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
6 y* T3 ]% U# g: I- A0 ^$ O
2 `( t) C' X, \( v$ V2 i0 cOTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 是另外一组：它们都是由协议栈程序跳转到 Lower 应用程序或者 Higher 应用程序；

9 a) d6 i6 x% f$ F• OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 的区别：OTA_BTL_ResetManager_Basic 的协议栈配置是 BLE_STACK_BASIC_CONF， 而OTA_BTL_ResetManager 的协议栈配置是 BLE_STACK_FULL_CONF
7 I5 p! m4 T5 R  e+ J/ E& J
• 不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。
o 不同的协议栈配置包含的功能请查看 stack_user_cfg.h
" h$ V1 f1 i+ Fo 占用的 Flash 空间可以通过编译的 Map 文件查看
. I$ a8 y% n2 c+ c  c1 zo 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
o Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
& [4 u/ v3 E. a! r- m) C- ~
5 D3 ^/ j# V$ a2 K5 w% `+ W其中，一个工程负责生成协议栈，另一个工程负责应用，那么这里 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 的使用固定协议栈的方法
* R$ D4 j+ z2 }) ^, s
5.2 将工程实例化为静态协议栈工程编程基础
: R- j6 F$ b/ P. q$ P6 B3 K  [将工程实例化为静态协议栈涉及比较多的步骤，可以参考官方的文档 :BlueNRG-LP_LPS DK 1.2.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack\README.txt
9 W) t5 \" @: V6 v
( g- W9 h6 m0 d& F, ^' f以及 SDK 安装目录的 index.html 中的静态协议栈的介绍如下图所示。
- \! o$ t3 M+ M- Q


如果在实例化 OTA 程序时，可能需要修改链接脚本和 Preprocesor Symbols 中下面几个宏（具体不同应用，不同 OTA 类型，具体需要定义的宏和宏的数值也不同）：

RESET_MANAGER_SIZESERVICE_MANAGER_OFFSETSERVICE_MANAGER_SIZEMEMORY_FLASH_APP_SIZEMEMORY_RAM_APP_OFFSET

' T5 u# N  ]; J, Q( R2 g! n& @5.3 使用默认配置的协议栈
! K; d# z& L  T* w+ y9 y如果使用了 OTA，发现空间不够，可以考虑将应用协议栈和 OTA 协议栈合并使用如下图所示。
4 d# G4 @3 t6 X& V! `7 M
& F4 y  L& R5 E
0 f% ?" d: i- _6 t2 C
; w+ g5 g" ~% |7 h  `7 L1 B6 {6 j0 w上图列举的是基于 BlueNRG-LP 的默认提供的工程的大致数值（BlueNRG-LPS 类似，这里不再举例）。如果遇到不同的应用，可以实际裁剪协议栈适配不同的应用需求。

1 t) b2 t) k5 _/ w5.4 使用自定义配置的协议栈
使用静态协议栈可以实现更为精确的函数级别的裁剪:通过注释协议栈工程中的 bluenrg_lp_cmd_if.c 中的 cmd_call_table 中对应的函数，编译时可以将不使用的协议栈函数裁减出协议栈。

6 x" c7 e9 S; Z' N

5.5 使用静态协议栈这种模式如何支持升级协议栈
当使用静态协议栈，默认协议栈就无法升级。为了能够支持协议栈也升级。需要增加一段 boot代码，当升级协议栈时，先放置在 APP 区域，当升级完协议栈后，将 APP 区域的协议栈拷贝到协议栈区域。接着继续升级被擦除的应用程序。Boot 代码决定搬运协议栈和跳转到下一级。
# F* @9 s1 N$ ?1 C! n# I
8 o4 `2 g( e; g" t+ d4 v

06优化后空间仍不足的其他方法
8 P6 ]. `* }* X2 O如果使用静态协议栈和空间仍然不足，可以考虑将一些常用而不需修改的通用模块编译进协议栈的工程。如果空间仍然差距比较远则考虑用片外 Falsh 或者选用 STM32WB 系列，再或者使用 STM32+协处理器模式。

( ~* {* D: L9 [- S
转载自：记帖
- }" I, i3 I+ `! N0 U. D3 [. d如有侵权请联系删除

# k3 G' T) @. T. L0 h, c3 i

1 G; I2 s! B2 C! e; _/ w