CN112579130B - 一种交互式的iap升级方法 - Google Patents

Abstract

本发明提供一种交互式的IAP升级方法。该方法应用于上位机和待升级设备之间，包括：升级包传输阶段、升级包校验阶段和升级模式处理阶段；其中：所述升级包传输阶段，包括：上位机将所述升级包发送至待升级设备；待升级设备接收升级包；所述升级包校验阶段，包括：待升级设备接收到升级包后，对升级包进行校验，并向上位机反馈校验结果；待升级设备根据通过校验的升级包进入升级模式处理阶段；所述升级模式处理阶段，包括：跳转到APP、进行升级和恢复到原备份固件。本发明可以保证系统升级过程中的文件拷贝的正常进行，即便升级过程失败，也能恢复至原固件；此外，即使在硬件异常的情况下，也可尽量保证BootLoader稳定。

Description

一种交互式的IAP升级方法

技术领域

本发明涉及计算机技术领域，尤其涉及一种交互式的IAP升级方法。

背景技术

IAP(在应用编程)技术可以对存储APP程序的Flash区域进行重新烧写，因此，利用IAP技术可以方便地对APP程序进行更新升级。

中国专利文献CN103425510A公开了一种交互式升级的方法及装置，该专利文献旨在解决终端在升级过程若遇到断电或其他特殊状况时所造成的终端无法启动及数据丢失的问题。

然而，实际上，现有的升级方法，尤其是IAP升级方法中，仍存在诸多其他问题，例如，数据容易被捕捉，且加密级别较低；升级过程自动化程度低，相当一部分还需要通过手动重启进行升级，操作复杂；升级效率低，无法快速稳定的进行升级；升级的方法受到数据传输介质，存储介质所影响过大；遭遇升级异常，无法快速准确定位问题所在位置等问题。

发明内容

为了解决或者部分地解决现有的升级方法所存在的数据加密级别较低、升级过程自动化程度低或升级效率低的问题，本发明提供一种交互式的IAP升级方法。

本发明提供一种交互式的IAP升级方法，应用于上位机和待升级设备之间，所述方法包括：升级包传输阶段、升级包校验阶段和升级模式处理阶段；其中：

所述升级包传输阶段，包括：上位机将所述升级包发送至待升级设备；待升级设备接收升级包；

所述升级包校验阶段，包括：待升级设备接收到升级包后，对升级包进行校验，并向上位机反馈校验结果；待升级设备根据通过校验的升级包进入升级模式处理阶段；

所述升级模式处理阶段，包括：跳转到APP、进行升级和恢复到原备份固件，具体为：

步骤A1：检测升级字的数值，升级字的数值为0、1或2；

步骤A2：若升级字为0，直接跳转到APP；

步骤A3：若升级字为1，进行CRC32文件校验，具体为：

步骤A3.1：若校验失败，则将升级字设置为0，直接跳转到APP；

步骤A3.2：若校验成功，则备份原固件到存储设备，继续执行步骤A3.3；

步骤A3.3：拷贝升级包到内部flash，并对拷贝后的内部flash文件进行完整性判断：若不完整，则重复执行本步骤，直至执行设定的次数后，若仍不完整，则设置升级标志为2，恢复到原备份固件；若完整，或者在执行设定的次数范围内，经判断完整，则设置升级字为0，跳转到APP；

步骤A4：若升级字为2，则备份原固件到内部flash，并对拷贝后的内部flash文件进行完整性判断：若完整，则正常跳转；若不完整，则重复执行本步骤。

进一步地，在升级包传输阶段中，在上位机将所述升级包发送至待升级设备之前还包括：在上位机上生成升级包，包括：

步骤B1：生成原始固件；

步骤B2：在所述原始固件中添加固件头信息，所述固件头信息包括：OTP版本信息、设备名称、硬件版本、硬件发布时间、软件版本、软件发布时间、加密方式和加密用参数、升级包长度、升级包升级有效时间以及UUID认证设备起始地址；

步骤B3：在上位机上打包生成升级包，包括：设置相关完整性校验方式并选择加密的相关参数信息；输入OTP版本信息、硬件版本、硬件发布时间、软件版本和软件发布时间；使能UUID判断；以及使能加密数据密钥。

进一步地，在升级包传输阶段中，所述升级包采用的传输协议帧的结构包括：数据头字段、数据长度字段、帧序号字段、用户数据区字段和CRC校验字段；其中：

数据头字段：占用2字节，包括定界符及选项字，所述选项字包括收发选项、反馈需求选项、网络设备选项、单播广播选项、预留位和用户数据区类型项；

数据长度字段：占用2字节，用于表示用户数据区的长度；

帧序号字段：用于表示当前所传输的帧的序号。

进一步地，所述用户数据区类型项从最低位到最高位依次为：起始帧、数据帧、设备编号分配帧、包完整请求帧、包完整反馈帧、异常上报帧、ACK确认帧和预留位；

所述起始帧承载有上位机ID、完整性检测方式信息、加密数据密钥、升级包分帧后的分帧个数、一个数据帧的长度和当前时间信息；

所述设备编号分配帧承载有上位机ID和对应的待升级设备的设备编号；

所述包完整请求帧和所述包完整反馈帧用于上位机和待升级设备之间进行升级包是否完整的交互；

所述异常上报帧用于承载待升级设备监测到的本地异常信息。

进一步地，在升级包传输阶段中，具体包括：

步骤C1：上位机将升级包分为多个数据帧，然后依次将多个数据帧发送至待升级设备；

步骤C2：待升级设备判断接收到的第一个数据帧是否为起始帧：若否，则结束升级；若是，则继续下一步；

步骤C3：待升级设备判断起始帧是否符合要求：若否，则延时等待上位机发送的下一个起始帧，若等待超时，则退出升级模式，进入正常模式；若是，则继续下一步；

步骤C4：待升级设备保存起始帧内承载信息，并进入升级模式，继续下一步；

步骤C5：待升级设备清理预先设定的存储设备的存储区域；

步骤C6：待升级设备继续接收上位机发送的数据帧并进行帧处理，帧处理过程包括：帧序号比对、帧校验和帧存储检测，并记录异常的帧序号；所述帧序号比对是指将当前接收到的数据帧的帧序号与上次接收到的数据帧的帧序号进行比对，确定是否漏帧，将漏掉的数据帧所对应的帧序号作为异常的帧序号；所述帧校验是指对当前接收到的数据帧进行CRC校验，将未通过校验的数据帧所对应的帧序号作为异常的帧序号；所述帧存储检测是指将当前接收到的数据帧中的数据写入设定的存储设备，然后读取写入的数据，判断读写结果是否一致，将读写结果不一致的数据帧所对应的帧序号作为异常的帧序号；

步骤C7：待升级设备判断当前接收到的数据帧是否为最后一帧：若否，则继续等待接收下一个数据帧，若等待超时，则进行预警报告，向上位机发送异常上报帧，并退出升级模式，进入正常模式；若是，则继续下一步。

步骤C8：待升级设备根据步骤C6的记录结果，判断是否存在异常的帧序号：若是，则执行步骤C9；若否，则执行步骤C10；

步骤C9：待升级设备向上位机发送包完整反馈帧，上位机在收到完整反馈帧并解析后，重新向待升级设备发送异常的帧序号所对应的数据帧，并在发送完所有对应的数据帧后，发送一个结束帧；

步骤C10：待升级设备进行升级包校验流程：若校验通过，则升级过程完成；若校验异常，则构造异常上报帧并上报至上位机。

进一步地，所述升级包校验阶段包括：

步骤D1：判断文件完整性：根据偏移地址、长度、完整性校验方式进行计算并判断，得到结果与文件头的参数进行比较；

步骤D2：判断OTP版本信息：当前的OTP版本信息指示值应不小于原有OTP版本信息指示值；

步骤D3：判断硬件版本信息：硬件版本信息与上次必须一致；

步骤D4：判断软件版本信息：软件版本信息不小于原有软件版本信息；

步骤D5：判断设备编号是否一致；

步骤D6：判断升级时间：通过当前固件软件版本信息与起始帧信息中的当前时间进行对比，如果相差超过规定时间，则约定固件信息无效，不进行升级；

步骤D7：判断UUID是否一致；

步骤D8：若文件完整性、OTP版本信息、硬件版本信息、软件版本信息、设备编号、升级时间和UUID均符合要求，则保存参数，然后重启，保存的参数包括：OTP版本信息、硬件版本信息、软件版本信息、设备编号和升级字。

进一步地，还包括：BootLoader交互阶段，包括：

步骤E1：采用应用层指令对待升级设备的应用层进行问题排查；

步骤E2：通过驱动层进行对待升级设备的相关系统寄存器及自定义寄存器进行修改，和/或，改变跳转地址信息，排查并修复待升级设备的硬件问题、数据包问题和跳转中断向量异常问题；

步骤E3：通过设置类操作改变OTP结构体的数据进行异常调试与处理；

步骤E4：通过断点调试，确定运行停止位置，以及各个停止位置的状态信息。

本发明的有益效果：

本发明提供的交互式的IAP升级方法，可以保证系统升级过程中的文件拷贝的正常进行，即便升级过程失败，也能恢复至原固件；此外，即使在硬件异常的情况下，也可尽量保证BootLoader稳定；

本发明所提出的传输协议帧是一种优选的帧格式，该协议帧结构相对功能完善、拓展性强、真实载荷占有率高，可以提高传输效率；并且适合单点升级、广播升级和兼容无线网络升级的模式；

本发明通过对传输协议帧的结构、升级包的传输方式和升级包的校验方式进行优化，确保了升级过程的安全性。

附图说明

图1为本发明实施例提供的一种交互式的IAP升级方法的流程示意图；

图2为本发明实施例提供的升级模式阶段的流程示意图；

图3为本发明实施例提供的待升级设备的内部flash存储Boot程序、APP程序和OTP结构体的示意图；

图4为本发明实施例提供的生成升级包的流程示意图；

图5为本发明实施例提供的升级包采用的传输协议帧的结构示意图；

图6为本发明实施例提供的起始帧的结构示意图；

图7为本发明实施例提供的数据帧的结构示意图；

图8为本发明实施例提供的设备编号分配帧的结构示意图；

图9为本发明实施例提供的包完整请求帧的结构示意图；

图10为本发明实施例提供的包完整反馈帧的结构示意图；

图11为本发明实施例提供的异常上报帧的结构示意图；

图12为本发明实施例提供的ACK确认帧的结构示意图；

图13为本发明实施例提供的升级包传输阶段的流程示意图；

图14为本发明实施例提供的升级包校验阶段的流程示意图；

图15为本发明实施例提供的BootLoader交互阶段的流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例1

如图1所示，本发明实施例提供的一种交互式的IAP升级方法，应用于上位机和待升级设备之间，所述方法包括三个阶段：升级包传输阶段、升级包校验阶段和升级模式处理阶段；

所述升级包传输阶段，包括：将所述升级包发送至待升级设备；待升级设备接收升级包；

所述升级包校验阶段，包括：待升级设备接收到升级包后，对升级包进行校验，并向上位机反馈校验结果；待升级设备根据通过校验的升级包进入升级模式处理阶段；

所述升级模式处理阶段，包括：跳转到APP、进行升级和恢复到原备份固件。

如图2所示，作为一种可实施方式，所述升级模式处理阶段，具体为：

步骤A1：检测升级字的数值，升级字的数值为0、1或2；

步骤A2：若升级字为0，直接跳转到APP；

步骤A3：若升级字为1，进行CRC32文件校验，具体为：

步骤A3.1：若校验失败，则将升级字设置为0，直接跳转到APP；

步骤A3.2：若校验成功，则备份原固件到存储设备，继续执行步骤A3.3；

步骤A3.3：拷贝升级包到内部flash，并对拷贝后的内部flash文件进行完整性判断：若不完整，则重复执行本步骤，直至执行设定的次数后，若仍不完整，则设置升级标志为2，恢复到原备份固件；若完整，或者在执行设定的次数范围内，经判断完整，则设置升级字为0，跳转到APP。

步骤A4：若升级字为2，则备份原固件到内部flash，并对拷贝后的内部flash文件进行完整性判断：若完整，则正常跳转；若不完整，则重复执行本步骤。

可以理解，本发明中的待升级设备包括：MCU、具有IAP功能的SOC及相关ASIC设备。可以理解的是，本发明方法也可以作为具有高级操作系统的设备产品升级的参考，例如Linux系统完整固件的升级。如图3所示，待升级设备的内部Flash至少拥有三片扇区，三片扇区的存储大小能够放入OTP结构体、boot程序、APP程序。其中，boot程序应从起始位置开始，其他数据(如OTP结构体、APP程序)的位置可以自行定义。

升级包传输阶段主要为数据收发处理。上位机作为发送端，待升级设备作为接收端，在收发端分别进行不同的处理，同时进行相关交互处理操作。

升级包的传输方式可以采用串口UART、IIC、SPI、SDIO以及以太网等硬件传输介质，也可以采用无线非接触式传输介质(例如，相关SOC上含有蓝牙、WIFI或射频传输功能的硬件)。

升级包的传输时间可以是待升级设备正常工作中的时间点，即待升级设备在正常工作时接收到升级指令进入升级模式进行升级；也可以通过串口进入BootLoader交互模式下通过引导进行烧录相关固件信息。

升级包的存储设备不受限，可以采用芯片内部存储设备，也可以采用芯片外部的IIC/SPI/SDIO及其他总线的存储设备，也可以采用SDIO/SPI总线的SD卡或USB总线的USB设备，或其他存储设备。

可以理解，若采用文件系统方式，则不需要进行升级包传输阶段，待升级设备直接按照约定格式文件方式通过USB设计、SD卡等设备读取升级包即可。

升级包校验阶段的目的是为了保证升级包完整、版本对应、升级时间在有效时间范围内和设备判断允许等。

本发明实施例提供的交互式的IAP升级方法，可以保证系统升级过程中的文件拷贝的正常进行，即便升级过程失败，也能恢复至原固件；此外，即使在硬件异常的情况下，也可尽量保证BootLoader稳定。

实施例2

在上述实施例的基础上，考虑到升级包一般相对比较大，且需要加入相关额外信息对升级过程进行指导作用。因此，本发明实施例提供了一种在上位机上生成升级包的方式，并设计了一种升级包的传输协议帧，用于指导相关升级过程。

本发明实施例中，作为一种可实施方式，在上位机上生成升级包，包括：

步骤B1：生成原始固件；

具体地，该步骤采用现有的固件生成方法即可。例如，对于hex及bin文件的升级包，需要编译工具支持能够读取生成包的大小，再通过编程器在指定app位置，读取指定数据，即为升级包。

步骤B2：在所述原始固件中添加固件头信息，所述固件头信息包括：OTP版本信息、设备名称、硬件版本、硬件发布时间、软件版本、软件发布时间、加密方式和加密用参数、升级包长度、升级包升级有效时间以及UUID认证设备起始地址；作为一种可实施方式，可按照表1进行定义固件头信息。

表1固件头信息

固件头的大小默认是256字节，除了使用的数据按照一字节对齐，其他字节数据自动填充为0xff。如果编译器下没有一字节对齐，则需要考虑以最长字节长度对齐。固件头的结构体数据按照小端序保存。

步骤B3：在上位机上打包生成升级包，如图4所示，包括：

步骤B3.1：设置相关完整性校验方式并选择加密的相关参数信息；

具体地，完整性校验方式包括CRC32、SHA、MD5等方式。例如，针对CRC32校验方式，需要选择CRC32校验的初始值。

步骤B3.2：输入OTP版本信息、硬件版本、硬件发布时间、软件版本和软件发布时间；

步骤B3.3：使能UUID判断；

具体地，UUID使能主要用于单点升级，在升级包的数据帧发送过程中，会发送相关数据帧的信息，附带相关UUID进行验证，如此进入升级状态的待升级设备只有唯一的一个。而针对广播下的UUID判断，则需要提前通过读取UUID信息添加到固件中，待升级设备接收到完整固件后，再进行校验，确保是已经授权的模块。

步骤B3.4：使能加密数据密钥。

具体地，加密数据密钥是解密传输的数据帧及完整包的数据基础。传输帧使用密钥可校验双方接收数据的信息完整性，防止被第三方恶意攻击处理。完整包密钥用来防止攻击者在采用上位机进行生成、发送升级包和根据升级包进行升级的过程中对原代码进行恶意修改。

本实施例中，所述升级包采用的传输协议帧采用上位机进行操作自动生成，作为一种可实施方式，如图5所示，所述升级包采用的传输协议帧的结构包括：数据头字段、数据长度字段、帧序号字段、用户数据区字段和CRC校验字段；其中：

数据头字段：占用2字节，包括定界符及选项字，二者各为一个字节；所述选项字包括收发选项、反馈需求选项、网络设备选项、单播广播选项、预留位和用户数据区类型项；

数据长度字段：占用2字节，用于表示用户数据区的长度；

帧序号字段：用于表示当前所传输的帧的序号，用于防止进行重放攻击。默认条件下，上位机端使用0-127序号，待升级设备端使用128-255序号。需要说明的是，在需要交互的帧的帧序号以发送方的为准。例如，上位机作为发送方发送包完整请求帧，该包完整请求帧的帧序号为57，则待升级设备收到数据后，向上位机反馈包完整反馈帧，该包完整反馈帧的帧序号需要也应为57，而不是128以上的序号。对于两次接收同样的数据帧，除非第一次接收到的数据有误或者非法，否则，直接作为垃圾数据抛弃，不进行再次处理。

用户数据区字段：变化长度，用于承载实际数据帧的载荷内容。

CRC校验字段：长度为16bit，包含一个16bit CRC-ITU的序列。校验域的值是通过对物理层载荷计算得到的。可选地，CRC计算多项式为:G(X)＝1+X5+X12+X16。在程序内部与上位机间隔进行约定初始数值与异或参数等，不同帧间，采用跳变的数值组合进行切换，保证不被侦听到进行破解。

具体地，定界符可设置为任意可被程序识别的数字，默认可以设置为0x7f。选项字占用一个字节，即8个bit，用于决定真实载荷的长度处理方式。作为一种可实施方式，从最高位到最低位依次为：收发选项、反馈需求选项、网络设备选项、单播广播选项、预留位和用户数据区类型项；其中，用户数据区类型项占用2～0共3bit；作为一种可实施方式，选项字的参数意义可设置如下：

7收发选项：1表示发送端发送；0表示接收端发送。

6反馈需求选项：1表示接收端必须回应ACK确认帧；0表示接收端不需要回应ACK确认帧。

5网络设备选项：1表示非网络设备；0表示为无线网络设备。

4单播广播选项：1表示非单播；0表示为单点升级。

3预留：拓展使用

2-0(数值为0-7)：表示用户数据区类型。可选地，所述用户数据区类型项从最低位到最高位依次为：起始帧、数据帧、设备编号分配帧、包完整请求帧、包完整反馈帧、异常上报帧、ACK确认帧和预留位；

如图6所示，所述起始帧承载有上位机ID(即图中的HostId)、完整性校验方式(即图中的EncryptMode)、加密数据密钥(即图中的Key)、升级包分帧后的分帧个数(即图中的AllNum)、一个数据帧的长度(即图中的OneLen)和当前时间信息(即图中的NowTime)。

待升级设备通过起始帧，能够确定相关上位机是否为自己所属的主机升级设备，如果是，则进入升级模式，如果不是，则不进入。上位机一般会发送多次起始帧，以确保待升级设备可以收到。需要说明的是，起始帧在自动生成前，需要在上位机上机芯设置数据帧长度。

上位机ID通过随机算法进行配置，每次打开软件所产生的上位机ID各不相同，用于保证一次升级过程，只为该时间段内的上位机与待升级设备进行通讯。

如图7所示，本实施例中的数据帧采用纯数据帧方式直接传输，尽量减少非必须要信息。Data：长度为变长，也就是起始帧中的OneLen长度。

如图8所示，所述设备编号分配帧承载有上位机ID和对应的待升级设备的设备编号(即图中的DevAddr)。

具体地，设备编号是上位机为其所关联的待升级设备所分配的标号，目的是便于后续进行相关数据交互。实际应用中，编号信息可以采用随机方式从编号池中获取，不必按照顺序方式。特别地，在仅存在单个待升级设备的情况下，考虑到效率问题，也可以不进行设置设备编号，相应地，待升级设备也无需判断是否为自身所属的上位机。

所述包完整请求帧和所述包完整反馈帧用于上位机和待升级设备之间进行升级包是否完整的交互；

具体地，图9所示为包完整请求帧，图10为包完整反馈帧。包完整请求帧主要用于一个上位机对多个待升级设备进行同时升级，上位机主动去查询所属的待升级设备的升级状况，再进行重新广播升级。包完整请求帧中的设备编号信息即为上位机请求查询的待升级设备的设备编号。对应地，包完整反馈帧主要用于待升级设备回应包完整请求帧和自动上报包完整性信息。通过该包完整反馈帧，能够让上位机了解到待升级设备缺少哪些数据帧，以便上位机进行相关数据帧的重发或者其他操作。其中，包完整反馈帧中的丢失帧记录的长度是根据起始帧的数据长度及载荷长度计算得到的相关数据帧个数。数据帧个数分别用一个bit表示，不足8bit(1字节)按照一个字节计算，数据按照小端排列方式。

所述异常上报帧用于承载待升级设备监测到的本地异常信息；

具体地，如图11所示为异常上报帧，ErrorNum表示错误代码；作为一种可实施方式，不同取值的错误代码所代表的意义如表2所示。

表2错误代码参数意义

ACK确认帧：用于消息应答，包括数据帧的待升级设备端的是否收到应答、异常上报帧的上位机应答。

如图12所示为ACK确认帧，AckType表示回应的何种数据用户数据区。由于ACK确认帧都是根据发送方确定帧序号，因此无法准确判断是否重放，需要区分相同设备的不同帧。

可以理解，本发明提供的交互式的IAP升级方法并不限制于特定的协议帧方式，协议帧仅是通过帧格式，将一个文件进行合理分配。本实施例中的传输协议帧是一种优选的帧格式，该协议帧结构相对功能完善、拓展性强、真实载荷占有率高，可以提高传输效率。本实施例中的协议帧，适合单点升级、广播升级和兼容无线网络升级的模式。

实施例3

在上述各实施例的基础上，本发明实施例提供一种升级结构体，用于在升级方法的各个阶段，该数据只会在生产烧录过程进行一次烧录。其他时间，只有在升级或进入BootLoader交互，才能进行修改。升级结构体数据按照小端序保存。

如表3所示，本实施例中的升级结构体包括：

基础升级指令功能：对应固件的软件版本信息、硬件版本信息、OTP版本信息、设备编号。

相关用户信息：用于设备在BootLoader交互期间进行身份验证。

针对芯片自身信息：包含生产厂商信息及SN，保证生产具有唯一性。

针对网络设备：主要针对网络设备的升级，增加MAC地址及网络相关其他信息。

相关功能标志位：升级字与跳转地址。通过升级字能够进行不同升级模式切换，通过修改跳转地址及备用地址，能保证在异常下进行自恢复。

针对加密申请：主要是针对升级包完整性，升级包加密，升级权限验证。

表3升级结构体

/>

实施例4

在上述各实施例的基础上，如图13所示，本发明实施例还提供一种具体的升级包传输方式，包括以下步骤：

步骤C1：上位机将升级包分为多个数据帧，然后依次将多个数据帧发送至待升级设备；

步骤C2：待升级设备判断接收到的第一个数据帧是否为起始帧：若否，则结束升级；若是，则继续下一步；

步骤C3：待升级设备判断起始帧是否符合要求：若否，则延时等待上位机发送的下一个起始帧，若等待超时，则退出升级模式，进入正常模式；若是，则继续下一步；

步骤C4：待升级设备保存起始帧内承载信息，并进入升级模式，继续下一步；

步骤C5：待升级设备清理预先设定的存储设备的存储区域；

步骤C6：待升级设备继续接收上位机发送的数据帧并进行帧处理，帧处理过程包括：帧序号比对、帧校验和帧存储检测，并记录异常的帧序号；所述帧序号比对是指将当前接收到的数据帧的帧序号与上次接收到的数据帧的帧序号进行比对，确定是否漏帧，将漏掉的数据帧所对应的帧序号作为异常的帧序号；所述帧校验是指对当前接收到的数据帧进行CRC校验，将未通过校验的数据帧所对应的帧序号作为异常的帧序号；所述帧存储检测是指将当前接收到的数据帧中的数据写入设定的存储设备，然后读取写入的数据，判断读写结果是否一致，将读写结果不一致的数据帧所对应的帧序号作为异常的帧序号；

步骤C7：待升级设备判断当前接收到的数据帧是否为最后一帧：若否，则继续等待接收下一个数据帧，若等待超时，则进行预警报告，向上位机发送异常上报帧，并退出升级模式，进入正常模式；若是，则继续下一步。

步骤C8：待升级设备根据步骤C6的记录结果，判断是否存在异常的帧序号：若是，则执行步骤C9；若否，则执行步骤C10；

步骤C9：待升级设备向上位机发送包完整反馈帧，上位机在收到完整反馈帧并解析后，重新向待升级设备发送异常的帧序号所对应的数据帧，并在发送完所有对应的数据帧后，发送一个结束帧；

步骤C10：待升级设备进行升级包校验流程：若校验通过，则升级过程完成；若校验异常，则构造异常上报帧并上报至上位机。

具体地，升级过程的数据量是比较大的，因此需要尽可能减少系统资源在其他方面的耗费，因此，将升级模式作为单独状态，与正常模式等进行区分。

实施例5

在产品越来越网络化、智能化的现在，安全的意义已经越来越重要，而正常固件拥有诸多防止加密的方式用来防止克隆、破解、恶意攻击、旁路攻击、打磨芯片获取秘钥等。但是，很多产品设计过程中，没能更好的在升级阶段进行保护，导致在升级过程中能够进行截取信息，从而导致数据泄露，甚至代码篡改。因此，本发明上述各实施例已经介绍了对传输协议帧的结构、升级包的传输方式的处理过程以保证升级过程的安全性。在上述各实施例的基础上，如图14所示，本发明实施例还提供一种具体的升级包校验方式，更进一步地确保升级过程的安全性。该升级包校验中，主要为数据包与头校验、版本验证、UUID判断，包括以下步骤：

步骤D1：判断文件完整性：根据偏移地址、长度、完整性校验方式进行计算并判断，得到结果与文件头的参数进行比较；

步骤D2：判断OTP版本信息：当前的OTP版本信息指示值应不小于原有OTP版本信息指示值；

步骤D3：判断硬件版本信息：前两字节为“HV”，后两个字节表示主次版本信息，主次版本信息与上次必须一致；

步骤D4：判断软件版本信息：前两字节为“FV”，后两个字节表示主次版本信息，主次版本信息不小于原有软件版本信息；

步骤D5：判断设备编号是否一致；

步骤D6：判断升级时间：通过当前固件软件版本信息与起始帧信息中的当前时间进行对比，如果相差超过一天时间或者规定时间，则约定固件信息无效，不进行升级；

步骤D7：判断UUID是否一致；

步骤D8：若文件完整性、OTP版本信息、硬件版本信息、软件版本信息、设备编号、升级时间和UUID均符合要求，则保存参数，然后重启，保存的参数包括：OTP版本信息、硬件版本信息、软件版本信息、设备编号和升级字。

实施例6

在系统升级过程中，经常存在系统升级无法成功的问题。BootLoader出现问题，则无法进行正常启动与引导，一般是APP升级过程出现的问题可以进行解决。但是常规下无法准确定定位问题所在，如果异常则需要重新烧录。因此本发明提出一种在BOOT区域进行接口访问的功能，用作系统调试、问题查询，从而提高开发效率与升级异常的处理。

如图15所示，在BootLoader代码中，可以在调试期间进行打开BootLoader交互的宏定义功能即可实现图示操作。系统上电后，首先进行相关基础硬件的初始化，其中包含有串口中断的初始化功能，默认设置波特率为115200；初始化成功后的200ms内，至少收到三个a字符，表示请求进入BootLoader进行交互调试；如果200ms内没有数据交互或者交互字符错误则直接进入升级模式处理。

需要说明的是，由于BootLoader的代码应遵循尽量高效简洁，加入调试信息，会在一定程度增加程序大小，并降低其运行速度及执行效率。因此，在正式固件中，不建议打开BootLoader交互功能。

BootLoader交互阶段根据需要提供四个类别(即步骤E1至E4，可以理解的是，四个步骤之间并不限定先后顺序)，其使用方式根据需要可以交互使用，具体包括：

步骤E1：采用应用层指令对待升级设备的应用层进行问题排查；

具体地，登陆到BootLoader，提供相关异常判断的问题，例如：备份固件包信息firmware 2；升级包包信息firmware 1；当前固件包信息firmware 0；查看相关固件信息，含OTP信息等；无法升级成功问题细致信息upgradeerr；进行逐级排查异常问题，并将异常问题定位代码进行打印；硬件检测hwtest；进行硬件自测，确定相关驱动及应用是否导致异常；Uuid查询uuid；可以在boot区域查询uuid信息，获取需要信息，写入uuid到固件中。

步骤E2：通过驱动层进行对待升级设备的相关系统寄存器及自定义寄存器进行修改，和/或，改变跳转地址信息，排查并修复待升级设备的硬件问题、数据包问题和跳转中断向量异常问题；

具体地，读写芯片寄存器信息md/mw，如果是设置硬件导致异常，可以通过有效寄存器进行设置信息；读写外部升级包(片区)mde/mwe，对外部存储设备进行模拟分区，映射虚拟地址。如果通过固件排查定位到是固件包问题，则可以使用本指令进行修改对应功能进行合理修改。如果大面积错误，则不适合使用该执行；修改app跳转地址go，可以采用app指令go进行跳转地址修改，提高应用程序跳转地址的合理性。需要说明的是，修改地址，会导致升级结构体的跳转地址更改，原地址备份到跳转地址备份1或2中。如果跳转地址异常会进行看门狗复位，则在多次跳转失败后，会尝试恢复备份跳转地址。

步骤E3：通过设置类操作改变OTP结构体的数据进行异常调试与处理；

具体地，修改升级字setupdatemode；根据需要设置升级字为0、1、2，进行相关跳转APP、升级、恢复原固件的操作；修改软件版本发布时间setsofttime；修改硬件版本发布时间sethardtime；修改软件版本发布版本setsoftver，修改硬件版本发布版本sethardver，修改软硬件版本信息，进行调试版本验证过程使用；修改用户登陆账号及密码setuser，改变登录用户名及密码，根据交互提示信息，填入用户名及密码，该密码为用户密码。默认下，存在超级权限用户，为程序内部设置好，当且仅当忘记密码无法登录BootLoader交互模式下，可以申请使用。

步骤E4：通过断点调试，确定运行停止位置，以及各个停止位置的状态信息。

具体地，在没有编程器的情况下，可以采用本步骤，能够正常进行简单调试。受芯片限制，本步骤的断点调试，只能在一定程序上实现断点功能。如果需要更细致的调试，可以在开发阶段通过编程器进行逐级调试，包括：列举代码list；列举主函数代码；打断点break，通过主函数代码行号，设置断点到制定的行号，在下次进行全速执行遇到断点就会停止运行，等待下一步的指令；全速执行run，让程序进行全速执行；单步执行step，让程序进行单步执行；重新执行continue，让程序从头开始再次执行；列举断点位置breakinfo，打印所有断点信息；打印升级相关信息upgradeinfo，打印在某状况下的升级相关信息，类似参数变量。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (1)

1.一种交互式的IAP升级方法，其特征在于，应用于上位机和待升级设备之间，所述方法由升级包传输阶段、升级包校验阶段、升级模式处理阶段和BootLoader交互阶段组成；其中：

所述升级包传输阶段，包括：上位机将所述升级包发送至待升级设备；待升级设备接收升级包；在升级包传输阶段中，所述升级包采用的传输协议帧的结构包括：数据头字段、数据长度字段、帧序号字段、用户数据区字段和CRC校验字段；其中：

数据头字段：占用2字节，包括定界符及选项字，所述选项字包括收发选项、反馈需求选项、网络设备选项、单播广播选项、预留位和用户数据区类型项；

数据长度字段：占用2字节，用于表示用户数据区的长度；

帧序号字段：用于表示当前所传输的帧的序号；

所述用户数据区类型项从最低位到最高位依次为：起始帧、数据帧、设备编号分配帧、包完整请求帧、包完整反馈帧、异常上报帧、ACK确认帧和预留位；

所述起始帧承载有上位机ID、完整性检测方式信息、加密数据密钥、升级包分帧后的分帧个数、一个数据帧的长度和当前时间信息；其中，上位机ID通过随机算法进行配置，每次打开软件所产生的上位机ID各不相同；

所述设备编号分配帧承载有上位机ID和对应的待升级设备的设备编号；

所述包完整请求帧和所述包完整反馈帧用于上位机和待升级设备之间进行升级包是否完整的交互；所述包完整请求帧用于承载上位机要查询的待升级设备的设备编号；所述包完整反馈帧用于承载待升级设备的设备编号和丢失帧记录；

所述异常上报帧用于承载待升级设备监测到的本地异常信息；

在升级包传输阶段中，具体包括：

步骤C1：上位机将升级包分为多个数据帧，然后依次将多个数据帧发送至待升级设备；

步骤C2：待升级设备判断接收到的第一个数据帧是否为起始帧：若否，则结束升级；若是，则继续下一步；

步骤C3：待升级设备判断起始帧是否符合要求：若否，则延时等待上位机发送的下一个起始帧，若等待超时，则退出升级模式，进入正常模式；若是，则继续下一步；

步骤C4：待升级设备保存起始帧内承载信息，并进入升级模式，继续下一步；

步骤C5：待升级设备清理预先设定的存储设备的存储区域；

步骤C6：待升级设备继续接收上位机发送的数据帧并进行帧处理，帧处理过程包括：帧序号比对、帧校验和帧存储检测，并记录异常的帧序号；所述帧序号比对是指将当前接收到的数据帧的帧序号与上次接收到的数据帧的帧序号进行比对，确定是否漏帧，将漏掉的数据帧所对应的帧序号作为异常的帧序号；所述帧校验是指对当前接收到的数据帧进行CRC校验，将未通过校验的数据帧所对应的帧序号作为异常的帧序号；所述帧存储检测是指将当前接收到的数据帧中的数据写入设定的存储设备，然后读取写入的数据，判断读写结果是否一致，将读写结果不一致的数据帧所对应的帧序号作为异常的帧序号；

步骤C7：待升级设备判断当前接收到的数据帧是否为最后一帧：若否，则继续等待接收下一个数据帧，若等待超时，则进行预警报告，向上位机发送异常上报帧，并退出升级模式，进入正常模式；若是，则继续下一步；

步骤C8：待升级设备根据步骤C6的记录结果，判断是否存在异常的帧序号：若是，则执行步骤C9；若否，则执行步骤C10；

步骤C9：待升级设备向上位机发送包完整反馈帧，上位机在收到完整反馈帧并解析后，重新向待升级设备发送异常的帧序号所对应的数据帧，并在发送完所有对应的数据帧后，发送一个结束帧；

步骤C10：待升级设备进行升级包校验流程：若校验通过，则升级过程完成；若校验异常，则构造异常上报帧并上报至上位机；

所述升级包校验阶段，包括：待升级设备接收到升级包后，对升级包进行校验，并向上位机反馈校验结果；待升级设备根据通过校验的升级包进入升级模式处理阶段；

所述升级模式处理阶段，包括：跳转到APP、进行升级和恢复到原备份固件，具体为：

步骤A1：检测升级字的数值，升级字的数值为0、1或2；

步骤A2：若升级字为0，直接跳转到APP；

步骤A3：若升级字为1，进行CRC32文件校验，具体为：

步骤A3.1：若校验失败，则将升级字设置为0，直接跳转到APP；

步骤A3.2：若校验成功，则备份原固件到存储设备，继续执行步骤A3.3；

步骤A3.3：拷贝升级包到内部flash，并对拷贝后的内部flash文件进行完整性判断：若不完整，则重复执行本步骤，直至执行设定的次数后，若仍不完整，则设置升级标志为2，恢复到原备份固件；若完整，或者在执行设定的次数范围内，经判断完整，则设置升级字为0，跳转到APP；

步骤A4：若升级字为2，则备份原固件到内部flash，并对拷贝后的内部flash文件进行完整性判断：若完整，则正常跳转；若不完整，则重复执行本步骤；

在升级包传输阶段中，在上位机将所述升级包发送至待升级设备之前还包括：在上位机上生成升级包，包括：

步骤B1：生成原始固件；

步骤B2：在所述原始固件中添加固件头信息，所述固件头信息包括：OTP版本信息、设备名称、硬件版本、硬件发布时间、软件版本、软件发布时间、加密方式和加密用参数、升级包长度、升级包升级有效时间以及UUID认证设备起始地址；

步骤B3：在上位机上打包生成升级包，包括：设置相关完整性校验方式并选择加密的相关参数信息；输入OTP版本信息、硬件版本、硬件发布时间、软件版本和软件发布时间；使能UUID判断；以及使能加密数据密钥；

所述升级包校验阶段包括：

步骤D1：判断文件完整性：根据偏移地址、长度、完整性校验方式进行计算并判断，得到结果与文件头的参数进行比较；

步骤D2：判断OTP版本信息：当前的OTP版本信息指示值应不小于原有OTP版本信息指示值；

步骤D3：判断硬件版本信息：硬件版本信息与上次必须一致；

步骤D4：判断软件版本信息：软件版本信息不小于原有软件版本信息；

步骤D5：判断设备编号是否一致；

步骤D6：判断升级时间：通过当前固件软件版本信息与起始帧信息中的当前时间进行对比，如果相差超过规定时间，则约定固件信息无效，不进行升级；

步骤D7：判断UUID是否一致；

步骤D8：若文件完整性、OTP版本信息、硬件版本信息、软件版本信息、设备编号、升级时间和UUID均符合要求，则保存参数，然后重启，保存的参数包括：OTP版本信息、硬件版本信息、软件版本信息、设备编号和升级字；

还包括：BootLoader交互阶段，包括：

步骤E1：采用应用层指令对待升级设备的应用层进行问题排查；

步骤E2：通过驱动层进行对待升级设备的相关系统寄存器及自定义寄存器进行修改，和/或，改变跳转地址信息，排查并修复待升级设备的硬件问题、数据包问题和跳转中断向量异常问题；

步骤E3：通过设置类操作改变OTP结构体的数据进行异常调试与处理；

步骤E4：通过断点调试，确定运行停止位置，以及各个停止位置的状态信息。