CN109189457B - 智能惯导传感系统的固件升级系统及方法 - Google Patents
智能惯导传感系统的固件升级系统及方法 Download PDFInfo
- Publication number
- CN109189457B CN109189457B CN201811309799.7A CN201811309799A CN109189457B CN 109189457 B CN109189457 B CN 109189457B CN 201811309799 A CN201811309799 A CN 201811309799A CN 109189457 B CN109189457 B CN 109189457B
- Authority
- CN
- China
- Prior art keywords
- packet
- app2
- app1
- firmware
- destarea
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Abstract
本发明提供了一种双备份固件升级系统和方法,其中该系统包括处理器和存储器,存储器用于存储程序;处理器用于接收固件升级请求和固件升级包,执行存储器中存储的程序以实现双备份固件升级流程。
Description
技术领域
本发明涉及一种智能惯导传感系统中的数据处理方法,特别是惯导传感系统处理器的固件升级系统和方法。
背景技术
惯性导航是一种以测量运动体加速度为基础的定位方法,它不依赖外界信息,只靠自身的惯性测量完成导航,惯性导航系统则是一种利用惯性敏感器件、基准方向及最初位置来确定物体在空间中的位置、方向和速度的自主式导航系统。智能惯导传感系统是整体系统中的核心部件之一,其数据处理功能直接影响了系统性能的优劣,各种数据,包括固件代码、默认配置、用户数据等的升级、备份和保护的机制对于系统的高效稳定运行起到了至关重要的作用。目前现有技术中flash中的数据的升级、备份、保护的机制并不完善,导致系统会出现运行不稳定,无故宕机,宕机后无法自动启动,固件升级备份功能不完备等一系列的问题。
发明内容
为解决上述技术问题,本发明了提供了一种flash的双备份系统及其固件备份升级方法,可以提高智能惯导系统的稳定性和鲁棒性。
本发明提供一种双备份系统中的固件升级方法,其中双备份系统优选为flash双备份系统。包括如下步骤:
步骤一、系统收到固件升级请求,进入固件升级状态;判断正在运行的固件为App1还是App2,如果正在运行的固件程序为App1,设置App2为预升级固件,将变量DestArea设置为APP2,擦除App2所在的区域APP2以及Reserve区域的数据,跳转到步骤四;如果正在运行的固件程序为App2,设置App1为预升级固件,将变量DestArea设置为APP1,擦除App1所在的区域APP1以及Reserve区域的数据;
步骤二、等待上位机发送固件升级包(FirmwareUpdatePacket),当收到上位机发送的固件升级包,解密固件升级包中加密的载荷部分;
步骤三、获取并判断固件升级包载荷的包类型;
如果固件升级包载荷的包类型(PacketType)为Header,获取包头数据,包括固件升级包载荷中的包类型(PacketType)、包数量(PacketNum)、包长度(PacketLength)、包总数(TotalPackets)、HDR包数量(HDRPacketNumber)、尾包数量(TailPacketNumber)、包标识(AtomID)、第一校验位(CRC1)、第二校验位(CRC2)和校验尾(CRCTail),跳转到步骤二;
如果固件升级包中有效载荷的包类型为App1,判断DestArea的值,如果DestArea等于APP1,则将有效载荷的包数据写入APP1区域,然后跳转到步骤二,否则如果DestArea不等于APP1,直接跳转到步骤二;
如果固件升级包中有效载荷的包类型(PacketType)为App2,判断DestArea的值,如果DestArea等于APP2,则将有效载荷的包数据写入APP2区域,然后跳转到步骤二,否则如果DestArea不等于APP2,直接跳转到步骤二;
如果收到的固件升级包有效载荷的包类型为包尾(tail),将有效载荷的包数据写入预留区域(Reserve区域),转入步骤四;否则,返回错误指示;
步骤四、判断DestArea的值;
如果等于APP1,计算APP1区域中的CRC,并与从包头(Header)中获取的第一校验位(CRC1)进行比对;如果DestArea等于APP2,计算APP2区域的CRC并与包头(Header)中获取到的第二校验位CRC2进行比对;
步骤五、如果任意比对成功,再判断DestArea值;如果DestArea等于APP1,则将Parameter1和Parameter2区域的Flag区域中的APP1_FLAG置为1,APP2_FLAG置为0,跳转到步骤七;如果DestArea等于APP2,则将Parameter1和Parameter2区域的Flag区域中的APP1_FLAG置为0,APP2_FLAG置为1,跳转到步骤七;否则跳转到步骤六;
步骤六、返回错误提示;
步骤七、结束固件升级过程。
本发明提供一种双备份系统,其包括处理器和存储器,其中存储器用于存储程序,处理器执行存储器中存储的程序执行上述固件升级过程。
附图说明
图1Flash双备份系统配置
图2系统和用户的配置数据结构
图3Flash双备份系统
图4Flash双备份系统固件升级流程
图5Flash双备份系统,
具体实施方式
为了阅读理解方便,对本发明中一些缩略语进行说明:
APP1或者APP2意为FLASH中的对应区域;
App1和App2意为对应区域中的固件;
本发明提供了flash中双备份系统、系统启动方法、数据固件等更新升级的方法,其可优选应用于智能惯导传感器系统中。智能惯导传感系统中采用控制器进行各类数据的处理、计算、融合,其片内具有多个flash。按照功能分,可将每个flash分为多个区域,如图1所示,包括Bootloader区域,Parameter1区域,Parameter2区域,APP1区域,APP2区域,预留(Reserve)区域。BootLoader区域用于存储引导固件启动的代码,Parameter1与Parameter2区域用于存储系统默认配置与客户配置,APP1与APP2区域用于存储系统固件,预留区域用于暂存固件升级时的配置升级文件。BootLoader主要完成了从模组上电启动到引导系统固件的功能。Flash内部同时存在两个可以运行的固件,我们称之为App1和App2,分别存储于APP1和APP2区域中。BootLoader将会按照一定的逻辑从中做出判断,选择出一个固件开始运行,在一般情况下,App1与App2的内容为完全相同,在BootLoader启动时,将会在两者之中选择其中的一个进行引导,若其中的一个固件发生损坏,在下次BootLoader启动时,将会引导另一个固件启动,同时利用完好的固件修复受损的固件,若两个固件均损坏,系统将无法启动。双固件区域将有效的增加系统的可靠性
片内Flash中同时设置两个用于存储默认配置与用户配置的Parameter区域,即Parameter1区域和Parameter2区域。Parameter1区域可位于片内FLASH地址0x08008000~0x0800BFFF的区域,总共16KB。Parameter2区域可位于FLASH地址0x0800C000~0x0800FFFF的区域,总共16KB。Parameter区域主要由三部分构成:即Flag区域、System区域和User区域。Flag区域存储用于指示BootLoader系统引导和固件升级的标志位或校验数据,这些是在BootLoader启动、FLASH启动检查和配置读取和固件升级过程中需要的标志或校验数据。标志位或校验位例如:APP1_FLAG,APP2_FLAG,DATA_VALID_FLAG,CONFIG_UPDATE_FLAG,SYS_CONFIG_CRC,USER_CONFIG_CRC。在BootLoader引导固件启动的过程中会对APP1_FLAG和APP2_FLAG进行检查,APP1_FLAG和APP2_FLAG的值将会决定BootLoader启动哪一个固件;当标志位DATA_VALID_FLAG不为0xAA时,说明该Parameter未经初始化,为不可用状态;当标志位CONFIG_UPDATE_FLAG为1时,说明有固件升级操作曾经发生,在FLASH启动检查和配置读取过程中会利用存在Reserve区域中的ConfigBin对Parameter区域进行针对固件改动的升级;标志位SYS_CONFIG_CRC为该Parameter区域中System区域的CRC16校验位,在加载System区域数据时,将会对System区域进行CRC校验,以确保所读取到的System区的出厂配置数据的可用性;标志位USER_CONFIG_CRC为该Parameter区域中User区域的CRC16校验位,在加载User区域数据时,将会对User区域进行CRC校验,以确保所读取到的User区用户配置数据的可用性。System区域用于存储写入的默认配置数据,该区域在初始设置过程中可被部分修改。User区域存储用户自行配置的配置数据,该区域内的配置数据均可被修改。在恢复默认配置过程中,该区域的数据将被擦除,并用System区域的数据,即默认配置数据进行重写。User区域存放的用户配置数据的数据格式与System区域的数据格式相同,其存放的数据名录也相同,在FLASH启动检查和配置读取的过程中,将默认读取生效User区域的配置数据。
如图2所示,System区域和User区域的配置数据由UniqueID、DataType、DataAmount和Data构成,UniqueID由GroupID和ItemID构成,每一个UniqueID都是唯一的。
Flag区域通常位于Parameter区域的前半段。以Parameter1区域的Flag区域为例:该区域位于片内FLASH地址0x08008000~0x080087FF,总共2KB。Flag区域存储APP1_FLAG和APP2_FLAG等多个标志位或检验位,APP1_FLAG以及APP2_FLAG为存储在Flag区域的两个标志位,其为8bit的无符号整形数,有效值为0或1,1代表从对应的APP区域内启动固件,一个FLAG区域中的APP1_FLAG和APP2_FLAG,两个值不同,例如一个值为1,一个值为0,为系统处于可正常启动的状态,否则为系统处于非正常状态。Parameter1区域和Parameter2区域在一般情况下存储的内容完全相同。在BootLoader启动时,将会按照一定的逻辑在Parameter1区域和Parameter2区域两者之中选择其一,加载选中的区域中存储的标志位以用于启动固件,同时,固件在初始化时也会依照一定的逻辑从两者之中的某一个Parameter区域之中读取用户或者系统的配置信息。在固件升级时,也会对Parameter区域进行读写。
Flash中的固件内置了固件升级的功能。固件升级内容包括固件本身的改动和Parameter区域的改动。固件升级功能不会对BootLoader有任何的读写操作。因为无法对正在运行的固件所在区域进行Flash的擦除和写功能,所以在当前固件下的升级动作将生效于另一个固件区域之中的固件。例如,在App1运行时开始固件升级,实际上新的固件将会被写入到App2,完成App2的更新升级。在系统成功升级并重新启动之后,BootLoader将会引导App2启动。为了保持App1和App2的内容完全一致,固件升级操作两次。
在固件启动初始化过程中,会对Parameter区域进行检查和读取,读取的内容为Parameter区域中的系统数据和用户数据。在这一过程中,检查程序将检查两个Parameter区域数据有效性,并按照一定的逻辑对无效的Parameter区域进行有效处理。
智能导航传感器系统的默认设置是将校准信息、ID等默认配置信息的写入过程。该过程将修改Parameter1和Parameter2中的System区域中的一部分数据。恢复默认设置是指将Parameter区域中的User区域进行擦除,并写入System区域中的默认配置值,这一过程将清除用户所保存数据。用户保存是指用户将其自己的个性化配置写入Parameter区域中的User区域,在系统的下一次启动时,将会加载用户在Parameter区域中的User区域的配置数据。
预留区域(reserve区域)在FLASH中位于BootLoader区域之后,Parameter区域之前的一段区域,FLASH片内地址为0x08004000~0x08007FFF,空间大小为16KB。Reserve区域一般为预留区域,该区域在固件升级过程中,被用来存储配置升级数据。该区域的数据将在固件升级过后第一次系统启动时的新旧配置数据合并过程中被使用,在该过程结束后Reserve区域将被擦除。
下面将参照附图对双备份系统、双备份系统的启动过程、数据固件等的更新升级过程进行具体描述。
图3示出了双备份固件升级系统的一个优选实施例。该系统包括引导加载处理模块(BootLoader)和存储器模块。其中,存储器模块被分成多个存储区域,分别存储不同类型的数据、固件、程序代码等,包括Bootloader区域,Parameter1区域,Parameter2区域,APP1区域,APP2区域,预留(Reserved)区域。BootLoader区域用于存储引导固件启动的程序代码,Parameter1与Parameter2区域用于存储系统默认配置与客户配置,APP1与APP2区域主要用于存储系统固件,预留区域用于暂存固件升级时的配置升级文件。BootLoader主要完成了从模组上电启动到引导系统固件的功能。Flash内部同时存在两个可以运行的固件,我们称之为App1和App2,分别存储于APP1和APP2区域中。BootLoader将会按照一定的逻辑从中做出判断,选择出一个固件开始运行,在一般情况下,App1与App2的内容为完全相同,在BootLoader启动时,将会在两者之中选择其中的一个进行引导,若其中的一个固件发生损坏,在下次BootLoader启动时,将会引导另一个固件启动,同时利用完好的固件修复受损的固件,若两个固件均损坏,系统将无法启动。双固件区域将有效的增加系统的可靠性
BootLoader引导加载程序位于片内FLASH地址0x08000000~0x08003FFF的区域内,总共16KB。在STM32F4中微控制器启动将首先运行FLASH地址0x08000000的代码,所以BootLoader通常将会在微控制器启动后被自动运行。
图4提供了一种flash双备份系统中的固件升级流程的优选实施例。在系统的上位机通信协议中,与固件升级有关的消息包括固件升级请求(FirmwareUpdateReq),固件升级请求应答(FirmwareUpdaterReqAck),固件升级包(FirmwareUpdatePacket),固件升级包应答(FirmwareUpdatePacketAck),其中固件升级请求和固件升级包为上位机发送给设备Device的命令,对应的Ack应答消息是设备Device发送给上位机的对应命令的应答。在配置模式(ConfigMode),上位机可以发送固件升级请求命令(FirmwareUpdateReq),使Device进入固件升级(FirmwareUpdate)状态,在固件升级状态下,上位机可以继续发送固件升级包以完成固件升级包和配置升级信息的传送,在完成固件升级后系统将自动退出固件升级状态。
图4所示,该flash双备份系统中的固件升级方法包括如下步骤:
步骤一、系统收到固件升级请求,进入固件升级状态;判断正在运行的固件为App1还是App2,如果正在运行的固件程序为App1,设置App2为预升级固件,将变量DestArea设置为APP2,擦除App2所在的区域APP2以及Reserve区域的数据,跳转到步骤四;如果正在运行的固件程序为App2,设置App1为预升级固件,将变量DestArea设置为APP1,擦除App1所在的区域APP1以及Reserve区域的数据;
步骤二、等待上位机发送固件升级包(FirmwareUpdatePacket),当收到上位机发送的固件升级包,解密固件升级包中加密的载荷部分;
步骤三、获取并判断固件升级包载荷的包类型。
如果固件升级包载荷的包类型(PacketType)为Header,获取包头数据,包括固件升级包载荷中的包类型(PacketType)、包数量(PacketNum)、包长度(PacketLength)、包总数(TotalPackets)、HDR包数量(HDRPacketNumber)、尾包数量(TailPacketNumber)、包标识(AtomID)、第一校验位(CRC1)、第二校验位(CRC2)和校验尾(CRCTail),跳转到步骤二;
如果固件升级包中有效载荷的包类型为App1,判断DestArea的值,如果DestArea等于APP1,则将有效载荷的包数据写入APP1区域,然后跳转到步骤二,否则如果DestArea不等于APP1,直接跳转到步骤二;
如果固件升级包中有效载荷的包类型(PacketType)为App2,判断DestArea的值,如果DestArea等于APP2,则将有效载荷的包数据写入APP2区域,然后跳转到步骤二,否则如果DestArea不等于APP2,直接跳转到步骤二;
如果收到的固件升级包有效载荷的包类型为包尾(tail),将有效载荷的包数据写入预留区域(Reserve区域),转入步骤四;否则,返回错误指示
步骤四、判断DestArea的值。
如果等于APP1,计算APP1区域中的CRC,并与从包头(Header)中获取的第一校验位(CRC1)进行比对;如果DestArea等于APP2,计算APP2区域的CRC并与包头(Header)中获取到的第二校验位CRC2进行比对;
步骤五、如果任意比对成功,再判断DestArea值。如果DestArea等于APP1,则将Parameter1和Parameter2区域的Flag区域中的APP1_FLAG置为1,APP2_FLAG置为0,跳转到步骤七;如果DestArea等于APP2,则将Parameter1和Parameter2区域的Flag区域中的APP1_FLAG置为0,APP2_FLAG置为1,跳转到步骤七;否则跳转到步骤六;
步骤六、返回错误提示
步骤七、结束固件升级过程。
图5提供了一个Flash双备份系统,其包括处理器和存储器,其中存储器用于存储程序,处理器执行存储器中存储的程序执行如下固件升级过程:
步骤一、系统收到固件升级请求,进入固件升级状态;判断正在运行的固件为App1还是App2,如果正在运行的固件程序为App1,设置App2为预升级固件,将变量DestArea设置为APP2,擦除App2所在的区域APP2以及Reserve区域的数据;如果正在运行的固件程序为App2,设置App1为预升级固件,将变量DestArea设置为APP1,擦除App1所在的区域APP1以及Reserve区域的数据。
步骤二、等待上位机发送固件升级包(FirmwareUpdatePacket),当收到上位机发送的固件升级包,解密固件升级包中加密的载荷部分。
步骤三、获取并判断固件升级包载荷的包类型。
如果固件升级包载荷的包类型(PacketType)为Header,获取包头数据,包括固件升级包载荷中的包类型(PacketType)、包数量(PacketNum)、包长度(PacketLength)、包总数(TotalPackets)、HDR包数量(HDRPacketNumber)、尾包数量(TailPacketNumber)、包标识(AtomID)、第一校验位(CRC1)、第二校验位(CRC2)和校验尾(CRCTail),跳转到步骤二;
如果固件升级包中有效载荷的包类型为App1,判断DestArea的值,如果DestArea等于APP1,则将有效载荷的包数据写入APP1区域,然后跳转到步骤二,否则如果DestArea不等于APP1,直接跳转到步骤二;
如果固件升级包中有效载荷的包类型(PacketType)为App2,判断DestArea的值,如果DestArea等于APP2,则将有效载荷的包数据写入APP2区域,然后跳转到步骤二,否则如果DestArea不等于APP2,直接跳转到步骤二;
如果收到的固件升级包有效载荷的包类型为包尾(tail),将有效载荷的包数据写入预留区域(Reserve区域),转入步骤四;否则,转入步骤六。
步骤四、判断DestArea的值。
如果DestArea等于APP1,计算APP1区域中的CRC,并与从包头(Header)中获取的第一校验位(CRC1)进行比对;如果DestArea等于APP2,计算APP2区域的CRC并与包头(Header)中获取到的第二校验位CRC2进行比对;
步骤五、如果任意比对成功,再判断DestArea值。如果DestArea等于APP1,则将Parameter1和Parameter2区域的Flag区域中的APP1_FLAG置为1,APP2_FLAG置为0,跳转到步骤七;如果DestArea等于APP2,则将Parameter1和Parameter2区域的Flag区域中的APP1_FLAG置为0,APP2_FLAG置为1,跳转到步骤七;否则跳转到步骤六;
步骤六、返回错误提示
步骤七、结束固件升级过程。
本发明实施例中处理器可以是通用处理器,例如但不限于,中央处理器(CentralProcessing Unit,CPU),也可以是专用处理器,例如但不限于,数字信号处理器(DigitalSignal Processor,DSP)、应用专用集成电路(Application Specific IntegratedCircuit,ASIC)和现场可编程门阵列(Field Programmable Gate Array,FPGA)等。此外,处理器702还可以是多个处理器的组合。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的模块及方法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。
Claims (4)
1.一种双备份系统中的固件升级方法,包括如下步骤:
步骤一、系统收到固件升级请求,进入固件升级状态;判断正在运行的固件为App1还是App2,如果正在运行的固件程序为App1,设置App2为预升级固件,将变量DestArea设置为APP2,擦除App2所在的区域APP2以及Reserve区域的数据;如果正在运行的固件程序为App2,设置App1为预升级固件,将变量DestArea设置为APP1,擦除App1所在的区域APP1以及Reserve区域的数据;
步骤二、等待上位机发送固件升级包,当收到上位机发送的固件升级包,解密固件升级包中加密的载荷部分;
步骤三、获取并判断固件升级包载荷的包类型;
如果固件升级包载荷的包类型为Header,获取包头数据,包括固件升级包载荷中的包类型、包数量、包长度、包总数、HDR包数量、尾包数量、包标识、第一校验位、第二校验位和校验尾,跳转到步骤二;
如果固件升级包中有效载荷的包类型为App1,判断DestArea的值,如果DestArea等于APP1,则将有效载荷的包数据写入APP1区域,然后跳转到步骤二,否则如果DestArea不等于APP1,直接跳转到步骤二;
如果固件升级包中有效载荷的包类型为App2,判断DestArea的值,如果DestArea等于APP2,则将有效载荷的包数据写入APP2区域,然后跳转到步骤二,否则如果DestArea不等于APP2,直接跳转到步骤二;
如果收到的固件升级包有效载荷的包类型为包尾,将有效载荷的包数据写入Reserve区域,转入步骤四;否则,返回错误指示;
步骤四、判断DestArea的值;
如果等于APP1,计算APP1区域中的CRC,并与从包头中获取的第一校验位进行比对;如果DestArea等于APP2,计算APP2区域的CRC并与包头中获取到的第二校验位进行比对;
步骤五、如果任意比对成功,再判断DestArea值;如果DestArea等于APP1,则将Parameter1和Parameter2区域的Flag区域中的APP1_FLAG置为1,APP2_FLAG置为0,跳转到步骤七;如果DestArea等于APP2,则将Parameter1和Parameter2区域的Flag区域中的APP1_FLAG置为0,APP2_FLAG置为1,跳转到步骤七;否则跳转到步骤六;
步骤六、返回错误提示;
步骤七、结束固件升级过程。
2.如权利要求1所述的方法,其中双备份系统优选为flash双备份系统。
3.一种双备份系统,其包括处理器和存储器,其中存储器用于存储程序,处理器执行存储器中存储的程序执行如下固件升级过程:
步骤一、系统收到固件升级请求,进入固件升级状态;判断正在运行的固件为App1还是App2,如果正在运行的固件程序为App1,设置App2为预升级固件,将变量DestArea设置为APP2,擦除App2所在的区域APP2以及Reserve区域的数据;如果正在运行的固件程序为App2,设置App1为预升级固件,将变量DestArea设置为APP1,擦除App1所在的区域APP1以及Reserve区域的数据;
步骤二、等待上位机发送固件升级包,当收到上位机发送的固件升级包,解密固件升级包中加密的载荷部分;
步骤三、获取并判断固件升级包载荷的包类型;
如果固件升级包载荷的包类型为Header,获取包头数据,包括固件升级包载荷中的包类型、包数量、包长度、包总数、HDR包数量、尾包数量、包标识、第一校验位、第二校验位和校验尾,跳转到步骤二;
如果固件升级包中有效载荷的包类型为App1,判断DestArea的值,如果DestArea等于APP1,则将有效载荷的包数据写入APP1区域,然后跳转到步骤二,否则如果DestArea不等于APP1,直接跳转到步骤二;
如果固件升级包中有效载荷的包类型为App2,判断DestArea的值,如果DestArea等于APP2,则将有效载荷的包数据写入APP2区域,然后跳转到步骤二,否则如果DestArea不等于APP2,直接跳转到步骤二;
如果收到的固件升级包有效载荷的包类型为包尾,将有效载荷的包数据写入Reserve区域,转入步骤四;否则,转入步骤六;
步骤四、判断DestArea的值;
如果DestArea等于APP1,计算APP1区域中的CRC,并与从包头(Header)中获取的第一校验位进行比对;如果DestArea等于APP2,计算APP2区域的CRC并与包头中获取到的第二校验位进行比对;
步骤五、如果任意比对成功,再判断DestArea值;如果DestArea等于APP1,则将Parameter1和Parameter2区域的Flag区域中的APP1_FLAG置为1,APP2_FLAG置为0,跳转到步骤七;如果DestArea等于APP2,则将Parameter1和Parameter2区域的Flag区域中的APP1_FLAG置为0,APP2_FLAG置为1,跳转到步骤七;否则跳转到步骤六;
步骤六、返回错误提示;
步骤七、结束固件升级过程。
4.如权利要求3所述的系统,其中双备份系统优选为flash双备份系统。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811309799.7A CN109189457B (zh) | 2018-11-05 | 2018-11-05 | 智能惯导传感系统的固件升级系统及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811309799.7A CN109189457B (zh) | 2018-11-05 | 2018-11-05 | 智能惯导传感系统的固件升级系统及方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109189457A CN109189457A (zh) | 2019-01-11 |
CN109189457B true CN109189457B (zh) | 2021-06-22 |
Family
ID=64941881
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811309799.7A Active CN109189457B (zh) | 2018-11-05 | 2018-11-05 | 智能惯导传感系统的固件升级系统及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109189457B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110031054A (zh) * | 2019-03-27 | 2019-07-19 | 上海飞奥燃气设备有限公司 | 燃气表智能控制器及其固件升级启动方法 |
CN114911648B (zh) * | 2022-07-14 | 2022-10-04 | 北京智芯微电子科技有限公司 | Xip flash程序驱动方法及系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105354063A (zh) * | 2015-11-18 | 2016-02-24 | 上海联影医疗科技有限公司 | 程序在线升级方法及系统 |
CN106095480A (zh) * | 2016-05-31 | 2016-11-09 | 青岛海信宽带多媒体技术有限公司 | 一种光模块固件升级的方法及装置 |
US9652216B2 (en) * | 2012-10-04 | 2017-05-16 | Dell Products L.P. | System and method for providing out-of-band software or firmware upgrades for a switching device |
CN108021410A (zh) * | 2017-12-06 | 2018-05-11 | 九阳股份有限公司 | 一种智能家电设备的固件升级方法及系统 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4359609B2 (ja) * | 2006-11-15 | 2009-11-04 | 株式会社日立製作所 | 計算機システム、システムソフトウェア更新方法及び第1サーバ装置 |
-
2018
- 2018-11-05 CN CN201811309799.7A patent/CN109189457B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9652216B2 (en) * | 2012-10-04 | 2017-05-16 | Dell Products L.P. | System and method for providing out-of-band software or firmware upgrades for a switching device |
CN105354063A (zh) * | 2015-11-18 | 2016-02-24 | 上海联影医疗科技有限公司 | 程序在线升级方法及系统 |
CN106095480A (zh) * | 2016-05-31 | 2016-11-09 | 青岛海信宽带多媒体技术有限公司 | 一种光模块固件升级的方法及装置 |
CN108021410A (zh) * | 2017-12-06 | 2018-05-11 | 九阳股份有限公司 | 一种智能家电设备的固件升级方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN109189457A (zh) | 2019-01-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109614265B (zh) | 智能惯导传感系统的双备份系统及其配置启动方法 | |
US9507604B2 (en) | Boot method and boot system | |
KR101407835B1 (ko) | 플랫폼 독립적인 메모리 로직의 제공 | |
US20040255106A1 (en) | Recovery of operating system configuration data by firmware of computer system | |
US10303459B2 (en) | Electronic system with update control mechanism and method of operation thereof | |
US20080010446A1 (en) | Portable apparatus supporting multiple operating systems and supporting method therefor | |
US7418589B2 (en) | System and method for updating a basic input/output system | |
CN105637521B (zh) | 一种数据处理方法及智能终端 | |
US20150154091A1 (en) | Bios maintenance method | |
US7127596B2 (en) | Method and system for improving computer system boot reliability by executing an application specific test during a boot prior loading an operating system | |
CN109189457B (zh) | 智能惯导传感系统的固件升级系统及方法 | |
US8555050B2 (en) | Apparatus and method thereof for reliable booting from NAND flash memory | |
CN113110891B (zh) | 固态硬盘的固件加载方法、装置、计算机设备及存储介质 | |
US20130080751A1 (en) | Method and device for updating bios program for computer system | |
US10642623B1 (en) | Preserving firmware settings during firmware updates | |
KR102598510B1 (ko) | 소프트웨어의 무결성 검증 방법 및 그 장치 | |
CN110297726B (zh) | 具有串行存在检测数据的计算机系统及内存模块控制方法 | |
US7934050B2 (en) | Microcomputer for flash memory rewriting | |
CN113238790A (zh) | 基于sd卡和eeprom的固件程序更新方法及系统 | |
US7490321B2 (en) | Method for updating firmware via determining program code | |
US10691465B2 (en) | Method for synchronization of system management data | |
WO2017143513A1 (zh) | 一种启动Boot的方法、CPU及单板 | |
WO2021012170A1 (zh) | 固件启动方法、设备及计算机可读存储介质 | |
US10157015B2 (en) | Techniques of protecting environment variables in bootloader of service processor | |
US7490232B2 (en) | Disk device using disk to rewrite firmware and firmware determination method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |