01引言
1 k! ?" u0 d1 P客户在使用 BlueNRG-LP/LPS 芯片时，增加 OTA 服务后常常反馈说，编译代码区域超空间了，需要帮忙优化一下。后文主要通过下列步骤进行分析和优化 BlueNRG-LP/LPS 的代码空间：
a. 通过分析 BlueNRG-LP/LPS 的 OTA 方式，让客户可以选择合适的方式；
' G& X- R/ d+ q% sb. 通过整体分析 BlueNRG-LP/LPS 的链接文件（*.icf/*.sct/*.ld）了解默认工程的存储分布；
3 ]; V% S2 {8 I2 \( n4 [0 tc. 通过裁剪协议栈，选择合适的协议栈功能，优化 BlueNRG-LP/LPS 的代码空间；
d. 通过使用静态协议栈，进一步优化 BlueNRG-LP/LPS 的代码空间；
" a% R2 y% p8 T3 r* t0 ee. 其他方案；

) T* o$ g$ {' G/ V! D' C* s
0 H3 I4 }  v! a9 c8 O! [
总的来说通过两个维度来节省空间：一个是协议栈的裁剪维度：主要是通过修改宏配置实现编译对应应用需要的协议栈。另一个是 OTA 和静态协议栈的维度：OTA 和静态协议栈的选择流程图如下图所示
. d( f, D0 c$ W1 N
  ^& V, P: ]3 J# \, t9 p02BlueNRG-LP/BlueNRG-LPS的OTA
2.1 OTA 的框架
9 x* }. @6 U5 I( v& _手机或者电脑做 GATT Client，给带 OTA 服务的设备升级。



8 c; U0 v0 h9 Y1 _$ U  T# d2.2 官方提供的 OTA 方式
默认提供的 OTA 应用和协议栈编译在一个固件上。
a. 不带备份的(右图中的右半部分)
, P" I* ?1 [: f9 N) B升级服务程序在 Boot 端(OTA Service manager)。
3 F! Z6 k) ]" p/ f) L7 [' h: N省空间（存放了 2 份协议栈，1 份应用）
管理简单（只需管理一份应用）
& x  {; q1 j$ e4 s/ m6 ?+ R5 Hb. 带备份的(右图中的左半部分)
( P. L& l0 p0 n2 {% i& H6 o8 P升级服务程序在应用端
- p+ Z, ^+ h6 ]; c3 Z更消耗空间（存放了 2 份协议栈，2 份应用）
管理稍微麻烦（需要管理两份应用，Lower 区域应用不能放置 Higher 区域运行）
& }7 s5 b7 ^( |& O( U0 ]更安全



a. 不带备份的方式由以下组件构成：
* C* D! Q" I3 w3 d0 G8 bBLE_OTA_ServiceManager+ application
b. 带备份的由以下组件构成：
BLE_OTA_ResetManager +Lower Application (with BLE OTA service) orBLE_OTA_ResetManager + Higher Application (with BLE OTA service)

对应在 SDK 中工程和配置如下图所示：
7 I$ j* y+ b& Na.BLE_OTA_ServiceManager 配合 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager
! K, Y3 C2 A& F; f! tb.BLE_OTA_ResetManger 配合 BLE_SerialPort 中的 Service_LowerApp_OTA 或者Service_LowerApp_OTA 使用
2 M. i1 ^/ m6 O: ~$ ~$ s. i9 d
# b+ M& @2 C0 O

$ j5 X7 ^- B/ u& T2.3 使用带备份类型 OTA 升级错误变砖头问题
1 Y. c5 S; x& ?9 z) s! ?; n( a4 ~7 P: p编译器编译的 Higher Application 如果放置在 Lower Application 的位置，程序无法运行。APP 程序可以知晓当前运行的固件是 Lower 还是 Higher APP。可以在编译固件 Higher Application 和 Lower Application 中加入一些标记，用于给升级工具识别，当前需要下载的是Higher Application 还是 Lower Application 或者是否混用。建议每次发布时两个应用程序都编译生成，不要人为来管理固件，否则容易造成混乱，应该让升级 app 自动选择对应的来升级。
: k& P# Q1 ?( U& a


. g. w% Z3 Q6 T4 q" n/ D
- C# n" ]& w$ [9 G
9 i+ \) x4 s4 Q( y03BlueNRG-LP/LPS的存储分析
3 \) V4 t4 I/ i2 |* g5 r1 u! s; |3.1 linker 中宏定义作用范围
Linker 中可定义一些宏、用于指定链接脚本文件所需的配置。这些宏定义不作用于.c文件或者.h文件，只作用于链接文件（.icf 或者.sct 或者 *.ld）。
  [" \$ |6 d. U3 o0 O* I! Y$ U

3.2 链接脚本文件分析（代码区域）
7 W4 p5 V# K3 W& {- n不同的 IDE 所使用的链接脚本文件的格式不同。比如，Keil 使用“*.sct”文件，IAR 使用“*.icf”文件，而 TrueStudio 使用 “*.ld”文件。
' @2 k* l% ~  d1 C
下面分析BlueNRG-LP最新SDK中BLE_SerialPort项目IAR工程目录下的BlueNRG_LP.icf文件, 其他IDE一样，可以进行类比。由于Flash的擦除必须是整页操作的，写Flash之前必须将对应的页擦除，所以Flash的划分需要2KB对齐。就算只使用到0.9KB，也需要划分2KB区域。

默认SDK中提供了4种程序的链接配置:
1.CONFIG_OTA_HIGHER
) u( u" u' i) q4 h4 \9 q2.CONFIG_OTA_LOWER
2 t: w( O4 [- O+ L3.CONFIG_OTA_USE_SERVICE_MANAGER
4.其他


2 n7 |  A! C1 |* _  w  e" l
- g; _0 S/ ~/ K' n对于这四种链接配置编译后，代码区域放置在如下地址。BLE_OTA_ServiceManager 工程使用的是非 OTA 程序，而 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager 工程使用的是CONFIG_OTA_USE_SERVICE_MANAGER。
6 K; U8 b; F2 Q& J
& X. ^! t" ]& F; b' ^$ s

上述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限制这个工程编译的程序空间大小不能超过这个范围。
) I: L  q( I* i% t1 n0 ~
- W, @. B9 `5 h, O' ?8 ]如果在linker中没有定义MEMORY_FLASH_APP_SIZE，则对应的4种配置分别是：



MEMORY_FLASH_APP_OFFSET: 定义程序编译链接地址的偏移（非OTA程序）。如果在linker中没有定义MEMORY_FLASH_APP_OFFSET，则对应的4种配置分别是：
8 e2 r0 D8 f$ a! H$ C
- t$ L8 F4 s% z$ a
% G  `/ ~1 e. Y! |$ z* v
: s; t5 ^- W, f前面提到默认SDK中提供了4种程序的链接配置，本质上只是计算MEMORY_FLASH_APP_OFFSET和MEMORY_FLASH_APP_SIZE的方式不同而已，如果应用需要，也可以改动这个链接脚本文件。
" W# h) j' z  R* V
1 p" V4 m5 B5 n# o
04通过协议栈的初步裁剪与自定义优化空间
SDK 中默认提供了 4 种默认配置的协议栈加一种自定义的协议栈配置（BLE_STACK_CUSTOM_CONF），如下图所示。

) {& R. E& s# U9 Q8 A

上述 5 种不同协议栈的配置，本质上就是通过使用宏控制不同的特性功能是否打开。只是前面 4种提供了默认便捷的设置，而最后一种可以进行细粒度更细的自定义的协议栈。
% z( @  `5 Y6 e8 @3 `5 F
3 z' |5 n& G; ?2 Q: g可以在 Preprocesor Symbols 中定义相关的宏来配置使用哪种协议栈配置。


% _/ j5 n+ M! a( |$ S: j
, \- B3 y  Z8 S! i6 \如果选用细粒度更细的 BLE_STACK_CUSTOM_CONF 协议栈配置，则在 其中在头文件“custom_ble_stack_config.h”中开关不同功能特性，大致占用的代码如下图所示。



, k; l4 F$ r! _+ s6 R
6 m9 `7 Z" h/ ~0 M2 a  x' ?05协议栈的进一步裁剪:使用静态协议栈
5.1 静态协议栈工程的 4 种默认的配置
  g8 V( Q4 J. n& f( {ST 官方 SDK 中已经提供了静态协议栈的 Demo，分为协议栈工程和应用工程两部分，路径为：C:\Users\user name\ST\BlueNRG-LP DK 1.x.x\Projects\BLE_Examples\BLE_StaticStack 静态协议栈工程默认提供了 4 种配置：
, s. n; l, `2 w7 h8 S• Release
$ Y& ^  m# x( \1 A' ?& r5 z• Basic
! u+ x' g! ?8 w9 r! M0 O# _/ K• OTA_BTL_ResetManager
6 |" B. d6 L- c# D8 O" s  D" H• OTA_BTL_ResetManager_Basic
% h1 x- @1 i9 m! X
, Y: w1 j, M; m. g8 E% Q: jC:\Users\user name\ST\BlueNRG-LP DK 1.x.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack
" k4 Q) f. n( r• Release
" W- e( Q% Q* @1 d) L• LowerApp_OTA
• HigherApp_OTA
4 k9 v, a1 F* T9 G: U, L3 c  U2 ]; w; Z. u
4 x* ?0 m6 w( L0 _: d6 l% w

0 K+ N: C+ Q" U) Q2 `那它们有什么区别呢？它们可以分为两组。
% T- t( H# E. E* p2 [' e
+ m5 ]4 g- m2 F4 I; `Release 和 Basic 是一组：它们运行时都是由协议栈程序直接跳转到一个固定的应用上；
. p6 K. J% A% @* C
Release 和 Basic 的区别：Basic 的协议栈配置是 BLE_STACK_BASIC_CONF， 而 Release的协议栈配置是 BLE_STACK_FULL_CONF。
6 \+ b- c* g3 _+ i4 g, i
不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。
• 不同的协议栈配置包含的功能请查看 stack_user_cfg.h
• 占用的 Flash 空间可以通过编译的 Map 文件查看• 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
• Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。

OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 是另外一组：它们都是由协议栈程序跳转到 Lower 应用程序或者 Higher 应用程序；
6 D1 j5 N" A/ d& V3 `! \* ~" m; N
• OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 的区别：OTA_BTL_ResetManager_Basic 的协议栈配置是 BLE_STACK_BASIC_CONF， 而OTA_BTL_ResetManager 的协议栈配置是 BLE_STACK_FULL_CONF
& ~$ V3 a% p+ c8 Z: Q2 q
4 n& t4 L4 [  L& p8 c# Z! P; f• 不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。
o 不同的协议栈配置包含的功能请查看 stack_user_cfg.h
o 占用的 Flash 空间可以通过编译的 Map 文件查看
o 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
o Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
: G3 f# |) @2 z
其中，一个工程负责生成协议栈，另一个工程负责应用，那么这里 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 的使用固定协议栈的方法
$ V1 X$ y; ]' ~" F+ I+ H2 o* @
. c( {5 i% X8 l3 m5 t5.2 将工程实例化为静态协议栈工程编程基础
将工程实例化为静态协议栈涉及比较多的步骤，可以参考官方的文档 :BlueNRG-LP_LPS DK 1.2.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack\README.txt
) A! X6 F+ _& \6 @( B
( B. B' v, B% b0 u/ L. [2 r以及 SDK 安装目录的 index.html 中的静态协议栈的介绍如下图所示。
0 |; n5 e( S! H, _' `) s! a" f3 N
6 j2 C$ Z, ]6 a: _" j0 z0 D
2 R0 P  q' V1 x( T7 T1 T  u  O
如果在实例化 OTA 程序时，可能需要修改链接脚本和 Preprocesor Symbols 中下面几个宏（具体不同应用，不同 OTA 类型，具体需要定义的宏和宏的数值也不同）：
/ n4 y7 W8 l- @
1 ]8 c  l1 G& j5 }% jRESET_MANAGER_SIZESERVICE_MANAGER_OFFSETSERVICE_MANAGER_SIZEMEMORY_FLASH_APP_SIZEMEMORY_RAM_APP_OFFSET

5.3 使用默认配置的协议栈
如果使用了 OTA，发现空间不够，可以考虑将应用协议栈和 OTA 协议栈合并使用如下图所示。
0 ]5 f: T  x# U4 U& a8 F


上图列举的是基于 BlueNRG-LP 的默认提供的工程的大致数值（BlueNRG-LPS 类似，这里不再举例）。如果遇到不同的应用，可以实际裁剪协议栈适配不同的应用需求。

6 O- B) @" X4 K8 n0 `5.4 使用自定义配置的协议栈
使用静态协议栈可以实现更为精确的函数级别的裁剪:通过注释协议栈工程中的 bluenrg_lp_cmd_if.c 中的 cmd_call_table 中对应的函数，编译时可以将不使用的协议栈函数裁减出协议栈。


$ i" e: @; }$ N( K1 ~4 `
( @3 |( Z+ g: \/ T8 T+ X- Z' v5.5 使用静态协议栈这种模式如何支持升级协议栈
当使用静态协议栈，默认协议栈就无法升级。为了能够支持协议栈也升级。需要增加一段 boot代码，当升级协议栈时，先放置在 APP 区域，当升级完协议栈后，将 APP 区域的协议栈拷贝到协议栈区域。接着继续升级被擦除的应用程序。Boot 代码决定搬运协议栈和跳转到下一级。
: n4 {9 ?) _" @, A/ J' b- h. |; u

4 a8 M) D2 s+ {# w7 \
06优化后空间仍不足的其他方法
如果使用静态协议栈和空间仍然不足，可以考虑将一些常用而不需修改的通用模块编译进协议栈的工程。如果空间仍然差距比较远则考虑用片外 Falsh 或者选用 STM32WB 系列，再或者使用 STM32+协处理器模式。
$ j3 ^3 v6 B% n" j( z6 d

转载自：记帖
8 J$ s* S. P" _+ j, ]. O. v如有侵权请联系删除
) K- A$ s4 |0 G- ~+ R3 o
& h! G$ z1 \* \# {