CN105022646A - 一种数据无损的远程代码更新方法和装置 - Google Patents

Abstract

本发明提供了一种数据无损的远程代码更新方法和装置，所述方法包括：步骤一，服务器端发送ProcessAppInfoMsg帧，该帧将代码的总字节数和总包数传递给控制器并由控制器写入SD卡指定位置处中，以供校验帧校验时使用，控制器返回ProcessSendResponse帧；步骤二，服务器端发送ProcessTransDataMsg帧，控制器端根据该帧的校验码校验该帧，若正确则根据SD卡的记录格式将代码写入SD卡相应地址处；步骤三，服务器端发送ProcessAppVerificationMsg帧，该帧在代码帧发送完毕后发送，其记录了所有代码的32位累加校验和，若从SD卡中读取的所有代码帧的32位累加校验和与此相等，则校验成功，否则由该帧的返回帧携带出错信息，请求服务器重发该帧。步骤四，服务器端发送ProcessAppUpdateMsg帧，用户应用程序接收到该帧则程序跳转到bootloader处，由bootloader完成代码更新操作。本发明具有代码更新时间短、数据无损失的优点。

Description

一种数据无损的远程代码更新方法和装置

技术领域

本发明涉及远程代码更新领域，更具体地，涉及一种数据无损的远程代码更新方法和装置。

背景技术

随着物联网技术的发展，在无线传感器网络等领域，无线远程代码更新技术愈发显得必不可少。在军事、科学研究等领域，有些数据极其珍贵，丢失2、3分钟内采集的数据也变得无法容忍，这对无线远程代码更新机制带来了新的挑战。

目前，基于WiFi、以太网、GPRS、ZigBee、CAN总线等技术的远程代码更新技术层出不穷。他们均遵从于BootLoader(代码更新)代码与用户代码分离的原则，即在BootLoader程序中接收待更新程序的机器码文件，并将其拷贝到指定地址的ROM中，并采用PC指针跳转来完成代码更新操作。在Cortex-M4内核的STM32芯片上，目前已经出现按照上述原则采用GPRS技术完成代码更新的技术。

然而，现存的技术受网络质量、环境的影响，或多或少的存在代码更新延迟，更有甚者代码更新失败，这不可避免造成了大量的数据丢失。

发明内容

为解决基于GPRS的传统无线远程代码更新时数据采集大量丢失、代码更新花费时间长的技术问题，本发明提出了一种数据无损的远程代码更新方法，其采用空间换时间的方式降低了代码更新时间长的问题，由于更新时延低从而在代码更新过程中不会出现数据大量丢失的情况。

本发明所提供的数据无损的远程代码更新方法，包括如下步骤：

步骤一，服务器端发送ProcessAppInfoMsg帧，该帧将代码的总字节数和总包数传递给控制器并由控制器写入SD卡指定位置处中，以供校验帧校验时使用，控制器返回ProcessSendResponse帧；若ProcessAppInfoMsg帧出错则重发ProcessAppInfoMsg帧；

步骤二，服务器端发送ProcessTransDataMsg帧，控制器端根据该帧的校验码校验该帧，若正确则根据SD卡的记录格式将代码写入SD卡相应地址处；若出错，则返回当前应接受帧的包号以要求服务器重发该帧；此外，若服务器收不到该帧的返回帧则重发该帧，该过程持续到第n帧发送结束，n为要发送的帧的数量；

步骤三，服务器端发送ProcessAppVerificationMsg帧，该帧在代码帧发送完毕后发送，其记录了所有代码的累加校验和，若从SD卡中读取的所有代码帧的累加校验和与此相等，则校验成功，否则由该帧的返回帧携带出错信息，请求服务器重发该帧；此外，若服务器收不到该帧的返回帧则重发该帧。

步骤四，服务器端发送ProcessAppUpdateMsg帧，用户应用程序接收到该帧则程序跳转到bootloader处，由bootloader完成代码更新操作。

优选的，在所述步骤一之前，通过下述步骤提取.S19文件：

S1，读取一行S记录，若为S0记录，表明该文件的起始格式正确，否则，表明文件打开错误，返回程序开始处重新打开文件；

S2，读取一行S3记录，取得该S3记录的长度赋值给变量len，然后以代码在主控芯片Flash中的地址为下标，将所述len字节代码存储在boot.image.f[]数组中；

S3，在相同下标的boot.image.f[]数组中标记代码是否为有效数据，其中1表示有效，0表示无效；

S4，计算所述len字节代码的累加校验和fcs，若fcs与该S3记录的最后一个字节相加和为0xff，则表明该S3记录提取的代码有效，否则报错并退出.S19文件的提取流程。

优选的，BootLoader和.S19机器码文件存储在控制器的MCU的Flash区中，将Flash区划分为bootloader代码区和用户代码区，bootloader代码区包括bootloader代码和bootloader中断向量表，用户代码区包括用户代码和用户代码中断向量表。

优选的，bootloader中断向量表在Flash中的起始地址为零地址处，bootloader代码在Flash中的结束地址小于0x00008000，用户代码中断向量表在Flash中的起始地址为0x0000_8000，用户代码在Flash中的起始地址为0x00008420。

优选的，累加校验为32位。

本发明所提供的实现上述任意一项所述的数据无损的远程代码更新方法的数据无损的远程代码更新装置，包括：服务器、GPRS模块、控制器和SD卡，其中，服务器和控制器之间通过GPRS模块通信连接，SD卡与控制器通信连接。

与现有技术相比，本发明提出的数据无损的远程代码更新方法，在用户应用程序中，将通过GPRS传输过来的数据存储到SD卡中，当数据传输完毕，调用BootLoader程序将SD卡中的数据拷贝到芯片内部的Flash中，完成代码更新，由于数据从SD卡中拷贝到Flash中十分快速，因此极大的减少了代码更新的时间，这在对时间需求较高的场合来说具有十分重要的意义。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明所述的数据无损的远程代码更新装置的框图；

图2是本发明所述的.S19文件有效数据提取的流程图；

图3是本发明所述的中断向量表重定位的示意图；

图4是本发明所述的SD卡记录格式；

图5是本发明所述的服务器端与控制芯片端通信帧格式；

图6是本发明所述的数据无损的远程代码更新方法的流程图。

具体实施方式

嵌入式系统在上电后首先要执行的代码就是BootLoader代码，该代码初始化和CPU相关的硬件，并将操作系统的映像或者嵌入式应用程序装载到内存中，然后跳转到应用程序处执行相关代码。

嵌入式BootLoader的启动一般分为两个阶段。第一阶段主要用于初始化依赖于CPU的硬件，该段代码一般使用汇编语言实现。这个阶段的主要任务有：(1)初始化基本的硬件设备(例如关闭所有的中断、关闭处理器内部数据、指令的Cache等)；(2)为应用程序准备好RAM空间。如果用户应用程序存储于固态存储媒介(例如SD卡、服务器硬盘等)，则复制BootLoader的第二阶段的代码到RAM中，设置相应的堆栈指针并跳转到第二阶段的C代码程序入口处执行。第二阶段代码一般采用C或者C++编写，便于开发人员编写、修改和移植，也为了实现更加复杂的功能，这个阶段的主要任务就是初始化用户应用程序的硬件设备，将应用程序的映像拷贝到RAM中，配置堆栈指针后开始运行用户应用程序。

本发明提出的数据无损的无线远程代码方法，通过深入剖析bootloader机制，并结合MG323(华为GPRS模块)的透明传输技术，在基于飞思卡尔公司Cortex M4内核的K60DN512Z芯片的主控器(MCU)上设计了bootloader，该芯片将MG323发送过来的代码经过处理后存储在SD卡中，而bootloader负责在接收到代码更新指令后将存储到SD卡中代码复制到MCUFlash的指定位置，并通过PC指针跳转来实现代码更新。由于该方案的代码更新速度主要取决于SD卡拷贝数据的速度，因此，可实现2HZ以下数据的无损采集。

图1给出了实现本发明所述的数据无损的无线远程代码更新方法的硬件装置，包括服务器、GPRS模块、控制器和SD卡，服务器和控制器之间通过GPRS模块通信连接，SD卡与控制器通信连接，其中控制器的控制芯片采用Cortex-M系列的K60DN512Z(简称K60)芯片，GPRS模块采用华为的MG323。本发明的硬件装置还包括与控制器通信连接的ZIgBee模块(图1中未示出)，以及与GPRS模块通信连接的SIM卡(图1中未示出)。

K60DN512Z芯片为飞思卡尔公司研发的Cortex-M4系列芯片，其配套开发环境为IAR或者CodeWarrior，编程语言为C和少量的汇编语言。基于该芯片的应用程序采用C语言开发，结合已经编译的.lib外设驱动库文件经过CodeWarrior 10.5自带的arm-elf-gcc编译器编译后，生成.S19格式的机器码文件。

1. .S19文件

.S19文件(S-record格式文件)是飞思卡尔编译器生成的机器码文件。其由若干行S记录构成，每行记录以CR/LF/NUL结尾。一行S记录有5个部分组成，如表1所示。

表1机器码记录格式

.S19文件共有9种记录类型S0～S9。S0为程序开始记录，不包含有效数据，无需写入Flash。S1～S3分别为8位、16位和32位MCU所对应的S记录格式，包含了机器码文件所有的代码/数据，必须无差错地写入由地址字段指定地址处的Flash中。S5记录用于统计S1、S2、S3记录的总数。S7、S8、S9分别为S3、S2、S1记录的结束记录。本发明所采用的芯片为32位的MCU，因此代码/数据部分存储在S3记录中。

在进行代码更新之前需要将.S19文件的有效数据提取出来，即将提取.S19文件中的所有S3记录的有效数据。

图2给出了提取.S19文件中的所有S3记录的有效数据的流程，图2中以其在控制芯片Flash中的地址为下标，值为内容存储在boot.image.f[]数组中，并在相同下标的boot.image.f[]数组中标记其是否为有效数据(1：有效，0：无效)。具体为：首先读取一行S记录，若为S0记录，表明该文件的起始格式正确，接下来读取一行S3记录(若为其他格式则表明文件打开错误，返回程序开始处重新打开文件)，取得该记录的长度赋值给变量len，接下来以代码在主控芯片Flash中的地址为下标，值作为内容将这len字节代码存储在boot.image.f[]数组中，在相同下标的boot.image.f[]数组中标记其是否为有效数据(1：有效，0：无效)，并计算这len字节代码的累加校验和fcs，若fcs与该记录的最后一个字节相加和为0xff则表明该记录提取的代码有效，否则报错退出.S19文件提取流程。此外，在用户代码中不可避免的会出现程序的跳转，因此映像文件中的地址会出现跳变，而被跳过的地址中存储的内容是无意义的，因此给其赋值0xff，但是在代码更新的时候将其作为有效数据进行传输并烧写到相应的地址处以简化传输过程。

2.控制芯片端代码更新设计

控制芯片端主要包括bootloader设计、GPRS模块的设置、应用程序中代码帧处理。

2.1bootloader设计

如上所述，bootloader是指系统启动后，运行在用户应用程序之前的一段代码，用其来初始化硬件设备、建立内存空间映射图，为调用用户应用程序准备好正确的环境。传统的远程代码更新bootloader机制依托于具体的通信接口。而本发明设计的bootloader因采用代码接收与代码更新分离机制，故无此限制，但是需要用户应用程序中通信手段(本发明采用GPRS通信)的支持。

2.1.1中断向量表重定位设计

中断向量是中断源的识别标志，可用来存放中断服务程序的入口地址或跳转到中断服务程序的入口地址。程序执行的第一条指令的地址也以中断向量的形式给出，因此重定位中断向量表是设计bootloader的第一步。

实际上，代码更新就是机器码文件在Flash中的替换。这里给出BootLoader和.S19机器码在MCU Flash中分布如图3所示。图3中左侧为K60芯片存储空间映像，其中0xe0000000～0xe00fffff为芯片的私有外设区，这部分由半导体厂家设定，用户无法更改。0x20000000～0x200fffff为SRAM_U位带区，位带区只能用于数据访问，不能用于取指。通过位带，可以把多个布尔型数据打包在单一的字中，且依然可以从位带别名区中，像访问普通内存一样使用它们。位带别名区中的访问操作是原子操作，消灭了传统的“读-改-写”三部曲。0x00000000～0x18000000为Flash区，这个区是需要重点关注的，用户代码和BootLoader代码均在该区中。

中间图将芯片Flash区划分为bootloader代码区和用户代码区，bootloader代码区包括bootloader代码和中断向量表，同样的用户代码区包括用户代码和中断向量表。其中bootloader的中断向量表默认处于0x0000_0000地址处，Cortex M4内核机制使MCU开机查找该向量表并取出应用程序的入口地址进行执行。传统的bootloader机制是开机即运行bootloader代码，在预定的时间内若没有接收到代码更新命令则跳转到用户应用程序中执行，而本发明设计的bootloader机制将代码接收与代码更新区别开来，即由用户应用程序接收代码帧并存储在SD卡指定位置处，并在接收到代码更新命令后，跳转到bootloader代码处，由bootloader负责将SD卡中的代码拷贝到MCU Flash的相应地址处，并将指针跳转到用户代码的入口地址处进行执行。这样就完成可代码更新操作。在这里，向量表重定位指得就是用户应用程序中本处于0x0000_0000地址处的中断向量表搬运到用户代码区所示的0x0000_8000地址处。事实表明，用户应用程序与中断向量表重定位后的用户应用程序的代码完全一致，区别只是代码在Flash中的存储位置不同，它们之间的转换公式为：用户代码＝0x0000_8000+重定位后的用户代码。其中0x0000_8000是Flash区划分的依据，也是中断向量表起始地址寄存器SCB->VTOR中定义的中断向量表的起始地址。

2.1.2链接文件中内存设计

链接文件用于把各种目标文件和库文件链接起来，并重定向它们的位置，完成符号解析。本发明链接文件的设计主要关注MEMORY和SECTIONS这两个命令。MEMORY命令：将段定位到由MEMORY命令定义的具有特定名称或属性的地址范围。SECTIONS命令：链接文件中的section(比如c语言中的一个函数就可以看做一个section)，用于SECTIONS命令作用范围之内，并作为块存在，链接器把目标文件中的每个section都当做一个个体，为其分配运行所需要的内存空间，这个过程就是重定位，最后把所有目标文件合并为一个目标文件。链接器通过一个链接脚本对其进行控制，这个脚本描述了输入文件的section到输出文件的映射，以及输出文件的内存分布。

网关节点采用的K60DN512Z芯片的RAM为64KB，Flash为512KB，在链接文件中对BootLoader代码存储空间进行划分。

bootloader代码区Flash划分如下：

#定义中断向量表起始地址为0x00000000，分配空间为0x00000400B

vectorrom   (RX):ORIGIN＝0x00000000,LENGTH＝0x00000400

#定义Flash配置域起始地址为0x00000400，分配空间为0x00000020B

cfmprotrom  (R):ORIGIN＝0x00000400,LENGTH＝0x00000020

#定义rom区    起始地址为0x00000420，分配空间为0x0007FBE0B

rom     (RX):ORIGIN＝0x00000420,LENGTH＝0x0007FBE0#Code+Const data

#定义ram区    起始地址为0x1FFF0000，分配空间为0x00020000B

ram     (RW):ORIGIN＝0x1FFF0000,LENGTH＝0x00020000#SRAM-RW data

BootLoader代码开机即运行，若检测不到代码更新标志则跳转到用户代码区去执行， 因此其中断向量表的位置需从0x00000000地址处开始，Cortex-M4内核的中断源个数不超过256个，每个中断源占4个字节，因此，给其分配0x400字节空间用于存放中断向量表。ROM起始地址为0x00000420，分配空间为0x0007FBE0字节，RAM区起始地址为0x1FFF0000，分配空间为0x00020000字节。

用户应用程序代码区Flash划分如下：

#定义中断向量表起始地址为0x00008000，分配空间为0x00000400B

vectorrom   (RX):ORIGIN＝0x00008000,LENGTH＝0x00000400

#定义Flash配置域起始地址为0x00008400，分配空间为0x00000020B

cfmprotrom  (R):ORIGIN＝0x00008400,LENGTH＝0x00000020

#定义rom区    起始地址为0x00008420，分配空间为0x0007FBE0B

rom     (RX):ORIGIN＝0x00008420,LENGTH＝0x0007CBE0#Code+Const data

#定义ram区    起始地址为0x1FFF0000，分配空间为0x00020000B

ram     (RW):ORIGIN＝0x1FFF0000,LENGTH＝0x00020000#SRAM-RW data

由于0x00000000地址处开始存放的是BootLoader代码，因此设置app用户程序的中断向量表地址为0x00008000(此地址大于BootLoader代码ROM区的结束地址)，其分配空间为0x400字节。ROM区的起始地址为0x00008420，为其分配0x0007FBE0字节空间，RAM区起始地址为0x1FFF0000，为其分配0x00020000字节空间。

bootloader中断向量表处于Flash的零地址处，ROM起始地址处于0x00000420处，因为该bootloader代码量小于32KB，故其在Flash中的结束地址小于0x00008000。由此可知在应用程序中将中断向量表安排在0x00008000是合适的，此时应用程序在Flash的0x00008420地址处开始存放。这样通过链接文件的划分就能将bootloader与应用程序代码合理地安排在MCU的Flash中。

2.1.3拷贝SD卡代码完成代码更新

从GPRS模块接收过来的代码已按照格式正确的存入SD卡。该方案中并未使用文件系统，为了操作方便自定义了一个极其简单的文件记录格式，如图4所示。

InitSection记录了初始存储数据的扇区号，即所有的数据均从这一扇区开始存储，此字段一经定义就无需改变。NowSecton记录了当前正在使用的扇区号，即数据从InitSection扇区号开始存储到NowSection扇区结束，每存储一帧数据均需更新该字段，NowSectionByes记录了当前扇区已用字节数，即作为当前扇区存储下一帧的起始地址，也需要即时更新该字段。Fcs为初始扇区号、当前正在使用的扇区号，当前扇区已用字节数的32位累加和，以确保该记录格式的准确性。由于在代码接收阶段已经确保了SD卡内数据的准确性，此处直接按照记录格式将代码拷贝到相应的Flash处并跳转PC指针即可。

2.2.用户应用程序中GPRS模块设置

通用无线分组业务GPRS(General Packet Radio Service)是一种基于GSM系统的无线分组交换技术，提供端到端的、广域的无线IP连接。简单的说，GPRS是一项低速数据处理的技术，其方法是以“分组”的形式传送数据。网络容量只在所需时分配，不要时就释放，这种发送方式称为统计复用。目前，GPRS移动通信网的传输速度可达115k/s。

本发明采用基于GPRS的华为MG323模块，其内嵌TCP/IP协议栈，可以很好的实现网关节点与万维网的通信，以便通过网页等PC方APP程序对网关节点实施控制。

本发明采用AT命令控制来实现GPRS的透明传输(传输过程对用户透明，此处是指串口与网口互发数据)。

透明传输的初始化AT命令如下(以下各指令设置成功均返回OK)：

经过以上设置可以开启MG323模块的透明传输功能。此时，网络数据即转化成了串口数据，因此，本发明的bootoader更新转化为基于串口的bootloader更新机制。

2.3服务器端与控制芯片端通信帧格式定义

用户应用程序中的帧格式必须与服务器端软件的帧格式一致，此处我们对其进行定义。该方案主要由通用命令帧、应用信息预处理帧、代码帧、返回帧、校验帧和更新帧。通用命令帧是载体，内嵌其余五种帧。应用信息预处理帧传送有效代码字节数和包号以供控制芯片接收与校验；代码帧传输烧入到Flash中的实际内容；校验帧用于保证数据传输的正确性；更新帧启动控制芯片端代码更新。图5是本发明所述的服务器端与控制芯片端通信帧格式。

(1)通用命令帧COMMON格式

此帧为通用帧，其它各帧内嵌在第5～n-3字节中，其中第5字节为各帧的命令字，6～n-3字节为各帧的具体内容，n-2字节为各帧有效数据的累加和校验。

(2)应用信息预处理帧(ProcessAppInfoMsg)格式

此帧在通用命令帧COMMON中的各字节说明如下：3～4字节为帧长，第5字节为命令字CMD_APP_INFO，6～9字节为有效代码总字节数，10～11字节为更新代码总包号。

(3)代码帧(ProcessTransDataMsg)格式

此帧在通用命令帧COMMON中的各字节说明如下：3～4字节为帧长，第5字节为命令字CMD_TRANS_DATA，6～7字节为包号，8～n-3字节为有效代码总字节数。

(4)返回帧(ProcessSendResponse)格式

此帧在通用命令帧COMMON中的各字节说明如下：3～4字节为帧长，第5字节为命令字CMD_RESPONSE，6～9字节当前帧包号。

(5)校验帧(ProcessAppVerificationMsg)格式

此帧在通用命令帧COMMON中的各字节说明如下：3～4字节为帧长，第5字节为命令字CMD_VERIFICATION，6～9字节为有效代码总字节数。

(6)更新帧(ProcessAppUpdateMsg)格式

此帧在通用命令帧COMMON中的各字节说明如下：3～4字节为帧长，第5字节为命令字CMD_UPDATE，6～9字节为有效代码总字节数。

3控制芯片与服务器端通信控制

如图6所示，服务器端代码更新软件内嵌于服务器端应用程序中。结合考虑GPRS的慢速数据传输能力、SD卡读写能力和控制芯片的处理能力，本发明设计的代码帧长为521字节。因此，需将代码拆分为若干包进行发送。代码更新步骤如下。

第一步：服务器端发送ProcessAppInfoMsg帧，该帧将代码的总字节数和总包数传递给控制器并由控制器写入SD卡指定位置处中，以供校验帧校验时使用。控制器返回ProcessSendResponse帧，若该帧出错则重发ProcessAppInfoMsg帧。

第二步：服务器端发送ProcessTransDataMsg帧，控制器端根据该帧的校验码校验该帧，若正确则根据SD卡的记录格式将代码写入SD卡相应地址处；若出错，则返回当前应接受帧的包号以要求服务器重发该帧。此外，若服务器收不到返回帧则重发该帧，该过程持续到第n帧发送结束，n为要发送的帧的数量。

第三步：服务器端发送ProcessAppVerificationMsg帧，该帧在代码帧发送完毕后发送，其记录了所有代码的32位累加校验和，若从SD卡中读取的所有代码帧的32位累加校验和与此相等，则校验成功，否则由返回帧携带出错信息，请求服务器重发该帧。此外，若服务器收不到该帧的返回帧则重发该帧。

第四步：服务器端发送ProcessAppUpdateMsg帧，用户应用程序接收到该帧则程序跳转到bootloader处，由bootloader完成代码更新操作。

下面进行本发明提出的数据无损的远程代码更新方法与常规代码更新方法在屏蔽数据采集时间上的比较。常规代码更新方法屏蔽数据采集的时间即程序在bootloader中运行的时间。测试方法为：上位机软件设置一个定时器，显示bootloader开始到接收到bootloader更新成功帧所需的时间。无损代码更新方案屏蔽数据采集的时间即bootloader从SD卡中拷贝数据至Flash所花费的时间。测试方法为：控制器端给指定引脚一个低电平，在bootloader开始时将其拉高，结束时将其拉低，用示波器观察得到的高电平持续时间即为所需要的时间。以300KB的s19文件为例。在一天不同的时间段测试的各数据如下所示：每个数据均为当前时间测量的5次数据的平均值。

表2无损代码与常规代码屏蔽数据采集时间的比较

由表2可知采用本发明所述的无损代码更新方法屏蔽数据采集的时间仅为常规代码更新方法的1/40，因此极大的避免了代码更新过程中丢失采集到的数据。实际应用表明：该无损代码更新可做到2HZ数据采集频率下无损采集数据。

应当理解的是，以上所述仅为本发明的较佳实施例而已，并不足以限制本发明的技术方案，对本领域普通技术人员来说，在本发明的精神和原则之内，可以根据上述说明加以增减、替换、变换或改进，而所有这些增减、替换、变换或改进后的技术方案，都应属于本发明所附权利要求的保护范围。

Claims (6)

1.一种数据无损的远程代码更新方法，其特征在于所述方法包括如下步骤：

步骤一，服务器端发送ProcessAppInfoMsg帧，该帧将代码的总字节数和总包数传递给控制器并由控制器写入SD卡指定位置处中，以供校验帧校验时使用，控制器返回ProcessSendResponse帧；若ProcessAppInfoMsg帧出错则重发ProcessAppInfoMsg帧；

步骤二，服务器端发送ProcessTransDataMsg帧，控制器端根据该帧的校验码校验该帧，若正确则根据SD卡的记录格式将代码写入SD卡相应地址处；若出错，则返回当前应接受帧的包号以要求服务器重发该帧；此外，若服务器收不到该帧的返回帧则重发该帧，该过程持续到第n帧发送结束，n为要发送的帧的数量；

步骤三，服务器端发送ProcessAppVerificationMsg帧，该帧在代码帧发送完毕后发送，其记录了所有代码的累加校验和，若从SD卡中读取的所有代码帧的累加校验和与此相等，则校验成功，否则由该帧的返回帧携带出错信息，请求服务器重发该帧；此外，若服务器收不到该帧的返回帧则重发该帧；

步骤四，服务器端发送ProcessAppUpdateMsg帧，用户应用程序接收到该帧则程序跳转到bootloader处，由bootloader完成代码更新操作。

2.根据权利要求1所述的数据无损的远程代码更新方法，其特征在于在所述步骤一之前，通过下述步骤提取.S19文件：

S1，读取一行S记录，若为S0记录，表明该文件的起始格式正确，否则，表明文件打开错误，返回程序开始处重新打开文件；

S2，读取一行S3记录，取得该S3记录的长度赋值给变量len，然后以代码在主控芯片Flash中的地址为下标，将所述len字节代码存储在boot.image.f[]数组中；

S3，在相同下标的boot.image.f[]数组中标记代码是否为有效数据，其中1表示有效，0表示无效；

S4，计算所述len字节代码的累加校验和fcs，若fcs与该S3记录的最后一个字节相加和为0xff，则表明该S3记录提取的代码有效，否则报错并退出.S19文件的提取流程。

3.根据权利要求1所述的数据无损的远程代码更新方法，其特征在于：

BootLoader和.S19机器码文件存储在控制器的MCU的Flash区中，将Flash区划分为bootloader代码区和用户代码区，bootloader代码区包括bootloader代码和bootloader中断向量表，用户代码区包括用户代码和用户代码中断向量表。

4.根据权利要求3所述的数据无损的远程代码更新方法，其特征在于：bootloader中断向量表在Flash中的起始地址为零地址处，bootloader代码在Flash中的结束地址小于0x00008000，用户代码中断向量表在Flash中的起始地址为0x0000_8000，用户代码在Flash中的起始地址为0x00008420。

5.根据权利要求1所述的数据无损的远程代码更新方法，其特征在于：累加校验为32位。

6.一种实现如权利要求1-5中任意一项所述的数据无损的远程代码更新方法的数据无损的远程代码更新装置，其特征在于所述装置包括：服务器、GPRS模块、控制器和SD卡，其中，服务器和控制器之间通过GPRS模块通信连接，SD卡与控制器通信连接。