BLE的OTA可以用来更新固件程序。本文以BlueNRG-1芯片为例，分析OTA实现方案细节。
1. 架构
一个OTA方案至少包括三个部分：
| 程序类型 |
描述 |
| 当前用户程序 |
当前正在运行的固件程序 |
| 新版用户程序 |
接收的更新后的固件程序 |
| 引导程序 |
芯片上电先进入引导程序，再跳转到新版程序运行 |
BlueNRG-1对160kB的内部Flash进行了逻辑分区，分别存放这三个部分程序：
这颗芯片的Flash地址区间为0x10040000 – 0x10068000，共160kB。上图中，最下面的Bootloader为引导程序，随后是两个程序空间，NVM中存放一些关键信息，最后一部分为预留空间，不使用。
APP_A和APP_B地位平等，如果当前程序在APP_A处，则将新版程序写入APP_B，反之亦然。
图中标注了各部分空间的大小，APP_A和APP_B的空间数值是根据总空间160kB减去其他几部分空间再除以2得到的。由此可知，用户更新的程序Flash大小应小于76kB。
芯片复位时直接进入引导程序，引导程序检测当前程序的位置，然后跳转至相应的程序空间。
2. 协议
在对BLE设备执行OTA升级过程，需要约定双方的行为规范。
2.1 从机GATT服务
OTA行为需要在一个专有的GATT服务上进行。该服务的GATT结构如下：
- OTA Service
- Current Image Char [Read]
- New Image Info Char [Write | Read]
- New Image Data Char [Write_Without_Response]
- Expected Data Block Sequence Number Char [Notify]
该服务共四个特征项。
第一个特征项，用于主机读取从机的有效Flash空间地址和边界。
第二个特征项，用于主机向从机写入新版程序二进制文件的基地址和大小。
第三个特征项，用于主机向从机分块写入新版程序二进制文件的内容，每块共19个字节，包括16个字节文件数据，1字节校验信息，2字节块序号（Block Sequence）。
第四个特征项，用于从机向主机发送期望的块序号，配合第三个特征项，实现一个简单的流程控制功能，以保证二进制文件传输的完整性。
2.2 从机广播数据
可以在从机的广播包中加入特殊字段，以方便主机快速识别从机。
在从机的广播包中，加入Device Name内容。
在从机的扫描响应包中，加入OTA Service UUID内容。
2.3 时序
基本时序如下所示：
3. 引导程序
引导程序完成两个任务：
在程序的Flash空间基地址，存放的是中断向量表，向量表的第一个元素为_INITIAL_SP，其内容为栈顶的地址，即MSP指针；第二个元素为复位处理函数（Reset_Handler），执行该句柄将执行程序初始化操作并跳转进入C代码的main函数。
所以，引导程序需要做的是检测到当前程序的中断向量表，并执行它的复位处理函数。
中断向量表在程序空间的位置如下图所示：
中断向量表的第五个元素OTA_APP_TAG是自定义的中断向量，它并不响应任何中断，仅仅记录当前程序空间的有效性。
OTA更新成功时，会将新版程序的OTA_APP_TAG设为0xAA5555AA，旧版程序的OTA_APP_TAG设为0x00000000。
引导程序检测两块Flash空间的OTA_APP_TAG值，如果检测到有效值，则设置该空间的程序为有效程序，并擦除旧程序。检测程序伪代码如下：
#define TAG_VALUE(addr) (* ((volatile uint32_t*) ((addr) + OTA_TAG_VECTOR_TABLE_ENTRY_OFFSET)))
if ((TAG_VALUE(APP_A_ADDRESS) == 0xAA5555AA) && (TAG_VALUE(APP_B_ADDRESS) == 0x00000000)) {
// 1. Set APP_A Availability
// 2. Erase APP_B Flash
}
else {
// 1. Set APP_B Availability
// 2. Erase APP_A Flash
}
执行复位处理函数通常在芯片复位时自动执行，然后再进入main函数。由于现在是手动引导用户程序，所以也需要手动执行复位处理函数。
基本思路是：（1）将中断向量表的第一个元素所指向的内容赋给MSP。（2）将中断向量表的第二个元素所指向的内容转换成函数并执行。
其代码如下：
/* 设置MSP */
__set_MSP(*(__IO uint32_t*) appAddress);
/* 执行Reset_Handler */
uint32_t JumpAddress = *(__IO uint32_t*) (appAddress + 4);
pFunction Jump_To_Application = (pFunction) JumpAddress;
Jump_To_Application();
代码中的appAddress表示检测到的当前程序空间的Flash基地址，所以appAddress指向_INITIAL_SP， (appAddress + 4)指向OTA_APP_TAG元素。
4. 用户程序存储位置
用户程序准备好以后，需要先烧录引导程序，再烧录用户程序。用户程序可能放在APP_A空间，也可能放在APP_B空间，而且不能覆盖引导程序。
需要利用链接文件（*.icf）控制程序在Flash上的存放位置。
打开程序的链接文件（BlueNRG1.icf），发现里面的内容十分复杂，一眼望不到头。下面挑出重要的代码，挖掘程序保存在Flash指定位置的思路。以APP_A程序为例：
define symbol _MEMORY_FLASH_BEGIN_ = 0x10040000;
define symbol RESET_MANAGER_SIZE = 0x800; /* 2KB */
define symbol MEMORY_FLASH_APP_SIZE = 0x13000; /* 76KB */
define symbol _MEMORY_FLASH_OFFSET_ = RESET_MANAGER_SIZE;
define region REGION_FLASH = mem:[from _MEMORY_FLASH_BEGIN_ + _MEMORY_FLASH_OFFSET_
to _MEMORY_FLASH_BEGIN_ + _MEMORY_FLASH_OFFSET_ + MEMORY_FLASH_APP_SIZE - 1];
place at start of REGION_FLASH { readonly section .intvec };
第一行，定义了当前内存的开始地址，这个地址是芯片规定的Flash起始地址。
第二行，定义了引导程序的大小，代码中引导程序用“Reset Manager”表示。
第三行，定义了用户程序的大小，为76KB。
第四行，定义了用户程序相对于Flash起始地址的偏移量。对于APP_A而言，该偏移量为引导程序的大小（RESET_MANAGER_SIZE），对于APP_B而言，该偏移量为引导程序的大小加上APP_A的大小（RESET_MANAGER_SIZE + MEMORY_FLASH_APP_SIZE）。
第五行，定义了REGION_FLASH区域，这块区域就是当前用户程序的Flash区域。
最后一行，表示所有的readonly数据、.intvec段都放在REGION_FLASH区域的开头，翻译过来就是中断向量表放在REGION_FLASH的起始位置。这一行就决定了烧录工程二进制文件时，从REGION_FLASH的开头处开始烧写。
对于APP_B程序，只需要将第四行做如下更改即可：
define symbol _MEMORY_FLASH_OFFSET_ = RESET_MANAGER_SIZE + MEMORY_FLASH_APP_SIZE
5. 实现协议
系统提供了OTA_btl.c/OTA_btl.h两个文件，将所有的操作都打包成了API，这里分析其实现思路。
5.1 添加GATT服务
OTA Service的UUID、特征项、特性都已经定义好，所以可以封装成无参函数，在初始化BLE的GATT时候多添加这个服务项即可。
5.2 特征项
Current Image Char特征项需要准备当前设备空闲的程序空间供主机读取，由于这些数据是静态数据，所以在构建GATT服务时即可完成。
有三个特征项需要接收主机的Write数据，在回调函数中需要分别处理。
对于New Image Info Char特征项，接收的数据中包括新程序文件的大小和基地址。
对于New Image Data Char特征项，接收的数据位新程序文件的数据块，还附带校验信息和块序号。如果校验和块序号均有效，则立即写入Flash。同时统计总的数据长度，如果等于前面接收的程序文件的大小，说明传输完毕，则设置两个程序空间的标志位。
对于Expected Data Block Sequence Number Char特征项，写入一个数据块后会发送一个Notification给主机，告知下一个期望的块序号。
5.3 设置标志位
设置标志位时候只需要利用用户程序空间基地址，加上合适的偏移量，用标准库函数FLASH_ProgramWord写入即可。
6. APP_A与APP_B区别
Flash层面区别，二者是独立的。在链接文件中，需要用代码将应用程序的基地址指向APP_A或APP_B的基地址。
软件层面，主机需要知道从机的空闲Flash的地址和边界，在Current Image Char中需要将APP_A或APP_B的地址信息以硬代码形式写入程序。设置标志位时候，也需要知道当前程序是APP_A还是APP_B。
实际使用时，主机端需要准备APP_A和APP_B两套bin文件，先与从机沟通确定旧程序所在位置，然后选出合适的新程序传给从机。
疑问——能不能实现用户编程时候不管APP_A或APP_B，在设备端或主机端自动判断位置并将二进制文件写入到合适的Flash地址？
7. 单程OTA
前面介绍的OTA方案，新旧程序独立存放，因此在OTA升级过程中如果断电，重启后仍然可以运行旧程序。
但是该方案用户程序只能使用不足一半的Flash空间，浪费较多。
单程OTA方案不分割应用程序空间，将OTA Service 放在引导程序，更新时候在引导程序中接收新程序数据，并直接覆盖在程序空间。
这样好处是能够有效利用Flash空间，但如果OTA中途失败，将破坏旧程序，重启后会（且只能）进入等待升级状态。
单程OTA方案架构图如下：
实现思路与需要考虑的问题，与双程OTA方案大同小异。
（完）
