BLE的OTA可以用来更新固件程序。本文以BlueNRG-1芯片为例,分析OTA实现方案细节。

1. 架构

一个OTA方案至少包括三个部分:

程序类型 描述
当前用户程序 当前正在运行的固件程序
新版用户程序 接收的更新后的固件程序
引导程序 芯片上电先进入引导程序,再跳转到新版程序运行

BlueNRG-1对160kB的内部Flash进行了逻辑分区,分别存放这三个部分程序:

BLE_OTA_Dual_Image_Architecture

这颗芯片的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 时序

基本时序如下所示:

BLE_OTA_Protocol_Timing

3. 引导程序

引导程序完成两个任务:

  • 检测当前程序的位置
  • 跳转到当前程序

在程序的Flash空间基地址,存放的是中断向量表,向量表的第一个元素为_INITIAL_SP,其内容为栈顶的地址,即MSP指针;第二个元素为复位处理函数(Reset_Handler),执行该句柄将执行程序初始化操作并跳转进入C代码的main函数。

所以,引导程序需要做的是检测到当前程序的中断向量表,并执行它的复位处理函数。

中断向量表在程序空间的位置如下图所示:

BLE_OTA_Vector_Table

中断向量表的第五个元素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方案架构图如下:

BLE_OTA_Single_Image_Arch

实现思路与需要考虑的问题,与双程OTA方案大同小异。

(完)

一个工程代码总是以main作为入口函数,芯片上电时需要完成软硬件初始化工作,为执行main函数做准备。

复位流程

下图为MCU的映像文件部分内容:

MCU_Startup_Image

所谓映像文件,就是工程编译完成后生成的bin文件。

映像文件起始位置存放中断向量表(Vector Table),然后依次存放程序代码和其他数据。中断向量表的第一项为栈顶指针MSP(Main Stack Pointer)的初值,第二项为复位向量,它指向了程序的第一个指令,即复位处理函数Reset_Handler。

MCU_Startup_Reset_Sequence

如上图所示,MCU复位时,依次完成三个任务:

  1. 从向量表的第一项(@0x00000000)中取出MSP初值
  2. 从复位向量(@0x00000004)中取出Reset_Handler函数地址
  3. 跳转到Reset_Handler函数位置并执行

在Reset_Handler函数中,MCU执行软硬件初始化,包括Flash和RAM位置、时钟和PLL、静态和全局变量等。

下面详细介绍Reset_Handler的来龙去脉。

启动文件

启动文件定义了中断向量表、Reset_Handler函数,它直接决定了启动流程。

启动文件可以是C语言源文件文件(.c),也可以是汇编语言文件(.s)。IAR平台下启动文件通常是个汇编文件。

汇编格式的启动文件名字通常为startup_<< part_number >>.s,同一个型号芯片的启动文件一般相同。

下面以STM32L152芯片为例,打开startup_stm32l152xe.s文件,去掉注释和重复内容后,如下:

        MODULE  ?cstartup

        ;; Forward declaration of sections.
        SECTION CSTACK:DATA:NOROOT(3)
        SECTION .intvec:CODE:NOROOT(2)

        EXTERN  __iar_program_start
        EXTERN  SystemInit        
        PUBLIC  __vector_table

        DATA
__vector_table
        DCD     sfe(CSTACK)
        DCD     Reset_Handler             ; Reset Handler

        DCD     NMI_Handler               ; NMI Handler
        DCD     HardFault_Handler         ; Hard Fault Handler
        DCD     MemManage_Handler         ; MPU Fault Handler
        DCD     BusFault_Handler          ; Bus Fault Handler
        DCD     UsageFault_Handler        ; Usage Fault Handler
        
        <<Many More>>
        
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Default interrupt handlers.
;;
        THUMB

        PUBWEAK Reset_Handler
        SECTION .text:CODE:REORDER:NOROOT(2)
Reset_Handler
        LDR     R0, =SystemInit
        BLX     R0
        LDR     R0, =__iar_program_start
        BX      R0
        
        PUBWEAK NMI_Handler
        SECTION .text:CODE:REORDER:NOROOT(1)
NMI_Handler
        B NMI_Handler
        
		<<Many More>>
                
        END

这段程序实现了一个cstartup的模块,该模块分为三个部分,第一部分做全局声明以及数据的导入和导出,第二部分为DATA数据,定义了向量表,第三部分为Thumb指令,实现了各个中断处理函数。

第一部分,声明CSTACK段和.intvec段,各自的类型为DATA和CODE,EXTERN行表示导入外部函数,PUBLIC行表示其他文件可以使用该向量表。

第二部分,定义向量表__vector_table的内容,第一项SFE(CSTACK)表示CSTACK内存块的末尾地址,该项将赋给栈顶指针MSP,第二项Reset_Handler的实现部分在第三部分中被定义,后续各项分别对应着向量表的各个中断向量。DCD指令表示生成一个32-bit常数。

第三部分给出了向量表中各个中断处理函数的实现,其中Reset_Handler的实现如下:

Reset_Handler
        LDR     R0, =SystemInit
        BLX     R0
        LDR     R0, =__iar_program_start
        BX      R0

其中BLX和BX均表示跳转指令,这几行代码可以理解为先调用SystemInit函数,再调用__iar_program_start函数。

SystemInit函数是ST的库函数,它完成基本的时钟配置,同时设置中断向量表在Flash中的基地址。该地址可以通过IAR的Option -> Linker -> Config -> Edit设置窗口进行设置,如下所示:

MCU_Startup_intvec_Setting

也可以通过链接文件(.icf)进行手动设置。打开链接文件(stm32l152xe_flash.icf),找到相应的代码行:

define symbol __ICFEDIT_intvec_start__ = 0x08000000;

__iar_program_start函数是IAR平台自带的函数,它的源文件为C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.5\arm\src\lib\thumb\cstartup_M.c,其内容如下:

void __iar_program_start( void )
{
  __iar_init_core();
  __iar_init_vfp();
  __cmain();
}

前两个函数被封装在C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.5\arm\lib\rt7M_tl.a库文件中,无法得知其函数内容。

在Windows下可以使用命令行工具nm.exe查看.a库里面的符号列表,使用下列命令可以将符号列表输出到指定的文件中:

nm rt7M_tl.a >>symbol_list.txt

__cmain函数可以在C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.5\arm\src\lib\thumb\cmain.s文件中找到源码,但是汇编代码不易理解,这里通过反汇编代码,查看跳转逻辑。

打开IAR调试界面,使用反汇编窗口,通过搜索定位到__iar_program_start函数,可以看到它的前两行是空操作,第三行跳转到?main函数。

MCU_Startup_Deassembly_Window

继续跟踪该函数,将其反汇编代码复制出来:

__cmain:
    0x8000328: 0xf000 0xf80b  BL        __low_level_init        ; 0x8000342
    0x800032c: 0x2800         CMP       R0, #0
    0x800032e: 0xd001         BEQ.N     _call_main              ; 0x8000334
    0x8000330: 0xf7ff 0xffdc  BL        __iar_data_init3        ; 0x80002ec

第一行__low_level_init函数总是返回常数1,第二行比较R0寄存器是否为0,第三行在R0 != 0时候执行,__call_main函数直接跳转到C语言的main函数,第四行在R0 == 0时执行__iar_data_init3函数。

__iar_data_init3函数也被封装在rt7M_tl.a中,通过单步追踪发现它调用了两个子函数:__iar_zero_init3和__ iar_copy_init3。

__iar_zero_init3给.bss段内的数据赋0,__ iar_copy_init3给.data段内的赋值。

这两个子函数能够在C:\Program Files (x86)\IAR Systems\Embedded Workbench 7.5\arm\src\lib\init目录下找到各自源码。

赋值结束后,跳转至_call_main函数,进而转到C语言的main函数。

相关参考

The Definitive Guide to the ARM® Cortex-M3

IAR Help File

Booting Process

cortex-m3启动代码详解

STM32 Main里做了什么

(完)