一种基于蓝牙设备端的OTA固件升级方法及系统

摘要

本申请公开了一种基于蓝牙设备端的OTA固件升级方法和系统，包括启动OTA升级步骤，蓝牙设备端接收终端发送的OTA请求升级数据包、读取本地保存的断点续传固件数据和判断该升级数据包与断点续传固件数据中的版本号和校验值是否均对应一致；若否，则蓝牙设备端下载OTA固件；下载OTA固件步骤，蓝牙设备端等待接收OTA固件的第一个chunk数据包以更新OTA固件数据、依次接收OTA固件的剩余chunk数据包，根据该剩余chunk数据包的标识来下载OTA固件；蓝牙设备端接收终端发送的升级命令并基于下载的OTA固件对该蓝牙设备端进行升级。本发明实现了断点续传功能并保证了传输的OTA固件完整性。

权利要求

1.一种基于蓝牙设备端的OTA固件升级方法，所述OTA固件升级方法包括以下步骤：S10,启动OTA升级步骤，所述启动OTA升级包括以下子步骤S11‑S13；

S11:蓝牙设备端接收终端发送的OTA请求升级数据包；

S12:所述蓝牙设备端读取本地保存的断点续传固件数据；

S13: 所述蓝牙设备端判断该OTA请求升级数据包与断点续传固件数据中的版本号和校验值是否均对应一致；

S20,下载OTA固件步骤，所述下载OTA固件步骤包括以下子步骤S21‑S23；

S21:蓝牙设备端等待接收OTA固件的第一个chunk数据包以更新OTA固件数据；

S22:蓝牙设备端依次接收OTA固件的剩余chunk数据包，根据该剩余chunk数据包的标识判断所接收的chunk数据包是否为最后一个数据包；

S23:蓝牙设备端判断OTA固件是否完整且是否可以正常运行，若是，下载OTA固件；

S30, 蓝牙设备端接收终端发送的升级命令并基于下载的OTA固件对该蓝牙设备端进行升级；

所述请求升级数据包包括新固件版本号、新固件总大小和新固件校验值；

所述断点续传固件数据包括已下载固件的版本号、已下载固件的校验值和已下载偏移量；

所述步骤S13还包括以下子步骤:

所述蓝牙设备端判断所述新固件版本号与所述已下载固件的版本号是否一致且所述新固件校验值是否与所述已下载固件的校验值一致：若是，跳转到S14；

若否，该蓝牙设备端重新开始下载OTA固件；具体的，该蓝牙设备端构建第一回复数据包，其中，所述第一回复数据包包括每一次传输的OTA固件包的大小、第一期望的固件偏移量；该第一回复数据包的偏移量的字段为0；

S14：蓝牙设备端构建第二回复数据包；其中，该第二回复数据包的偏移量字段为所述已下载偏移量，蓝牙设备端判断新固件总大小和所述已下载偏移量是否一致；

若否，该蓝牙设备端进入到断点续传状态，然后跳转到S22；

若是，蓝牙设备端进入到已下载完OTA固件等待升级命令的状态，然后跳转到S30。

2.根据权利要求1所述的OTA固件升级方法，其特征在于，所述OTA固件升级方法还包括以下步骤：S40，蓝牙设备端根据接收到的OTA固件的异常数据，初始化OTA固件的状态数据并将该OTA固件的异常数据的信息反馈给终端。

3.根据权利要求2所述的OTA固件升级方法，其特征在于：所述蓝牙设备端等待接收OTA固件的第一个chunk数据包以更新OTA固件数据具体包括：若蓝牙设备端在下载新固件的状态下，蓝牙设备端接收到的chunk数据包中的偏移量不等于0，则跳转到S40；

若接收到的第一个chunk数据包的偏移量等于0，则该蓝牙设备端初始化所述断点续传固件数据，保存第一个chunk数据包中的二进制信息，计算当前chunk数据包的累计校验值。

4.根据权利要求3所述的OTA固件升级方法，其特征在于：所述根据该剩余chunk数据包的标识判断所接收的chunk数据包是否为最后一个数据包具体包括：蓝牙设备端检测chuck数据包的标识，若该数据包的标识等于1，则表示这一chuck数据包是OTA固件的最后一个数据包，然后跳转到S23；

若该标识等于0,则表示这一chuck数据包不是最后一个数据包数据，循环执行S22，直到chuck数据包的标识等于1。

5.根据权利要求1所述的OTA固件升级方法，其特征在于，在所述根据该剩余chunk数据包的标识判断所接收的chunk数据包是否为最后一个数据包之前还包括有效检测步骤，具体为：蓝牙设备端依次接收OTA固件的剩余chunk数据包，以确定剩余chunk数据包中的每一个chunk数据包是否完整；

若否，即蓝牙设备端检测到剩余chunk数据包中至少存在一个异常数据时，跳转到S40；

若是，即检测到剩余chunk数据包中的每一个chunk数据包均正常，则该蓝牙设备端将该chunk数据包的二进制信息、当前chunk数据包的偏移量和累加计算校验值保存。

6.根据权利要求5所述的OTA固件升级方法，其特征在于，所述确定剩余chunk数据包中的每一个chunk数据包是否完整的方法为：蓝牙设备端对每个接收到的chunk数据包进行累计得到累加计算校验值，直到接收到最后一个chunk数据包，获得最终校验值，若该最终校验值与所述新固件校验值二者完全相同时，则确定剩余chunk数据包中的每一个chunk数据包是完整的。

7.一种基于蓝牙设备端的OTA固件升级系统，所述OTA固件升级系统使用根据权利要求

1至6中任一项所述的OTA固件升级方法进行固件升级，且包括蓝牙设备端和终端；

蓝牙设备端接收终端发送的OTA请求升级数据包；所述蓝牙设备端读取本地保存的断点续传固件数据；所述蓝牙设备端判断该OTA请求升级数据包与断点续传固件数据中的版本号和校验值是否均对应一致；若否，则该蓝牙设备端下载OTA固件；

蓝牙设备端等待接收OTA固件的第一个chunk数据包以更新OTA固件数据；蓝牙设备端依次接收OTA固件的剩余chunk数据包，根据该剩余chunk数据包的标识判断所接收的chunk数据包是否为最后一个数据包；蓝牙设备端判断OTA固件是否完整且是否可以正常运行，若是，下载OTA固件；

蓝牙设备端接收终端发送的升级命令并基于下载的OTA固件对该蓝牙设备端进行升级。

说明书

一种基于蓝牙设备端的OTA固件升级方法及系统

技术领域

[0001] 本申请涉及蓝牙技术领域，特别是涉及一种基于蓝牙设备端的OTA固件升级方法及系统。

背景技术

[0002] 随着物联网的高速发展，在物联网领域流行着多种无线通讯协议，比如Zigbee、蓝牙、WIFI等等。这些无线通讯协议均有着各自的优势和缺点，凭借着易连接、低功耗、成本低、无需额外网关或路由做中继等优势，低功耗蓝牙(BLE，Bluetooth Low Energy)设备已经被广泛地应用到人们日常使用的电子设备中。

[0003] 与此同时，物联网设备对系统功能和性能的要求不断提高，为了消除系统缺陷或完善功能，在线升级(OTA)对于批量化的物联网终端设备来说是相当重要的。

[0004] 虽然BLE拥有着诸多优点，但这一无线通讯协议的劣势是：为了更充分地实现其低功耗的能力，从而不得不牺牲了该无线通信协议传输的速率。

[0005] 由于BLE设备本身就是为了应对低频小数据量的场景，因此其劣势并不明显，但是为了实现OTA功能BLE设备的劣势就被暴露出来了，即如果用户想要给一个BLE设备进行完整的OTA升级就需要耗费很长的时间来等待，在OTA期间用户的终端设备不能离开BLE设备的范围，否则OTA升级过程就会终止，这样就需要再一次进行OTA升级。

发明内容

[0006] 本申请的目的在于克服上述问题或者至少部分地解决或缓减解决上述问题。

[0007] 根据本申请的一个方面，提供了一种基于蓝牙设备端的OTA固件升级方法，该方法包括以下步骤：

[0008] S10,启动OTA升级步骤，所述启动OTA升级包括以下子步骤S11‑S13；

[0009] S11:蓝牙设备端接收终端发送的OTA请求升级数据包；

[0010] S12:所述蓝牙设备端读取本地保存的断点续传固件数据；

[0011] S13:所述蓝牙设备端判断该OTA请求升级数据包与断点续传固件数据中的版本号和校验值是否均对应一致；若否，则该蓝牙设备端下载OTA固件；

[0012] S20,下载OTA固件步骤，所述下载OTA固件步骤包括以下子步骤S21‑S23；

[0013] S21:蓝牙设备端等待接收OTA固件的第一个chunk数据包以更新OTA固件数据；

[0014] S22:蓝牙设备端依次接收OTA固件的剩余chunk数据包，根据该剩余chunk数据包的标识判断所接收的chunk数据包是否为最后一个数据包；

[0015] S23:蓝牙设备端判断OTA固件是否完整且是否可以正常运行，若是，下载OTA固件；

[0016] S30,蓝牙设备端接收终端发送的升级命令并基于下载的OTA固件对该蓝牙设备端进行升级。

[0017] 可选的，所述OTA固件升级方法还包括以下步骤：

[0018] S40，蓝牙设备端根据接收到的OTA固件的异常数据，初始化OTA固件的状态数据并将该OTA固件的异常数据的信息反馈给终端。

[0019] 可选的，所述请求升级数据包包括新固件版本号、新固件总大小和新固件校验值；

[0020] 所述断点续传固件数据包括已下载固件的版本号、已下载固件的校验值和已下载偏移量。

[0021] 可选的，所述的OTA固件升级方法，其特征在于，所述启动OTA升级还包括以下子步骤:

[0022] S14：蓝牙设备端构建第二回复数据包；其中，该第二回复数据包的偏移量字段为所述已下载偏移量，蓝牙设备端判断新固件总大小和所述已下载偏移量是否一致；

[0023] 若否，该蓝牙设备端进入到断点续传状态，然后跳转到S22；

[0024] 若是，蓝牙设备端进入到已下载完OTA固件等待升级命令的状态，然后跳转到S30。

[0025] 可选的，所述启动OTA升级还包括以下子步骤:

[0026] 所述蓝牙设备端判断所述新固件版本号与所述已下载固件的版本号是否一致且所述新固件校验值是否与所述已下载固件的校验值一致为：

[0027] 若是，跳转到S14；

[0028] 若否，该蓝牙设备端重新开始下载OTA固件；具体的，该蓝牙设备端构建第一回复数据包，其中，所述第一回复数据包包括每一次传输的OTA固件包的大小、第一期望的固件偏移量；该第一回复数据包的偏移量的字段为0。

[0029] 可选的，所述蓝牙设备端等待接收OTA固件的第一个chunk数据包以更新OTA固件数据具体包括：

[0030] 若蓝牙设备端在下载新固件的状态下，蓝牙设备端接收到的chunk数据包中的偏移量不等于0，则跳转到S40；

[0031] 若接收到的第一个chunk数据包的偏移量等于0，则该蓝牙设备端初始化所述断点续传固件数据，保存第一个chunk数据包中的二进制信息，计算当前chunk数据包的累计校验值。

[0032] 可选的，所述根据该剩余chunk数据包的标识判断所接收的chunk数据包是否为最后一个数据包具体包括：

[0033] 蓝牙设备端检测chuck数据包的标识，若该数据包的标识等于1，则表示这一chuck数据包是OTA固件的最后一个数据包，然后跳转到S23；

[0034] 若该标识等于0,则表示这一chuck数据包不是最后一个数据包数据，循环执行S22，直到chuck数据包的标识等于1。

[0035] 可选的，在所述根据该剩余chunk数据包的标识判断所接的chunk数据包是否为最后一个数据包之前还包括有效检测步骤，具体为：

[0036] 蓝牙设备端依次接收OTA固件的剩余chunk数据包，以确定剩余chunk数据包中的每一个chunk数据包是否完整；

[0037] 若否，即蓝牙设备端检测到剩余chunk数据包中至少存在一个异常数据时，跳转到S40；

[0038] 若是，即检测到剩余chunk数据包中的每一个chunk数据包均正常，则该蓝牙设备端将该chunk数据包的二进制信息、当前chunk数据包的偏移量和累加计算校验值保存。

[0039] 可选的，所述检测剩余chunk数据包中的每一个chun数据包是否完整的方法为：

[0040] 蓝牙设备端对每个接收到的chunk数据包进行累计得到累加计算校验值，直到接收到最后一个chunk数据包，获得最终校验值，若该最终校验值与所述新固件校验值值者完全相同时，则确定剩余chunk数据包中的每一个chunk数据包是完整的。根据本申请的另一个方面，提供了一种基于蓝牙设备端的OTA固件升级系统，该系统包括蓝牙设备端和终端；

[0041] 蓝牙设备端接收终端发送的OTA请求升级数据包；所述蓝牙设备端读取本地保存的断点续传固件数据；所述蓝牙设备端判断该OTA请求升级数据包与断点续传固件数据中的版本号和校验值是否均对应一致；若否，则该蓝牙设备端下载OTA固件；

[0042] 蓝牙设备端等待接收OTA固件的第一个chunk数据包以更新OTA固件数据；蓝牙设备端依次接收OTA固件的剩余chunk数据包，根据该剩余chunk数据包的标识判断所接收的chunk数据包是否为最后一个数据包；蓝牙设备端判断OTA固件是否完整且是否可以正常运行，若是，下载OTA固件；

[0043] 蓝牙设备端接收终端发送的升级命令并基于下载的OTA固件对该蓝牙设备端进行升级。

[0044] 本申请提供的基于蓝牙设备端的OTA固件升级方法和系统，蓝牙设备端通过判断OTA请求升级数据包与断点续传固件数据中的版本号和校验值是否均对应一致，并结合断点续传系统机制，从而解决了由于OTA固件太大,在蓝牙设备端与终端间传输该OTA固件时间太长以及传输OTA固件时中途发生异常则必须重新下载OTA固件的技术问题，从而实现了断点续传功能；

[0045] 另外，本实施例通过比对根据累加计算校验值和新固件校验值，从而解决了OTA固件在传输过程中无法保证传输的OTA固件完整性的问题，本申请的OTA固件升级方法和系统实现了在BLE协议下完成设备OTA固件升级功能，又可以让用户不需要每次OTA升级都在设备旁等待很久。

[0046] 根据下文结合附图对本申请的具体实施例的详细描述，本领域技术人员将会更加明了本申请的上述以及其他目的、优点和特征。

附图说明

[0047] 后文将参照附图以示例性而非限制性的方式详细描述本申请的一些具体实施例。附图中相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解，这些附图未必是按比例绘制的。附图中：

[0048] 图1是根据本申请一个实施例提供的一种基于蓝牙设备端的OTA固件升级方法的流程示意图；

[0049] 图2是根据本申请另一实施例提供的一种基于蓝牙设备端的OTA固件升级方法的流程示意图；

[0050] 图3是根据本申请实施例提供的一种基于蓝牙设备端的OTA固件升级系统的结构示意图；

[0051] 图4是根据本申请实施例的计算设备示意图；

[0052] 图5是根据本申请实施例的计算机可读存储介质示意图。

具体实施方式

[0053] 图1是根据本申请实施例的提供的一种基于蓝牙设备端的OTA固件升级方法的流程示意图，参见图1所知，本申请实施例提供的OTA固件升级方法可以包括：

[0054] S10,启动OTA升级步骤，所述启动OTA升级包括以下子步骤S11‑S13；

[0055] S11:蓝牙设备端接收终端发送的OTA请求升级数据包；

[0056] S12:所述蓝牙设备端读取本地保存的断点续传固件数据；

[0057] S13:所述蓝牙设备端判断该OTA请求升级数据包与断点续传固件数据中的版本号和校验值是否均对应一致；若否，则该蓝牙设备端下载OTA固件；

[0058] S20,下载OTA固件，所述下载OTA固件包括以下子步骤S21‑S23：

[0059] S21:蓝牙设备端等待接收OTA固件的第一个chunk数据包以更新OTA固件数据；

[0060] S22:蓝牙设备端依次接收OTA固件的剩余chunk数据包，根据该剩余chunk数据包的标识判断所接收的chunk数据包是否为最后一个数据包；

[0061] S23:蓝牙设备端判断OTA固件是否完整以及是否可以正常运行；若是，下载OTA固件；

[0062] S30,蓝牙设备端接收终端发送的升级命令并基于下载的OTA固件对该蓝牙设备端进行升级。

[0063] 进一步的，所述OTA固件升级方法还包括步骤S40:蓝牙设备端根据接收到的OTA固件的异常数据，初始化OTA固件的状态数据并将该异常数据的信息反馈给终端。

[0064] 图2是根据本申请另一实施例提供的一种基于蓝牙设备端的OTA固件升级方法的流程示意图；该实施例中的终端以手机APP为例进行说明，参见图2，该OTA固件升级方法具体包括如下步骤：

[0065] S10，启动OTA升级步骤，所述启动OTA升级包括以下子步骤S11‑S13；

[0066] S11：蓝牙设备端接收手机APP发送的OTA请求升级数据包；

[0067] 具体的，首先，手机APP向蓝牙设备端发送的OTA请求升级数据包，蓝牙设备端接收该请求升级数据包；其中，本实施例中的所述请求升级数据包进一步包括手机APP待升级固件的各种数据，例如：新固件版本号(new_version)、新固件总大小(total_len)和新固件校验值(new_crc16)等数据；

[0068] S12:所述蓝牙设备端读取本地保存的断点续传固件数据；

[0069] 其中，所述断点续传固件数据包括已下载固件的版本号(down_version)、已下载固件的校验值(down_crc16)和已下载偏移量(down_offset)等数据；

[0070] S13:所述蓝牙设备端判断该OTA请求升级数据包与断点续传固件数据中的版本号和校验值是否均对应一致；若否，则该蓝牙设备端下载OTA固件；

[0071] 具体的，所述蓝牙设备端判断所述新固件版本号(new_version)与所述已下载固件的版本号(down_version)是否一致且所述新固件校验值(new_crc16)是否与所述已下载固件的校验值(down_crc16)一致；

[0072] 若是，则表明新下载的固件和原有已下载的固件相同，跳转到S14；

[0073] 若否，则表明新下载的固件和原有已下载的固件不相同，因此蓝牙设备端进入到下载OTA固件的步骤S20，即该蓝牙设备端需要重新开始下载OTA固件；具体的，该蓝牙设备端可以构建第一回复数据包，其中，该第一回复数据包的偏移量offset的字段为0；

[0074] 可选的，所述第一回复数据包进一步包括每一次传输的OTA固件包的大小(chunksize)、第一期望的固件偏移量(expect_offset1)。

[0075] S14:蓝牙设备端构建第二回复数据包；其中，该第二回复数据包的offset字段为所述已下载偏移量down_offset，蓝牙设备端判断所述新固件总大小(total_len)和所述已下载偏移量(down_offset)是否一致；

[0076] 若是，表明蓝牙设备端原有下载的固件已经传输完成，仅需要向手机APP发送升级命令即可，此时，蓝牙设备端进入到已下载完OTA固件等待升级命令的状态，然后跳转到S30；

[0077] 若否，表明蓝牙设备端原有下载的固件没有传输完成，此时，该蓝牙设备端进入到断点续传状态，然后跳转到S22。

[0078] 可选的，所述第二回复数据包也包括每一次传输OTA固件包的大小(chunksize)、第二期望的固件偏移量(expect_offset2)；其中所述第一期望的固件偏移量(expect_offset1)与第二期望的固件偏移量(expect_offset2)相同。

[0079] S20,下载OTA固件，所述下载OTA固件包括以下子步骤S21‑S24：

[0080] S21:蓝牙设备端等待接收OTA固件的第一个chunk数据包以更新OTA固件数据；

[0081] 本实施例中，若蓝牙设备端新下载的固件和原有已下载的固件不相同，则手机APP重新发送OTA固件的chunk数据包(分块数据包)，该蓝牙设备端下载该chunk数据包以进入到下载新固件的状态；

[0082] 可选的，所述chunk数据包进一步包括：最后一个chunk数据包的标识(isend)、OTA固件的当前二进制流数据的大小(binarysize)、第三期望的固件偏移量(expect_offset3)(即当前chunk数据包的偏移量offset)和OTA固件的二进制信息(binary)。

[0083] 具体的，蓝牙设备端等待接收OTA固件的第一个chunk数据包(即offset＝0的数据包)；若蓝牙设备端在下载新固件的状态下，蓝牙设备端接收到的chunk数据包中的offset不等于0，则跳转到S40；若接收到的第一个chunk数据包offset等于0，则该蓝牙设备端初始化本地存储的断点续传固件数据，将第一个chunk数据包中的二进制信息binary保存至OTA固件存储区域，计算当前chunk数据包的累计校验值(cur_crc)，以此来保存并更新OTA固件数据；

[0084] S22:蓝牙设备端依次接收OTA固件的剩余chunk数据包(即除了第一个chunk数据包以外的所有chunk数据包)，以检测剩余chunk数据包中的每一个chunk数据包是否有效；

[0085] 若否，即检测到剩余chunk数据包中至少存在一个异常数据时，则跳转到S40；

[0086] 若是，即检测到剩余chunk数据包中的每一个chunk数据包均正常，则该蓝牙设备端首先将该chunk数据包的二进制信息binary保存到新的OTA固件的存储区域，并在本地将第三期望的固件偏移量(expect_offset3)(即当前chunk数据包的期望的固件偏移量)和累加计算校验值(cur_crc)进行保存，以在断点续传时使用；即在蓝牙设备端断电重启后，将该第三期望的固件偏移量(expect_offset3)作为步骤S12中的已下载偏移量(down_offset)；同理，将累加计算校验值(cur_crc)作为步骤S12中的已下载固件的校验值(down_crc16)。

[0087] 其中，所述检测剩余chunk数据包中的每一个chunk数据包是否有效是通过检验整个chunk数据包的完整性来实现的：

[0088] 具体的，在下载完所有OTA固件后来检验整个chunk数据包的完整性，由于步骤S11中手机APP发送的请求升级包中的新固件校验值new_crc16是整个新固件的crc16校验值，该校验值是以chunksize为步长依次遍历整个新固件后计算得出的，因此蓝牙设备端在每接收到一个chunk数据包后都要进行累计计算，以得到累加计算校验值(cur_crc)，直到接收到最后一个chunk数据包，获得最终校验值end_crc16，将该最终校验值end_crc16与步骤S11中的新固件校验值new_crc16值进行比较，当二者完全相同在，则说明整个chunk数据包是完整的，进一步来说明剩余chunk数据包中的每一个chunk数据包是有效的。

[0089] 本实施中的第三期望的固件偏移量(expect_offset3)的值是根据接收到的chunk数据包的大小chunksize而变化的；例如蓝牙设备端收到的当前chunksize＝512，则收到第一个chunk数据包后，该expect_offset3＝512，若收到第二个chunk数据包后，则expect_offset3＝1024，以此类推。

[0090] 需要说明的是，由于蓝牙设备端在本地存储的行为大部分是直接操作flash，而flash的寿命有限，如果频繁写入数据则很快就会导致数据读写异常；因此，优选的，所述第三期望的固件偏移量(expect_offset3)和累加计算校验值(cur_crc)进行保存前，还可以制定保存策略来延长该flash的使用寿命；其中本实施例中的保存策略为：设定蓝牙设备端在收到N次(例如20次)chunk数据包后或者收到M字节大小(例如20KB)的chunk数据包，将该第三期望的固件偏移量(expect_offset3)和累加计算校验值(cur_crc)保存。

[0091] 然后，蓝牙设备端根据chuck数据包的标识(isend)判断该数据包是否是最后一个数据包；

[0092] 具体的，所述蓝牙设备端检测chuck数据包的标识(isend)，若该数据包的标识(isend)等于1，则表示这一chuck数据包是OTA固件的最后一个数据包，然后跳转到S23；若该数据包的标识(isend)等于0,则表示这一chuck数据包不是最后一个数据包数据，循环执行S22直到chuck数据包的标识(isend)等于1。

[0093] S23:蓝牙设备端根据累加计算校验值和新固件校验值判断OTA固件是否完整，若该OTA固件有效且完整，则下载所述OTA组件；若OTA固件的不完整和/或无效时，则跳转到S40。

[0094] 具体的，蓝牙设备端将所述累加计算校验值(cur_crc)与S11中接收到的新固件校验值(new_crc16)进行比对，以此来检验下载的OTA固件的是否有效且完整；即将最终校验值end_crc16与步骤S11中的新固件校验值new_crc16值进行比较，当二者完全相同，则说明下载的OTA固件在传输过程中是完整的。

[0095] 进一步的，在另一实施例中，当所述OTA固件完整时，可以根据预设的检验方式来判断OTA固件是否能正常的运行在当前的蓝牙设备上；可以理解的，所述预设的检验方式可以是用户的自定义格式或者蓝牙设备端厂家所提供的检验方式。

[0096] S30,蓝牙设备端接收手机APP发送的升级命令并基于下载的OTA固件对该蓝牙设备端进行升级。

[0097] 具体的，所述蓝牙设备端接收手机APP发送的升级命令并基于下载的OTA固件对该蓝牙设备端进行升级包括以下子步骤：

[0098] S31:蓝牙设备端执行OTA升级接口；

[0099] S32:初始化OTA固件状态；

[0100] S32:清空本地断点续传信息；

[0101] S32:重启蓝牙设备端，以此蓝牙设备端OTA升级完成。

[0102] 可选的，在另一个实施例中，由于蓝牙设备端所检测和接收到的数据内容和期望的不一致而进入到异常状态或者蓝牙连接断开，在这个状态下，本实施例的OTA固件升级方法还包括S40，蓝牙设备端根据接收到的OTA固件的异常数据，初始化OTA固件的状态数据并将该异常数据的信息反馈给手机APP；这里所述蓝牙设备端所检测和接收到的数据内容和期望的不一致是指蓝牙设备端所检测和接收到的数据在传输过程中数据的协议存在格式异常，比如传输的数据没有按照协议文档的格式进行封装，造成蓝牙设备端数据解析错误或者是蓝牙设备当前状态机异常。

[0103] 其中，所述OTA固件的状态数据例如包括：OTA状态机的状态数据、设备保存的全局变量等数据；所述异常数据的信息例如为该异常数据所对应的错误代码(errcode)。

[0104] 本实施例的有益效果是：

[0105] 本实施例的蓝牙设备端通过判断OTA请求升级数据包与断点续传固件数据中的版本号和校验值是否均对应一致，并结合断点续传系统机制，从而解决了由于OTA固件太大,在蓝牙设备端与终端间传输该OTA固件时间太长以及传输OTA固件时中途发生异常则必须重新下载OTA固件的技术问题，从而实现了断点续传功能；

[0106] 另外，本实施例通过比对根据累加计算校验值和新固件校验值，从而解决了OTA固件在传输过程中无法保证传输的OTA固件完整性的问题。

[0107] 基于同一发明构思，如图3所示，本申请实施例还提供了一种基于蓝牙设备端的OTA固件升级系统，所述OTA固件升级系统包括蓝牙设备端和终端；

[0108] 蓝牙设备端接收终端发送的OTA请求升级数据包；所述蓝牙设备端读取本地保存的断点续传固件数据；所述蓝牙设备端判断该OTA请求升级数据包与断点续传固件数据中的版本号和校验值是否均对应一致；若否，则该蓝牙设备端下载OTA固件；

[0109] 蓝牙设备端等待接收OTA固件的第一个chunk数据包以更新OTA固件数据；蓝牙设备端依次接收OTA固件的剩余chunk数据包，根据该剩余chunk数据包的标识判断所接收的chunk数据包是否为最后一个数据包；蓝牙设备端判断OTA固件是否完整且是否可以正常运行，若是，下载OTA固件；

[0110] 蓝牙设备端接收终端发送的升级命令并基于下载的OTA固件对该蓝牙设备端进行升级。

[0111] 本实施例提供的上述系统，可以执行上述任一OTA固件升级方法中的实施例所提供的方法，详细过程详见方法实施例中的描述，此处不赘述。

[0112] 本申请实施例还提供了一种计算设备，参照图4，该计算设备包括存储器620、处理器610和存储在所述存储器620内并能由所述处理器610运行的计算机程序，该计算机程序存储于存储器620中的用于程序代码的空间630，该计算机程序在由处理器610执行时实现用于执行任一项根据本发明的方法步骤631。

[0113] 本申请实施例还提供了一种计算机可读存储介质。参照图5，该计算机可读存储介质包括用于程序代码的存储单元，该存储单元设置有用于执行根据本发明的方法步骤的程序631′，该程序被处理器执行。

[0114] 本申请实施例还提供了一种包含指令的计算机程序产品。当该计算机程序产品在计算机上运行时，使得计算机执行根据本发明的方法步骤。

[0115] 在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、获取其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

[0116] 专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。
专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

[0117] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令处理器完成，所述的程序可以存储于计算机可读存储介质中，所述存储介质是非短暂性(英文：non‑transitory)介质，例如随机存取存储器，只读存储器，快闪存储器，硬盘，固态硬盘，磁带(英文：magnetic tape)，软盘(英文：floppy disk)，光盘(英文：optical disc)及其任意组合。

[0118] 以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。