01引言
$ T3 _* y; u( k$ t2 E客户在使用 BlueNRG-LP/LPS 芯片时，增加 OTA 服务后常常反馈说，编译代码区域超空间了，需要帮忙优化一下。后文主要通过下列步骤进行分析和优化 BlueNRG-LP/LPS 的代码空间：
5 }* \  N) ]* c' ^  X" w- R( R- Ga. 通过分析 BlueNRG-LP/LPS 的 OTA 方式，让客户可以选择合适的方式；
b. 通过整体分析 BlueNRG-LP/LPS 的链接文件（*.icf/*.sct/*.ld）了解默认工程的存储分布；
, r6 @. d6 p& v3 M6 d1 Q- h$ Nc. 通过裁剪协议栈，选择合适的协议栈功能，优化 BlueNRG-LP/LPS 的代码空间；
/ X, ?( s. C5 L  e8 Td. 通过使用静态协议栈，进一步优化 BlueNRG-LP/LPS 的代码空间；
e. 其他方案；
) F: Y. J* H3 m% G: _, V


总的来说通过两个维度来节省空间：一个是协议栈的裁剪维度：主要是通过修改宏配置实现编译对应应用需要的协议栈。另一个是 OTA 和静态协议栈的维度：OTA 和静态协议栈的选择流程图如下图所示

2 q) b3 O& z# h6 u6 z. S0 h02BlueNRG-LP/BlueNRG-LPS的OTA
2.1 OTA 的框架
/ a/ _0 @6 x* V( U7 N* V手机或者电脑做 GATT Client，给带 OTA 服务的设备升级。



2.2 官方提供的 OTA 方式
默认提供的 OTA 应用和协议栈编译在一个固件上。
a. 不带备份的(右图中的右半部分)
升级服务程序在 Boot 端(OTA Service manager)。
省空间（存放了 2 份协议栈，1 份应用）
管理简单（只需管理一份应用）
% N" g5 u) v' d8 @& hb. 带备份的(右图中的左半部分)
升级服务程序在应用端
; C6 c, |* B& [9 t: X, I1 T4 ?3 @更消耗空间（存放了 2 份协议栈，2 份应用）
; z9 C) s& i' H9 H  s" g- r管理稍微麻烦（需要管理两份应用，Lower 区域应用不能放置 Higher 区域运行）
5 ?. [# m5 q/ o' r2 w% M更安全
: c* y1 y, I. w: i
7 b, h" ]' ~& S  \$ T

a. 不带备份的方式由以下组件构成：
BLE_OTA_ServiceManager+ application
* A( G& i5 ]  [* f' D* Bb. 带备份的由以下组件构成：
) o4 w* M  _4 a! X) |& j. |) N* ]BLE_OTA_ResetManager +Lower Application (with BLE OTA service) orBLE_OTA_ResetManager + Higher Application (with BLE OTA service)

对应在 SDK 中工程和配置如下图所示：
6 a2 o& C7 k- ^9 o1 La.BLE_OTA_ServiceManager 配合 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager
b.BLE_OTA_ResetManger 配合 BLE_SerialPort 中的 Service_LowerApp_OTA 或者Service_LowerApp_OTA 使用



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





: T) K& `2 U: S03BlueNRG-LP/LPS的存储分析
3.1 linker 中宏定义作用范围
) M5 d: G0 o' A& S1 `/ F* wLinker 中可定义一些宏、用于指定链接脚本文件所需的配置。这些宏定义不作用于.c文件或者.h文件，只作用于链接文件（.icf 或者.sct 或者 *.ld）。

  I' U! a% X# o) w" _- M, P' N
3.2 链接脚本文件分析（代码区域）
4 g0 a; u' [8 P. p  `( H. ^不同的 IDE 所使用的链接脚本文件的格式不同。比如，Keil 使用“*.sct”文件，IAR 使用“*.icf”文件，而 TrueStudio 使用 “*.ld”文件。

; B% Q& _  r6 h; z下面分析BlueNRG-LP最新SDK中BLE_SerialPort项目IAR工程目录下的BlueNRG_LP.icf文件, 其他IDE一样，可以进行类比。由于Flash的擦除必须是整页操作的，写Flash之前必须将对应的页擦除，所以Flash的划分需要2KB对齐。就算只使用到0.9KB，也需要划分2KB区域。
% [+ y. E' w9 Z8 c* N5 ~
) D7 K$ Y: w4 K默认SDK中提供了4种程序的链接配置:
1.CONFIG_OTA_HIGHER
2.CONFIG_OTA_LOWER
6 k. o$ e" w* G! [: ~, U! p3.CONFIG_OTA_USE_SERVICE_MANAGER
2 u8 y+ z8 N3 w, e0 N2 M4.其他
4 P6 v( F" I7 e! Y2 @

3 J' z% e6 U+ D7 h! `7 O0 u
; P& N5 L2 e' `对于这四种链接配置编译后，代码区域放置在如下地址。BLE_OTA_ServiceManager 工程使用的是非 OTA 程序，而 BLE_SerialPort 中的 Sever_Use_OTA_serviceManager 工程使用的是CONFIG_OTA_USE_SERVICE_MANAGER。
% V" E$ Z! R8 r/ k0 g, M& ~- o  ]! S
* U+ x7 G) N9 D% k6 ?, H
+ M6 ?, D( U7 h3 W8 O8 b, R, d% y* r
1 T  C1 g) m: I4 x) T上述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限制这个工程编译的程序空间大小不能超过这个范围。

9 ~* y; e, M, s; s如果在linker中没有定义MEMORY_FLASH_APP_SIZE，则对应的4种配置分别是：
) G( M. E7 _  \5 b
2 q' t$ D, ]1 Y) H

MEMORY_FLASH_APP_OFFSET: 定义程序编译链接地址的偏移（非OTA程序）。如果在linker中没有定义MEMORY_FLASH_APP_OFFSET，则对应的4种配置分别是：
+ X- T+ G; W# D- r. t  L! C# e

3 u8 K7 }2 z* @% K9 ]5 W1 A
& t$ }" l2 M. b8 _+ f7 k前面提到默认SDK中提供了4种程序的链接配置，本质上只是计算MEMORY_FLASH_APP_OFFSET和MEMORY_FLASH_APP_SIZE的方式不同而已，如果应用需要，也可以改动这个链接脚本文件。
* T! j# f! k2 ]" V" f2 J4 ]  N
* i/ |% t2 M0 |! W. \
04通过协议栈的初步裁剪与自定义优化空间
5 w1 v/ M# ?/ K; {0 wSDK 中默认提供了 4 种默认配置的协议栈加一种自定义的协议栈配置（BLE_STACK_CUSTOM_CONF），如下图所示。
3 V. y8 o- r( z/ n0 y5 T% \7 v1 K0 _
7 v! a& q* _+ ~1 ^+ U
: @5 O3 c) l4 o8 W9 X3 |) k  V  f
上述 5 种不同协议栈的配置，本质上就是通过使用宏控制不同的特性功能是否打开。只是前面 4种提供了默认便捷的设置，而最后一种可以进行细粒度更细的自定义的协议栈。

% u8 z$ K( \. _) l( |! T( m可以在 Preprocesor Symbols 中定义相关的宏来配置使用哪种协议栈配置。



6 ]& D* J3 e2 j, I- Q2 I. t2 B如果选用细粒度更细的 BLE_STACK_CUSTOM_CONF 协议栈配置，则在 其中在头文件“custom_ble_stack_config.h”中开关不同功能特性，大致占用的代码如下图所示。
: ^( F: z& C! j# f8 g6 N6 F- V



05协议栈的进一步裁剪:使用静态协议栈
# S4 f% @8 y, E+ y, R: _8 B, Q5.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

! d# V( f1 K' l# e! e- VC:\Users\user name\ST\BlueNRG-LP DK 1.x.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack
% A9 F5 R8 q, C• Release
• LowerApp_OTA
• HigherApp_OTA
: Y) U* V. j4 k+ ?3 R* q
0 W& ?$ J: O( ^
+ v- h$ k+ X6 `$ T1 G. `3 X! t0 m
+ `6 X* \  N3 R% W那它们有什么区别呢？它们可以分为两组。

. N& {5 ]* p& `3 IRelease 和 Basic 是一组：它们运行时都是由协议栈程序直接跳转到一个固定的应用上；

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

不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。
; a: o5 m' u5 q6 x7 t) [4 ~. R• 不同的协议栈配置包含的功能请查看 stack_user_cfg.h
& ?( w5 c- i2 b/ ]4 _+ l• 占用的 Flash 空间可以通过编译的 Map 文件查看• 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
4 x/ k- K0 A5 A" o5 |• Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。

OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 是另外一组：它们都是由协议栈程序跳转到 Lower 应用程序或者 Higher 应用程序；

* R7 {( }" d$ l% z3 c• OTA_BTL_ResetManager 和 OTA_BTL_ResetManager_Basic 的区别：OTA_BTL_ResetManager_Basic 的协议栈配置是 BLE_STACK_BASIC_CONF， 而OTA_BTL_ResetManager 的协议栈配置是 BLE_STACK_FULL_CONF
3 z+ A  u' M) a' F$ S
/ U4 \7 }: N5 v• 不同的协议栈配置，包含的功能和占用的 Flash 空间也不一致。
; n" P/ t( m3 N- c2 B5 xo 不同的协议栈配置包含的功能请查看 stack_user_cfg.h
o 占用的 Flash 空间可以通过编译的 Map 文件查看
" F( r& |2 A$ y8 _$ Bo 宏 RESET_MANAGER_SIZE 用于协议栈程序的跳转偏移，即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。
: X  ^( ]3 S2 B" E$ }3 K' Ro Linker 中宏 MEMORY_FLASH_APP_SIZE 用于定义程序可用的大小。即预留多少空间给协议栈，因此这个宏的大小也会因为协议栈占用的空间不同而不同。

& d: ]% S% E+ z: j( [3 z8 ?其中，一个工程负责生成协议栈，另一个工程负责应用，那么这里 BLE_StaticStack 中的Release or Basic 与 OTA_BTL_ResetManager or OTA_BTL_ResetManager_Basic 怎么和Release，LowerApp_OTA 和 HigherApp_OTA 组合呢？
7 W7 U3 G1 k4 H' w' ]• 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 的使用固定协议栈的方法

6 @) b. J0 Y2 ?! x* o5.2 将工程实例化为静态协议栈工程编程基础
: \5 L; w7 N" }, _+ n+ c将工程实例化为静态协议栈涉及比较多的步骤，可以参考官方的文档 :BlueNRG-LP_LPS DK 1.2.0\Projects\BLE_Examples\BLE_SensorDemo_StaticStack\README.txt
# i# F6 a8 F- n" }5 n( }" N  g; ]
以及 SDK 安装目录的 index.html 中的静态协议栈的介绍如下图所示。
6 O( q0 {' T) f6 q2 \4 a  r2 [/ c

6 I% G& Z$ f8 w. l2 _
% [) V% R4 S% }  @: A如果在实例化 OTA 程序时，可能需要修改链接脚本和 Preprocesor Symbols 中下面几个宏（具体不同应用，不同 OTA 类型，具体需要定义的宏和宏的数值也不同）：

RESET_MANAGER_SIZESERVICE_MANAGER_OFFSETSERVICE_MANAGER_SIZEMEMORY_FLASH_APP_SIZEMEMORY_RAM_APP_OFFSET
, c0 `, X/ \& G/ C
5.3 使用默认配置的协议栈
如果使用了 OTA，发现空间不够，可以考虑将应用协议栈和 OTA 协议栈合并使用如下图所示。

; I3 R0 Q6 s3 v4 u8 x. N* B
9 u: x0 _, I1 p' i8 Z
8 P' S6 e( Z8 X/ h+ S1 x3 e上图列举的是基于 BlueNRG-LP 的默认提供的工程的大致数值（BlueNRG-LPS 类似，这里不再举例）。如果遇到不同的应用，可以实际裁剪协议栈适配不同的应用需求。
- m$ D7 b8 Z! T  B  i4 d4 Q! P& N- o
5.4 使用自定义配置的协议栈
使用静态协议栈可以实现更为精确的函数级别的裁剪:通过注释协议栈工程中的 bluenrg_lp_cmd_if.c 中的 cmd_call_table 中对应的函数，编译时可以将不使用的协议栈函数裁减出协议栈。
( y. K, V1 }4 A/ @; ^
8 G6 M7 H% U1 `
* F  h$ J( [& R  s  g7 ^
5.5 使用静态协议栈这种模式如何支持升级协议栈
当使用静态协议栈，默认协议栈就无法升级。为了能够支持协议栈也升级。需要增加一段 boot代码，当升级协议栈时，先放置在 APP 区域，当升级完协议栈后，将 APP 区域的协议栈拷贝到协议栈区域。接着继续升级被擦除的应用程序。Boot 代码决定搬运协议栈和跳转到下一级。
! n- H% A# L5 `, C, L


06优化后空间仍不足的其他方法
+ ^6 h; w" j" L) o3 C$ ]4 e. d如果使用静态协议栈和空间仍然不足，可以考虑将一些常用而不需修改的通用模块编译进协议栈的工程。如果空间仍然差距比较远则考虑用片外 Falsh 或者选用 STM32WB 系列，再或者使用 STM32+协处理器模式。
, N# a* j; r" ]: K7 i+ r: ^% I4 B

9 C9 }/ V/ p# @& l; R3 y转载自：记帖
( v2 a6 V, G( Q+ x- @如有侵权请联系删除
0 r6 Q) {% x: U$ \# j7 l3 Y

( N* y; c' R1 d" \; u
( W5 l" S( B0 ]/ X