CN111459519A - 一种mcu升级方法及装置 - Google Patents
一种mcu升级方法及装置 Download PDFInfo
- Publication number
- CN111459519A CN111459519A CN202010238099.4A CN202010238099A CN111459519A CN 111459519 A CN111459519 A CN 111459519A CN 202010238099 A CN202010238099 A CN 202010238099A CN 111459519 A CN111459519 A CN 111459519A
- Authority
- CN
- China
- Prior art keywords
- mcu
- upgrading
- slave
- data
- upgrade
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 79
- 238000004891 communication Methods 0.000 claims abstract description 46
- 238000012545 processing Methods 0.000 claims description 25
- 230000009191 jumping Effects 0.000 claims description 20
- 230000008569 process Effects 0.000 abstract description 28
- 238000002054 transplantation Methods 0.000 abstract description 14
- 230000006870 function Effects 0.000 description 24
- 230000004044 response Effects 0.000 description 15
- 230000005540 biological transmission Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 8
- 230000009286 beneficial effect Effects 0.000 description 5
- 238000012790 confirmation Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 4
- 238000010606 normalization Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 125000004122 cyclic group Chemical group 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 238000005728 strengthening Methods 0.000 description 1
- 230000003313 weakening effect Effects 0.000 description 1
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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/382—Information transfer, e.g. on bus using universal interface adapter
- G06F13/387—Information transfer, e.g. on bus using universal interface adapter for adaptation of different data processing systems to different peripheral devices, e.g. protocol converters for incompatible systems, open system
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
本发明公开了一种MCU升级方法及装置,应用于多MCU架构下的主MCU,采用在各个MCU的APP层和驱动层之间,单独增加一层中间接口层的策略,通过中间接口层屏蔽MCU的底层硬件以及不同的通信方式,来最大程度的复用APP层的上层业务,实现升级功能的快速移植。主MCU对从MCU的升级包进行格式化统一处理得到升级数据,当从MCU由工作模式跳转至升级模式后,将升级数据发送至对应的从MCU进行升级。本发明通过对各个从MCU的升级包进行格式化统一处理,使得各个从MCU均接收到相同格式的数据包,从而解决了各个从MCU的升级包格式差异的问题,简化了升级流程,提高了MCU的升级效率。
Description
技术领域
本发明涉及汽车电子技术领域,更具体的说,涉及一种MCU升级方法及装置。
背景技术
ECU(Electronic Control Unit,电子控制单元)又称“行车电脑”、“车载电脑”等,由MCU(Microcontroller Unit,微控制单元)、存储器、输入/输出接口、模数转换器以及整形、驱动等大规模集成电路组成。传统的汽车ECU在进行升级时,一般通过OBD(On-BoardDiagnostics,车载自诊断***)接口,采用CAN(Controller Area Network,控制器局域网络)总线通信的方式,将ECU的升级包传输至ECU的BootLoader(启动装载),由BootLoader执行写Flash操作进行升级。
近年来,随着人们对汽车功能的不断追求,以及汽车工业的迅速发展,ECU变得越来越复杂,ECU由单MCU逐渐发展为多MCU。在实际使用中,为不断提升各MCU的性能,经常需要对各MCU进行升级。目前,在多MCU架构下,对各MCU进行升级时,一般由主MCU升级从MCU。当主MCU对应多个从MCU的多MCU架构应用在一款车型时,每个从MCU的通信方式可能不同;当主MCU对应一个从MCU的多MCU架构应用于不同的车型时,不同车型中的从MCU的通信方式也可能不同。从MCU的通信方式包括:UART(Universal Asynchronous Receiver/Transmitter,通用异步收发传输器)通信方式、SPI(Serial Peripheral Interface,串行外设接口)通信方式和IIC(Inter-Integrated Circuit,集成电路总线)通信方式等等,因此,当通过主MCU对从MCU进行升级时,技术人员需要根据每个从MCU的通信方式以及升级方式,单独编写升级程序,因此升级流程相对复杂,且很冗余,从而导致升级效率低。
发明内容
有鉴于此,本发明公开一种MCU升级方法及装置,以解决MCU升级流程复杂,且很冗余,导致MCU升级效率低的问题。
一种MCU升级方法,应用于主MCU,所述主MCU和至少一个从MCU连接,所述主MCU和所述从MCU均包括:APP层、中间接口层和驱动层,所述中间接口层位于所述APP层和所述驱动层之间,用于屏蔽MCU的底层硬件以及不同的通信方式,所述方法包括:
获取所述从MCU的升级包,并对所述升级包进行解析,对格式进行统一化处理,得到升级数据;
向与所述升级数据对应的所述从MCU发送升级命令,使所述从MCU根据所述升级命令由工作模式跳转至升级模式;
将所述升级数据发送至所述从MCU;
当接收到所述从MCU反馈的升级结果时,向所述从MCU发送跳转命令,使所述从MCU根据所述跳转命令由所述升级模式跳转至所述工作模式。
可选的,所述将所述升级数据发送至所述从MCU,具体包括:
接收所述从MCU发送的升级请求;
根据所述升级请求将所述升级数据发送至所述从MCU。
可选的,在所述接收所述从MCU发送的升级请求之前,还包括:
向所述从MCU发送文件预览信息,使所述从MCU根据所述文件预览信息中包含的升级包信息确定升级数据在Flash中的存放区间,并将所述存放区间中已存放的数据进行擦除。
一种MCU升级方法,应用于从MCU,所述从MCU与主MCU连接,所述主MCU和所述从MCU均包括:APP层、中间接口层和驱动层,所述中间接口层位于所述APP层和所述驱动层之间,用于屏蔽MCU的底层硬件以及不同的通信方式,所述方法包括:
接收所述主MCU发送的升级命令;
根据所述升级命令由工作模式跳转至升级模式;
接收所述主MCU发送的升级数据,所述升级数据由所述主MCU对获取的所述从MCU的升级包进行解析,对格式进行统一化处理后得到;
根据所述升级数据进行升级,并在升级完成后将升级结果反馈至所述主MCU;
接收所述主MCU发送的跳转命令;
根据所述跳转命令由所述升级模式跳转至所述工作模式。
可选的,所述接收所述主MCU发送的升级数据,具体包括:
向所述主MCU发送升级请求;
接收所述主MCU发送的所述升级数据。
可选的,在所述向所述主MCU发送升级请求之前,还包括:
接收所述主MCU发送的文件预览信息,所述文件预览信息中包含升级包信息;
根据所述升级包信息确定升级数据在Flash中的存放区间,并将所述存放区间中已存放的数据进行擦除。
可选的,所述根据所述升级数据进行升级,并在升级完成后将升级结果反馈至所述主MCU,具体包括:
将所述升级数据写入对应的Flash区间;
在将所述升级数据完全写入所述Flash区间后,从所述Flash区间中回读已写完的所述升级数据,并作为回读数据;
将所述回读数据与接收的所述升级数据进行比较;
当所述回读数据与所述升级数据的所有数据完全一致时,确定所述升级数据写入成功并生成所述升级结果;
将所述升级结果反馈至所述主MCU。
可选的,在所述根据所述升级数据进行升级,并在升级完成后将升级结果反馈至所述主MCU之后,还包括:
当等待接收所述跳转命令的时间超过预设时间阈值时,主动由所述升级模式跳转至所述工作模式。
一种MCU升级装置,应用于主MCU,所述主MCU和至少一个从MCU连接,所述主MCU和所述从MCU均包括:APP层、中间接口层和驱动层,所述中间接口层位于所述APP层和所述驱动层之间,用于屏蔽MCU的底层硬件以及不同的通信方式,所述装置包括:
解析单元,用于获取所述从MCU的升级包,并对所述升级包进行解析,对格式进行统一化处理,得到升级数据;
升级命令发送单元,用于向与所述升级数据对应的所述从MCU发送升级命令,使所述从MCU根据所述升级命令由工作模式跳转至升级模式;
数据发送单元,用于将所述升级数据发送至所述从MCU;
跳转命令发送单元,用于当接收到所述从MCU反馈的升级结果时,向所述从MCU发送跳转命令,使所述从MCU根据所述跳转命令由所述升级模式跳转至所述工作模式。
一种MCU升级装置,应用于从MCU,所述从MCU与主MCU连接,所述主MCU和所述从MCU均包括:APP层、中间接口层和驱动层,所述中间接口层位于所述APP层和所述驱动层之间,用于屏蔽MCU的底层硬件以及不同的通信方式,所述装置包括:
升级命令接收单元,用于接收所述主MCU发送的升级命令;
第一跳转单元,用于根据所述升级命令由工作模式跳转至升级模式;
数据接收单元,用于接收所述主MCU发送的升级数据,所述升级数据由所述主MCU对获取的所述从MCU的升级包进行解析,对格式进行统一化处理后得到;
升级单元,用于根据所述升级数据进行升级,并在升级完成后将升级结果反馈至所述主MCU;
跳转命令接收单元,用于接收所述主MCU发送的跳转命令;
第二跳转单元,用于根据所述跳转命令由所述升级模式跳转至所述工作模式。
从上述的技术方案可知,本发明公开了一种MCU升级方法及装置,该方法应用于多MCU架构下的主MCU,在多MCU架构下,一个主MCU和至少一个从MCU连接,本发明采用在各个MCU的APP层和驱动层之间,单独增加一层中间接口层的策略,通过中间接口层屏蔽MCU的底层硬件以及不同的通信方式,来应对MCU通信方式变化带来的升级包移植困扰,从而最大程度的复用APP层的上层业务,实现升级功能的快速移植。主MCU对获取的从MCU的升级包进行格式化统一处理得到升级数据,当从MCU由工作模式跳转至升级模式后,主MCU将升级数据发送至对应的从MCU进行升级。本发明通过对各个从MCU的升级包进行格式化统一处理,使得各个从MCU均接收到相同格式的数据包,从而解决了各个从MCU的升级包格式差异的问题,简化了升级流程,提高了MCU的升级效率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据公开的附图获得其他的附图。
图1为本发明实施例公开的一种主MCU和从MCU的软件架构示意图;
图2为本发明实施例公开的一种MCU升级方法流程图;
图3为本发明实施例公开的一种对从MCU的升级包进行解析,对格式进行统一化处理得到升级数据的示意图;
图4为本发明实施例公开的一种主MCU和从MCU交互的信令图;
图5为本发明实施例公开的另一种MCU升级方法流程图;
图6为本发明实施例公开的一种MCU升级装置的结构示意图;
图7为本发明实施例公开的另一种MCU升级装置的结构示意图。
具体实施方式
在多MCU架构中,为简化MCU的升级流程,本领域技术人员又提出了一些其他的MCU升级方法,下面举例说明:
第一种方法
在MCU升级过程中,通过主MCU转发上位机与从MCU之间的升级指令和升级数据,使得上位机不需要直接通过串口连接从MCU,而只需要连接主MCU便可以对至少一个从MCU进行升级,从而简化了MCU的升级流程,提高了升级效率。
第二种方法
主MCU和各个从MCU连接,在主MCU上设置有SPI(Serial Peripheral Interface,串行外设接口)接口和与存储设备相匹配的存储设备接口,主MCU通过SPI接口与相匹配的SPI存储设备连接。在该方法中,多MCU之间通过串口进行通信,并通过外接的存储设备对多MCU进行统一升级,从而简化了MCU的升级流程,提高了升级效率。
然而,本申请的发明人在研究后发现,在第一种方法中,主MCU主要充当“网关”,其作用为:转发上位机与从MCU之间的升级指令和升级数据。但是,这种方法拉长了升级链路,从上位机到主MCU再到从MCU,每一条升级指令的发送与接收都要经过这三个组件,不仅数据的传输链路比较长,而且三个组件需要相互耦合在一起,从而强化了上位机的作用,弱化了主MCU的作用。并且,在远程升级场景中,并没有上位机,而是后台服务器。由于后台服务器仅仅是升级包的存储终端,因此,具体的升级控制应该都由主MCU去完成才更合理。
在第二种方法中,由于需要额外增加硬件存储设备,且该硬件存储设备仅用于MCU升级操作,因此增加了多MCU升级硬件成本,并造成了一定的资源浪费。
为简化MCU的升级流程,提高MCU的升级效率,本发明实施例公开了一种MCU升级方法及装置,该方法应用于多MCU架构下的主MCU,在多MCU架构下,一个主MCU和至少一个从MCU连接,本发明采用在各个MCU的APP层和驱动层之间,单独增加一层中间接口层的策略,通过中间接口层屏蔽MCU的底层硬件以及不同的通信方式,来应对MCU通信方式变化带来的升级包移植困扰,从而最大程度的复用APP层的上层业务,实现升级功能的快速移植。主MCU对获取的从MCU的升级包进行格式化统一处理得到升级数据,当从MCU由工作模式跳转至升级模式后,将对升级包进行解析得到的升级数据发送至对应的从MCU进行升级。本发明通过对各个从MCU的升级包进行格式化统一处理,使得各个从MCU均接收到相同格式的数据包,从而解决了各个从MCU的升级包格式差异的问题,简化了升级流程,进而提高了MCU的升级效率。
另外,由于本发明对获取的从MCU的升级包进行了格式化统一处理,因此可以使得各个从MCU有一个统一的升级流程,从而利于MCU功能扩展,后期也容易维护。
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
在多MCU架构中,为简化MCU的升级流程,本发明对主MCU和从MCU的软件架构进行了改进。
参见图1,本发明一实施例公开的一种主MCU和从MCU的软件架构示意图,其中,主MCU和从MCU的软件分层结构相同,软件分层结构依次包括:APP层(也即应用层)、中间接口层和驱动层,APP层位于顶层,驱动层位于底层。主MCU和从MCU之间通过驱动层进行信息交互,该驱动层可以实现的通信方式包括但不限于IIC、SPI和UART三种通信方式,只需要保证从MCU升级时,主MCU和从MCU之间能够唯一通信即可。相对于传统的MCU的软件分层结构,本发明在APP层和驱动层之间,单独增加了一层中间接口层,这样,APP层只需要按照双MCU通信方式,也即主MCU和从MCU之间的应用层通信方式,将APP层的数据内容填充完毕,并传输至中间接口层即可。APP层和中间接口层传输数据过程中,无需考虑通信方式,仅需要关注业务逻辑即可。
需要说明的是,本实施例中,中间接口层的作用为:屏蔽MCU的底层硬件以及通信方式,使上层业务不受影响。
当双MCU通信方式发生改变时,也即当主MCU和从MCU之间的通信方式发生改变时,只需要对中间接口层和驱动层之间的接口调用关系进行维护即可,这样可以最大程度的复用APP层的上层业务,实现升级功能的快速移植。
由此可以看出,本发明在多MCU架构下,采用在MCU的APP层和驱动层之间,单独增加一层中间接口层的策略,通过中间接口层屏蔽MCU的底层硬件以及不同的通信方式,来应对MCU通信方式变化带来的升级功能移植困扰,从而最大程度的复用APP层的上层业务,实现升级功能的快速移植。
需要说明的是,本发明除了对MCU的软件分层进行改进外,还对主MCU对从MCU的升级方法进行了改进。
参见图2,本发明一实施例公开的一种MCU升级方法流程图,该方法应用于图1中的主MCU,主MCU和至少一个从MCU连接,该方法包括步骤:
步骤S101、获取从MCU的升级包,并对该升级包进行解析,对格式进行统一化处理,得到升级数据;
需要说明的是,本实施例中对从MCU的升级包进行解析,对格式进行统一化处理后的格式可以依据实际需要而定,在实际应用中,该统一的格式可以是根据实际需要自定义的格式,本发明在此不做限定。
本领域技术人员可以理解,任何一个下载至Flash里的升级包,都可以看成由多个block组成,每个block是一个完整的数据块,每个block均有起始地址和长度,本实施例对从MCU的升级包进行解析,对格式进行统一化处理后,所得到的升级数据如图3所示,图3中的低地址为80000000-8000000F,高地址为8FFFFFF0-8FFFFFFF,在Flash地址空间中依次包括:block0,block1,block2...,每个block均有起始地址和长度,比如,图3中示出的block1起始地址,block1结束地址,其中,block1的长度根据block1起始地址和block1结束地址得到。
在实际应用中,主MCU从第三方,比如后台服务器,获取从MCU的升级包,该升级包可以是.bin、.s19、.hex等格式的文件,并对该升级包进行解析,对格式统一化处理,得到升级数据,以便于后续检索。
本发明之所以对升级包进行格式统一化处理,是因为对于每个MCU而言,需要下载至MCU的Flash里的数据是二进制的原始数据,因此,MCU只需要知晓数据下载至Flash中的起始位置、数据内容以及数据长度即可,而不同格式的升级包,其数据的表现形式不一样,因此,本发明对升级包进行了格式统一化处理。
其中,升级数据可以包括:block(块)总数量、每个block的起始地址和block长度等等。
步骤S102、向与升级数据对应的从MCU发送升级命令,使从MCU根据升级命令由工作模式跳转至升级模式;
需要说明的是,在实际应用中,主MCU与各从MCU之间的通信协议中包含了各个从MCU的标志符字段,不同的MCU具有不同且唯一的ID,主MCU预先知晓当前待升级的升级包(或者说升级数据)所对应的从MCU的ID,基于该ID,主MCU可以向与升级数据对应的从MCU发送升级指令,使得只有ID与升级数据对应从MCU可以根据该升级命令做出响应。
当主MCU对升级包进行解析,得到升级数据后,主MCU就会根据升级数据中包含的待升级从MCU的标志符,向与升级数据对应的从MCU发送升级命令,该升级命令也即跳转BT(Boot Loader,启动装载)命令,从MCU根据该升级命令,从当前的工作模式跳转至升级模式,以执行升级任务。
其中,从MCU的工作模式也即APP模式,升级模式也即BT模式。
为便于主MCU知晓从MCU是否已成功由工作模式跳转至升级模式,在实际应用中,当从MCU成功跳转至升级模式后,从MCU可以向主MCU发送一个确认信息作为应答信息。
反之,当从MCU未成功跳转至升级模式,从MCU可以不向主MCU发送任何信息,或是发送一个未成功跳转信息作为应答信息。
步骤S103、将升级数据发送至从MCU;
参见图1,在实际应用中,主MCU可以通过自身的驱动层将升级数据发送至从MCU的驱动层,从而实现主MCU和从MCU间的数据传输。
步骤S104、当接收到从MCU反馈的升级结果时,向从MCU发送跳转命令,使从MCU根据跳转命令由升级模式跳转至工作模式。
具体的,当从MCU将所有的升级数据均写入对应的Flash后,从MCU完成升级,在这种情况下,从MCU会向主MCU反馈升级结果,当主MCU接收到从MCU反馈的升级结果时,会向从MCU发送跳转命令,使从MCU根据跳转命令由升级模式跳转至工作模式。
为便于主MCU知晓从MCU是否已成功由升级模式跳转至工作模式,在实际应用中,当从MCU成功跳转至工作模式后,从MCU会向主MCU发送一个确认信息ACK(Acknowledgecharacter,确认字符)作为应答信息,至此升级流程结束。
理论上,在实际应用中,从MCU在升级完成后,可以自动由升级模式跳转至工作模式。本发明使从MCU在升级完成后不自动跳转至工作模式,而是在主MCU的控制下,跳转至工作模式的原因为:考虑到主MCU和从MCU后期可能的扩展功能,可能会增加一些其它的操作,比如,在从MCU中写一些重点信息等等,因此,控制从MCU在主MCU的控制下进行模式跳转。
为避免因为通信等原因,导致从MCU在升级完成后,长时间未接收到主MCU发送的跳转命令,而长时间停留在升级模式,本发明还增加了超时机制。当从MCU等待接收跳转命令的时间超过预设时间阈值时,从MCU主动由升级模式跳转至工作模式,以保证正常工作。
综上可知,本发明公开了一种MCU升级方法,该方法应用于多MCU架构下的主MCU,在多MCU架构下,一个主MCU和至少一个从MCU连接,本发明采用在各个MCU的APP层和驱动层之间,单独增加一层中间接口层的策略,通过中间接口层屏蔽MCU的底层硬件以及不同的通信方式,来应对MCU通信方式变化带来的升级包移植困扰,从而最大程度的复用APP层的上层业务,实现升级功能的快速移植。主MCU对获取的从MCU的升级包进行格式化统一处理得到升级数据,当从MCU由工作模式跳转至升级模式后,主MCU将对升级包进行解析得到的升级数据发送至对应的从MCU进行升级。本发明通过对各个从MCU的升级包进行格式化统一处理,使得各个从MCU均接收到相同格式的数据包,从而解决了各个从MCU的升级包格式差异的问题,简化了升级流程,进而提高了MCU的升级效率。
另外,由于本发明对获取的从MCU的升级包进行了格式化统一处理,因此可以使得各个从MCU有一个统一的升级流程,从而利于MCU功能扩展,后期也容易维护。
可以理解,在实际应用中,主MCU可以主动向从MCU发送升级数据,也可以从MCU主动向主MCU申请升级数据。在上述实施例中,优选从MCU主动向主MCU申请升级数据。
因此,为进一步优化上述实施例,步骤S103具体可以包括:
接收从MCU发送的升级请求;
根据升级请求将升级数据发送至从MCU。
其中,在实际应用中,主MCU并不是将所有的升级数据一次性全部发送至从MCU,而是由从MCU根据自身情况,多次向主MCU申请相同大小或是不同大小的数据包,主MCU根据从MCU申请的数据包大小向从MCU传输升级数据,传包过程由从MCU控制时序。从MCU每次将升级数据成功写入Flash后,都会再次向主MCU申请下一个升级数据,如此反复,直至获取到所有的升级数据。
需要说明的是,本发明优选从MCU主动向主MCU申请升级数据的原因为:主MCU的功能一般都比较强大,处理能力比较强,内存资源和存储资源比较丰富,而从MCU一般资源有限,无法一次性从主MCU接收大量的数据,并且,每个从MCU的性能和资源等可能存在差异,因此,从MCU根据自身情况,比如资源限制,处理能力限制等因素,主动向主MCU申请升级数据的设计会更加合理和灵活。
可以理解,从MCU在接收主MCU发送的升级数据之前,需要将Flash中用于放置升级数据的区间中的数据进行擦除。
因此,为进一步优化上述实施例,在步骤接收从MCU发送的升级请求之前,还可以包括:
向从MCU发送文件预览信息,使从MCU根据文件预览信息中包含的升级包信息确定升级数据在Flash中的存放区间,并将该存放区间中已存放的数据进行擦除。
具体的,当从MCU根据升级命令由工作模式跳转至升级模式后,主MCU会向从MCU发送文件预览信息,也即需要下载至从MCU的Flash中的信息,文件预览信息中包含升级包信息,升级包信息至少包括:block总数,每个block的下载地址、block长度等等信息,从MCU在接收到文件预览信息后,可以向主MCU发送一个应答信息,并能够根据文件预览信息即可确定当前升级包的类型,以及升级数据在Flash中的存放区间。从MCU在确定升级数据在Flash中的存放区间后,会将该存放区间中已存放的数据进行擦除,以便放置升级数据。
需要说明的是,双MCU通信协议中已经对传输的数据进行了CRC(CyclicRedundancy Check,循环冗余校验)校验,只有校验通过的数据才是有效的。因此,当从MCU根据自身情况,主动向主MCU申请升级数据,并将主MCU发送的升级数据直接写入对应的Flash区间,从MCU每次写完升级数据后,都会从Flash区间中回读刚刚写入的升级数据,并将回读数据与接收到的升级数据进行比较,当回读数据和接收到的升级数据一致时,才确定数据已成功写入,从而保证每次写入Flash区间中的数据均正确,在这种情况下,从MCU才会向主MCU申请下一个升级数据。
为便于理解从MCU的升级流程,参见图4,下面对主MCU和从MCU之间的交互流程进行详细阐述,如下:
主MCU获取从MCU的升级包,并对该升级包进行解析,对格式进行统一化处理,得到升级数据;
主MCU向与升级数据对应的从MCU发送升级命令,使从MCU根据升级命令由工作模式跳转至升级模式;
当从MCU成功跳转至升级模式后,从MCU会向主MCU发送一个确认信息作为应答信息;
主MCU向从MCU发送文件预览信息;
从MCU根据文件预览信息中包含的升级包信息确定升级数据在Flash中的存放区间,并将该存放区间中已存放的数据进行擦除,并向主MCU发送升级请求;
主MCU根据升级请求将升级数据发送至从MCU;
从MCU将升级数据存储至Flash中完成升级,向主MCU反馈的升级结果;
主MCU向从MCU发送跳转命令;
从MCU根据跳转命令由升级模式跳转至工作模式。
参见图5,本发明另一实施例公开了一种MCU升级方法流程图,该方法应用于图1中的从MCU,从MCU和主MCU连接,该方法包括步骤:
步骤S201、接收主MCU发送的升级命令;
当主MCU对升级包进行解析,得到升级数据后,主MCU就会根据升级数据中包含的待升级从MCU的标志符,向与升级数据对应的从MCU发送升级命令,该升级命令也即跳转BT(Boot Loader,启动装载)命令,从MCU根据该升级命令,从当前的工作模式跳转至升级模式,以执行升级任务。
其中,从MCU的工作模式也即APP模式,升级模式也即BT模式。
步骤S202、根据升级命令由工作模式跳转至升级模式;
为便于主MCU知晓从MCU是否已成功由工作模式跳转至升级模式,在实际应用中,当从MCU成功跳转至升级模式后,从MCU可以向主MCU发送一个确认信息作为应答信息。
反之,当从MCU未成功跳转至升级模式,从MCU可以不向主MCU发送任何信息,或是发送一个未成功跳转信息作为应答信息。
步骤S203、接收主MCU发送的升级数据;
其中,升级数据由主MCU对获取的从MCU的升级包进行解析,对格式进行统一化处理后得到。
其中,主MCU对从MCU的升级包进行统一化处理的过程可参见图2所示实施例对应部分,此处不再赘述。
步骤S204、根据升级数据进行升级,并在升级完成后将升级结果反馈至主MCU;
具体的,当从MCU将所有的升级数据均写入对应的Flash后,从MCU完成升级,在这种情况下,从MCU会向主MCU反馈升级结果,当主MCU接收到从MCU反馈的升级结果时,会向从MCU发送跳转命令,使从MCU根据跳转命令由升级模式跳转至工作模式。
步骤S205、接收主MCU发送的跳转命令;
步骤S206、根据跳转命令由升级模式跳转至工作模式。
理论上,在实际应用中,从MCU在升级完成后,可以自动由升级模式跳转至工作模式。本发明使从MCU在升级完成后不自动跳转至工作模式,而是在主MCU的控制下,跳转至工作模式的原因为:考虑到主MCU和从MCU后期可能的扩展功能,可能会增加一些其它的操作,比如,在从MCU中写一些重点信息等等,因此,控制从MCU在主MCU的控制下进行模式跳转。
综上可知,本发明公开了一种MCU升级方法,该方法应用于多MCU架构下的从MCU,在多MCU架构下,一个主MCU和至少一个从MCU连接,本发明采用在各个MCU的APP层和驱动层之间,单独增加一层中间接口层的策略,通过中间接口层屏蔽MCU的底层硬件以及不同的通信方式,来应对MCU通信方式变化带来的升级包移植困扰,从而最大程度的复用APP层的上层业务,实现升级功能的快速移植。从MCU根据主MCU发送的升级命令由工作模式跳转至升级模式,从MCU根据主MCU发送的升级数据进行升级,并将升级结果反馈至主MCU,升级数据由主MCU对获取的从MCU的升级包进行格式化统一处理得到,从MCU升级完成后,从MCU根据主MCU发送的跳转命令由升级模式跳转至工作模式。本发明通过对各个从MCU的升级包进行格式化统一处理,使得各个从MCU均接收到相同格式的数据包,从而解决了各个从MCU的升级包格式差异的问题,简化了升级流程,进而提高了MCU的升级效率。
另外,由于本发明对获取的从MCU的升级包进行了格式化统一处理,因此可以使得各个从MCU有一个统一的升级流程,从而利于MCU功能扩展,后期也容易维护。
在实际应用中,主MCU可以主动向从MCU发送升级数据,也可以从MCU主动向主MCU申请升级数据。在上述实施例中,步骤S203具体可以包括:
向主MCU发送升级请求;
接收主MCU发送的升级数据。
其中,在实际应用中,主MCU并不是将所有的升级数据一次性全部发送至从MCU,而是由从MCU根据自身情况,多次向主MCU申请相同大小或是不同大小的数据包,主MCU根据从MCU申请的数据包大小向从MCU传输升级数据,传包过程由从MCU控制时序。从MCU每次将升级数据成功写入Flash后,都会再次向主MCU申请下一个升级数据,如此反复,直至获取到所有的升级数据。
需要说明的是,本发明优选从MCU主动向主MCU申请升级数据的原因为:主MCU的功能一般都比较强大,处理能力比较强,内存资源和存储资源比较丰富,而从MCU一般资源有限,无法一次性从主MCU接收大量的数据,并且,每个从MCU的性能和资源等可能存在差异,因此,从MCU根据自身情况,比如资源限制,处理能力限制等因素,主动向主MCU申请升级数据的设计会更加合理和灵活。
可以理解,从MCU在接收主MCU发送的升级数据之前,需要将Flash中用于放置升级数据的区间中的数据进行擦除。
因此,为进一步优化上述实施例,在向主MCU发送升级请求之前,还可以包括:
接收主MCU发送的文件预览信息,其中,文件预览信息中包含升级包信息;
根据升级包信息确定升级数据在Flash中的存放区间,并将存放区间中已存放的数据进行擦除。
具体的,当从MCU根据升级命令由工作模式跳转至升级模式后,主MCU会向从MCU发送文件预览信息,也即需要下载至从MCU的Flash中的信息,文件预览信息中包含升级包信息,升级包信息至少包括:block总数,每个block的下载地址、block长度等等信息,从MCU在接收到文件预览信息后,可以向主MCU发送一个应答信息,并能够根据文件预览信息即可确定当前升级包的类型,以及升级数据在Flash中的存放区间。从MCU在确定升级数据在Flash中的存放区间后,会将该存放区间中已存放的数据进行擦除,以便放置升级数据。
需要说明的是,双MCU通信协议中已经对传输的数据进行了CRC(CyclicRedundancy Check,循环冗余校验)校验,只有校验通过的数据才是有效的。因此,当从MCU根据自身情况,主动向主MCU申请升级数据,并将主MCU发送的升级数据直接写入对应的Flash区间,从MCU每次写完升级数据后,都会从Flash区间中回读刚刚写入的升级数据,并将回读数据与接收到的升级数据进行比较,当回读数据和接收到的升级数据一致时,才确定数据已成功写入,从而保证每次写入Flash区间中的数据均正确,在这种情况下,从MCU才会向主MCU申请下一个升级数据。
因此,为进一步优化上述实施例,步骤S204具体可以包括:
将升级数据写入对应的Flash区间;
在将升级数据完全写入Flash区间后,从Flash区间中回读已写完的升级数据,并作为回读数据;
将回读数据与接收的升级数据进行比较;
当回读数据与升级数据的所有数据完全一致时,确定升级数据写入成功并生成升级结果;
将升级结果反馈至主MCU。
为避免因为通信等原因,导致从MCU在升级完成后,长时间未接收到主MCU发送的跳转命令,而长时间停留在升级模式,本发明还增加了超时机制。当从MCU等待接收跳转命令的时间超过预设时间阈值时,从MCU主动由升级模式跳转至工作模式,以保证正常工作。
因此,为进一步优化上述实施例,在步骤S204之后,可以包括:
当等待接收跳转命令的时间超过预设时间阈值时,主动由升级模式跳转至工作模式。
与上述方法实施例相对应,本发明还公开了一种MCU升级装置。
参见图6,本发明一实施例公开的一种MCU升级装置的结构示意图,该装置应用于图1中的主MCU,主MCU和至少一个从MCU连接,该装置包括:
解析单元301,用于获取从MCU的升级包,并对升级包进行解析,对格式进行统一化处理,得到升级数据;
需要说明的是,本实施例中对从MCU的升级包进行解析,对格式进行统一化处理后的格式可以依据实际需要而定,在实际应用中,该统一的格式可以是根据实际需要自定义的格式,本发明在此不做限定。
本发明之所以对升级包进行格式统一化处理,是因为对于每个MCU而言,需要下载至MCU的Flash里的数据是二进制的原始数据,因此,MCU只需要知晓数据下载至Flash中的起始位置、数据内容以及数据长度即可,而不同格式的升级包,其数据的表现形式不一样,因此,本发明对升级包进行了格式统一化处理。
升级命令发送单元302,用于向与升级数据对应的从MCU发送升级命令,使从MCU根据升级命令由工作模式跳转至升级模式;
需要说明的是,在实际应用中,主MCU与各从MCU之间的通信协议中包含了各个从MCU的标志符字段,不同的MCU具有不同且唯一的ID,主MCU预先知晓当前待升级的升级包(或者说升级数据)所对应的从MCU的ID,基于该ID,主MCU可以向与升级数据对应的从MCU发送升级指令,使得只有ID与升级数据对应从MCU可以根据该升级命令做出响应。
当主MCU对升级包进行解析,得到升级数据后,主MCU就会根据升级数据中包含的待升级从MCU的标志符,向与升级数据对应的从MCU发送升级命令,该升级命令也即跳转BT(Boot Loader,启动装载)命令,从MCU根据该升级命令,从当前的工作模式跳转至升级模式,以执行升级任务。
其中,从MCU的工作模式也即APP模式,升级模式也即BT模式。
为便于主MCU知晓从MCU是否已成功由工作模式跳转至升级模式,在实际应用中,当从MCU成功跳转至升级模式后,从MCU可以向主MCU发送一个确认信息作为应答信息。
反之,当从MCU未成功跳转至升级模式,从MCU可以不向主MCU发送任何信息,或是发送一个未成功跳转信息作为应答信息。
数据发送单元303,用于将升级数据发送至从MCU;
参见图1,在实际应用中,主MCU可以通过自身的驱动层将升级数据发送至从MCU的驱动层,从而实现主MCU和从MCU间的数据传输。
跳转命令发送单元304,用于当接收到从MCU反馈的升级结果时,向从MCU发送跳转命令,使从MCU根据跳转命令由升级模式跳转至工作模式。
具体的,当从MCU将所有的升级数据均写入对应的Flash后,从MCU完成升级,在这种情况下,从MCU会向主MCU反馈升级结果,当主MCU接收到从MCU反馈的升级结果时,会向从MCU发送跳转命令,使从MCU根据跳转命令由升级模式跳转至工作模式。
为便于主MCU知晓从MCU是否已成功由升级模式跳转至工作模式,在实际应用中,当从MCU成功跳转至工作模式后,从MCU会向主MCU发送一个确认信息ACK(Acknowledgecharacter,确认字符)作为应答信息,至此升级流程结束。
为避免因为通信等原因,导致从MCU在升级完成后,长时间未接收到主MCU发送的跳转命令,而长时间停留在升级模式,本发明还增加了超时机制。当从MCU等待接收跳转命令的时间超过预设时间阈值时,从MCU主动由升级模式跳转至工作模式,以保证正常工作。
综上可知,本发明公开了一种MCU升级装置,该装置应用于多MCU架构下的主MCU,在多MCU架构下,一个主MCU和至少一个从MCU连接,本发明采用在各个MCU的APP层和驱动层之间,单独增加一层中间接口层的策略,通过中间接口层屏蔽MCU的底层硬件以及不同的通信方式,来应对MCU通信方式变化带来的升级包移植困扰,从而最大程度的复用APP层的上层业务,实现升级功能的快速移植。主MCU对获取的从MCU的升级包进行格式化统一处理得到升级数据,当从MCU由工作模式跳转至升级模式后,主MCU将对升级包进行解析得到的升级数据发送至对应的从MCU进行升级。本发明通过对各个从MCU的升级包进行格式化统一处理,使得各个从MCU均接收到相同格式的数据包,从而解决了各个从MCU的升级包格式差异的问题,简化了升级流程,进而提高了MCU的升级效率。
另外,由于本发明对获取的从MCU的升级包进行了格式化统一处理,因此可以使得各个从MCU有一个统一的升级流程,从而利于MCU功能扩展,后期也容易维护。
可以理解,在实际应用中,主MCU可以主动向从MCU发送升级数据,也可以从MCU主动向主MCU申请升级数据。在上述实施例中,优选从MCU主动向主MCU申请升级数据。
因此,为进一步优化上述实施例,数据发送单元303具体用于:
接收从MCU发送的升级请求;
根据升级请求将升级数据发送至从MCU。
其中,在实际应用中,主MCU并不是将所有的升级数据一次性全部发送至从MCU,而是由从MCU根据自身情况,多次向主MCU申请相同大小或是不同大小的数据包,主MCU根据从MCU申请的数据包大小向从MCU传输升级数据,传包过程由从MCU控制时序。从MCU每次将升级数据成功写入Flash后,都会再次向主MCU申请下一个升级数据,如此反复,直至获取到所有的升级数据。
可以理解,从MCU在接收主MCU发送的升级数据之前,需要将Flash中用于放置升级数据的区间中的数据进行擦除。
因此,为进一步优化上述实施例,数据发送单元303具体还用于:
在接收从MCU发送的升级请求之前,向从MCU发送文件预览信息,使从MCU根据文件预览信息中包含的升级包信息确定升级数据在Flash中的存放区间,并将该存放区间中已存放的数据进行擦除。
具体的,当从MCU根据升级命令由工作模式跳转至升级模式后,主MCU会向从MCU发送文件预览信息,也即需要下载至从MCU的Flash中的信息,文件预览信息中包含升级包信息,升级包信息至少包括:block总数,每个block的下载地址、block长度等等信息,从MCU在接收到文件预览信息后,可以向主MCU发送一个应答信息,并能够根据文件预览信息即可确定当前升级包的类型,以及升级数据在Flash中的存放区间。从MCU在确定升级数据在Flash中的存放区间后,会将该存放区间中已存放的数据进行擦除,以便放置升级数据。
参见图7,本发明另一实施例公开的一种MCU升级装置的结构示意图,该装置应用于图1中的从MCU,从MCU和主MCU连接,该装置包括
升级命令接收单元401,用于接收主MCU发送的升级命令;
当主MCU对升级包进行解析,得到升级数据后,主MCU就会根据升级数据中包含的待升级从MCU的标志符,向与升级数据对应的从MCU发送升级命令,该升级命令也即跳转BT(Boot Loader,启动装载)命令,从MCU根据该升级命令,从当前的工作模式跳转至升级模式,以执行升级任务。
第一跳转单元402,用于根据升级命令由工作模式跳转至升级模式;
为便于主MCU知晓从MCU是否已成功由工作模式跳转至升级模式,在实际应用中,当从MCU成功跳转至升级模式后,从MCU可以向主MCU发送一个确认信息作为应答信息。
反之,当从MCU未成功跳转至升级模式,从MCU可以不向主MCU发送任何信息,或是发送一个未成功跳转信息作为应答信息。
数据接收单元403,用于接收主MCU发送的升级数据,升级数据由主MCU对获取的从MCU的升级包进行解析,对格式进行统一化处理后得到;
其中,主MCU对从MCU的升级包进行统一化处理的过程可参见图2所示实施例对应部分,此处不再赘述。
升级单元404,用于根据升级数据进行升级,并在升级完成后将升级结果反馈至主MCU;
具体的,当从MCU将所有的升级数据均写入对应的Flash后,从MCU完成升级,在这种情况下,从MCU会向主MCU反馈升级结果,当主MCU接收到从MCU反馈的升级结果时,会向从MCU发送跳转命令,使从MCU根据跳转命令由升级模式跳转至工作模式。
跳转命令接收单元405,用于接收主MCU发送的跳转命令;
第二跳转单元406,用于根据跳转命令由升级模式跳转至工作模式。
理论上,在实际应用中,从MCU在升级完成后,可以自动由升级模式跳转至工作模式。本发明使从MCU在升级完成后不自动跳转至工作模式,而是在主MCU的控制下,跳转至工作模式的原因为:考虑到主MCU和从MCU后期可能的扩展功能,可能会增加一些其它的操作,比如,在从MCU中写一些重点信息等等,因此,控制从MCU在主MCU的控制下进行模式跳转。
综上可知,本发明公开了一种MCU升级装置,该装置应用于多MCU架构下的从MCU,在多MCU架构下,一个主MCU和至少一个从MCU连接,本发明采用在各个MCU的APP层和驱动层之间,单独增加一层中间接口层的策略,通过中间接口层屏蔽MCU的底层硬件以及不同的通信方式,来应对MCU通信方式变化带来的升级包移植困扰,从而最大程度的复用APP层的上层业务,实现升级功能的快速移植。从MCU根据主MCU发送的升级命令由工作模式跳转至升级模式,从MCU根据主MCU发送的升级数据进行升级,并将升级结果反馈至主MCU,升级数据由主MCU对获取的从MCU的升级包进行格式化统一处理得到,从MCU升级完成后,从MCU根据主MCU发送的跳转命令由升级模式跳转至工作模式。本发明通过对各个从MCU的升级包进行格式化统一处理,使得各个从MCU均接收到相同格式的数据包,从而解决了各个从MCU的升级包格式差异的问题,简化了升级流程,进而提高了MCU的升级效率。
另外,由于本发明对获取的从MCU的升级包进行了格式化统一处理,因此可以使得各个从MCU有一个统一的升级流程,从而利于MCU功能扩展,后期也容易维护。
在实际应用中,主MCU可以主动向从MCU发送升级数据,也可以从MCU主动向主MCU申请升级数据。在上述实施例中,数据接收单元403具体可以用于:
向主MCU发送升级请求;
接收主MCU发送的升级数据。
其中,在实际应用中,主MCU并不是将所有的升级数据一次性全部发送至从MCU,而是由从MCU根据自身情况,多次向主MCU申请相同大小或是不同大小的数据包,主MCU根据从MCU申请的数据包大小向从MCU传输升级数据,传包过程由从MCU控制时序。从MCU每次将升级数据成功写入Flash后,都会再次向主MCU申请下一个升级数据,如此反复,直至获取到所有的升级数据。
可以理解,从MCU在接收主MCU发送的升级数据之前,需要将Flash中用于放置升级数据的区间中的数据进行擦除。
因此,为进一步优化上述实施例,数据接收单元403还可以用于:
在向主MCU发送升级请求之前,接收主MCU发送的文件预览信息,其中,文件预览信息中包含升级包信息;
根据升级包信息确定升级数据在Flash中的存放区间,并将存放区间中已存放的数据进行擦除。
具体的,当从MCU根据升级命令由工作模式跳转至升级模式后,主MCU会向从MCU发送文件预览信息,也即需要下载至从MCU的Flash中的信息,文件预览信息中包含升级包信息,升级包信息至少包括:block总数,每个block的下载地址、block长度等等信息,从MCU在接收到文件预览信息后,可以向主MCU发送一个应答信息,并能够根据文件预览信息即可确定当前升级包的类型,以及升级数据在Flash中的存放区间。从MCU在确定升级数据在Flash中的存放区间后,会将该存放区间中已存放的数据进行擦除,以便放置升级数据。
为进一步优化上述实施例,升级单元404具体可以用于:
将升级数据写入对应的Flash区间;
在将升级数据完全写入Flash区间后,从Flash区间中回读已写完的升级数据,并作为回读数据;
将回读数据与接收的升级数据进行比较;
当回读数据与升级数据的所有数据完全一致时,确定升级数据写入成功并生成升级结果;
将升级结果反馈至主MCU。
为避免因为通信等原因,导致从MCU在升级完成后,长时间未接收到主MCU发送的跳转命令,而长时间停留在升级模式,本发明还增加了超时机制。当从MCU等待接收跳转命令的时间超过预设时间阈值时,从MCU主动由升级模式跳转至工作模式,以保证正常工作。
因此,为进一步优化上述实施例,MCU升级装置还可以包括:
主动跳转单元,用于在升级单元404根据升级数据进行升级,并在升级完成后将升级结果反馈至主MCU之后,当等待接收跳转命令的时间超过预设时间阈值时,主动由升级模式跳转至工作模式。
需要特别说明的是,装置实施例中各组成部分的具体工作原理,请参见方法实施例对应部分,此处不再赘述。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
Claims (10)
1.一种MCU升级方法,其特征在于,应用于主MCU,所述主MCU和至少一个从MCU连接,所述主MCU和所述从MCU均包括:APP层、中间接口层和驱动层,所述中间接口层位于所述APP层和所述驱动层之间,用于屏蔽MCU的底层硬件以及不同的通信方式,所述方法包括:
获取所述从MCU的升级包,并对所述升级包进行解析,对格式进行统一化处理,得到升级数据;
向与所述升级数据对应的所述从MCU发送升级命令,使所述从MCU根据所述升级命令由工作模式跳转至升级模式;
将所述升级数据发送至所述从MCU;
当接收到所述从MCU反馈的升级结果时,向所述从MCU发送跳转命令,使所述从MCU根据所述跳转命令由所述升级模式跳转至所述工作模式。
2.根据权利要求1所述的方法,其特征在于,所述将所述升级数据发送至所述从MCU,具体包括:
接收所述从MCU发送的升级请求;
根据所述升级请求将所述升级数据发送至所述从MCU。
3.根据权利要求2所述的方法,其特征在于,在所述接收所述从MCU发送的升级请求之前,还包括:
向所述从MCU发送文件预览信息,使所述从MCU根据所述文件预览信息中包含的升级包信息确定升级数据在Flash中的存放区间,并将所述存放区间中已存放的数据进行擦除。
4.一种MCU升级方法,其特征在于,应用于从MCU,所述从MCU与主MCU连接,所述主MCU和所述从MCU均包括:APP层、中间接口层和驱动层,所述中间接口层位于所述APP层和所述驱动层之间,用于屏蔽MCU的底层硬件以及不同的通信方式,所述方法包括:
接收所述主MCU发送的升级命令;
根据所述升级命令由工作模式跳转至升级模式;
接收所述主MCU发送的升级数据,所述升级数据由所述主MCU对获取的所述从MCU的升级包进行解析,对格式进行统一化处理后得到;
根据所述升级数据进行升级,并在升级完成后将升级结果反馈至所述主MCU;
接收所述主MCU发送的跳转命令;
根据所述跳转命令由所述升级模式跳转至所述工作模式。
5.根据权利要求4所述的方法,其特征在于,所述接收所述主MCU发送的升级数据,具体包括:
向所述主MCU发送升级请求;
接收所述主MCU发送的所述升级数据。
6.根据权利要求5所述的方法,其特征在于,在所述向所述主MCU发送升级请求之前,还包括:
接收所述主MCU发送的文件预览信息,所述文件预览信息中包含升级包信息;
根据所述升级包信息确定升级数据在Flash中的存放区间,并将所述存放区间中已存放的数据进行擦除。
7.根据权利要求4所述的方法,其特征在于,所述根据所述升级数据进行升级,并在升级完成后将升级结果反馈至所述主MCU,具体包括:
将所述升级数据写入对应的Flash区间;
在将所述升级数据完全写入所述Flash区间后,从所述Flash区间中回读已写完的所述升级数据,并作为回读数据;
将所述回读数据与接收的所述升级数据进行比较;
当所述回读数据与所述升级数据的所有数据完全一致时,确定所述升级数据写入成功并生成所述升级结果;
将所述升级结果反馈至所述主MCU。
8.根据权利要求4所述的方法,其特征在于,在所述根据所述升级数据进行升级,并在升级完成后将升级结果反馈至所述主MCU之后,还包括:
当等待接收所述跳转命令的时间超过预设时间阈值时,主动由所述升级模式跳转至所述工作模式。
9.一种MCU升级装置,其特征在于,应用于主MCU,所述主MCU和至少一个从MCU连接,所述主MCU和所述从MCU均包括:APP层、中间接口层和驱动层,所述中间接口层位于所述APP层和所述驱动层之间,用于屏蔽MCU的底层硬件以及不同的通信方式,所述装置包括:
解析单元,用于获取所述从MCU的升级包,并对所述升级包进行解析,对格式进行统一化处理,得到升级数据;
升级命令发送单元,用于向与所述升级数据对应的所述从MCU发送升级命令,使所述从MCU根据所述升级命令由工作模式跳转至升级模式;
数据发送单元,用于将所述升级数据发送至所述从MCU;
跳转命令发送单元,用于当接收到所述从MCU反馈的升级结果时,向所述从MCU发送跳转命令,使所述从MCU根据所述跳转命令由所述升级模式跳转至所述工作模式。
10.一种MCU升级装置,其特征在于,应用于从MCU,所述从MCU与主MCU连接,所述主MCU和所述从MCU均包括:APP层、中间接口层和驱动层,所述中间接口层位于所述APP层和所述驱动层之间,用于屏蔽MCU的底层硬件以及不同的通信方式,所述装置包括:
升级命令接收单元,用于接收所述主MCU发送的升级命令;
第一跳转单元,用于根据所述升级命令由工作模式跳转至升级模式;
数据接收单元,用于接收所述主MCU发送的升级数据,所述升级数据由所述主MCU对获取的所述从MCU的升级包进行解析,对格式进行统一化处理后得到;
升级单元,用于根据所述升级数据进行升级,并在升级完成后将升级结果反馈至所述主MCU;
跳转命令接收单元,用于接收所述主MCU发送的跳转命令;
第二跳转单元,用于根据所述跳转命令由所述升级模式跳转至所述工作模式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010238099.4A CN111459519A (zh) | 2020-03-30 | 2020-03-30 | 一种mcu升级方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010238099.4A CN111459519A (zh) | 2020-03-30 | 2020-03-30 | 一种mcu升级方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111459519A true CN111459519A (zh) | 2020-07-28 |
Family
ID=71679283
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010238099.4A Pending CN111459519A (zh) | 2020-03-30 | 2020-03-30 | 一种mcu升级方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111459519A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112596763A (zh) * | 2020-12-17 | 2021-04-02 | 青岛海信电子产业控股股份有限公司 | 一种智能家居设备无线升级的方法和装置及设备 |
CN117170704A (zh) * | 2023-08-21 | 2023-12-05 | 南京智谱科技有限公司 | 基于硬件iic的远程升级方法和装置 |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102063318A (zh) * | 2010-12-22 | 2011-05-18 | Tcl通力电子(惠州)有限公司 | 一种供电mcu的升级方法 |
CN103279371A (zh) * | 2013-05-22 | 2013-09-04 | 杭州电子科技大学 | 一种分布式控制***多从机程序在线同步升级的方法 |
CN104102518A (zh) * | 2014-07-23 | 2014-10-15 | 江苏兆伏新能源有限公司 | 一种双cpu***及其程序升级方法 |
CN104375855A (zh) * | 2014-09-24 | 2015-02-25 | 深圳市航盛电子股份有限公司 | 一种基于车载多mcu通过存储设备升级固件的装置及方法 |
CN104423984A (zh) * | 2013-08-29 | 2015-03-18 | 比亚迪股份有限公司 | 在线升级方法和在线升级*** |
WO2018045700A1 (zh) * | 2016-09-07 | 2018-03-15 | 中兴通讯股份有限公司 | 一种车载自动诊断***设备及其升级方法 |
CN107894900A (zh) * | 2017-12-06 | 2018-04-10 | 郑州云海信息技术有限公司 | 一种mcu升级的方法及*** |
CN108334373A (zh) * | 2017-10-16 | 2018-07-27 | 深圳市路畅科技股份有限公司 | 一种多mcu升级的方法及*** |
CN109491681A (zh) * | 2018-10-19 | 2019-03-19 | 北京经纬恒润科技有限公司 | 一种汽车内mcu的升级方法及装置 |
CN110549871A (zh) * | 2019-10-17 | 2019-12-10 | 吉林大学 | 一种基于分布式驱动车辆的整车控制器及控制方法 |
-
2020
- 2020-03-30 CN CN202010238099.4A patent/CN111459519A/zh active Pending
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102063318A (zh) * | 2010-12-22 | 2011-05-18 | Tcl通力电子(惠州)有限公司 | 一种供电mcu的升级方法 |
CN103279371A (zh) * | 2013-05-22 | 2013-09-04 | 杭州电子科技大学 | 一种分布式控制***多从机程序在线同步升级的方法 |
CN104423984A (zh) * | 2013-08-29 | 2015-03-18 | 比亚迪股份有限公司 | 在线升级方法和在线升级*** |
CN104102518A (zh) * | 2014-07-23 | 2014-10-15 | 江苏兆伏新能源有限公司 | 一种双cpu***及其程序升级方法 |
CN104375855A (zh) * | 2014-09-24 | 2015-02-25 | 深圳市航盛电子股份有限公司 | 一种基于车载多mcu通过存储设备升级固件的装置及方法 |
WO2018045700A1 (zh) * | 2016-09-07 | 2018-03-15 | 中兴通讯股份有限公司 | 一种车载自动诊断***设备及其升级方法 |
CN108334373A (zh) * | 2017-10-16 | 2018-07-27 | 深圳市路畅科技股份有限公司 | 一种多mcu升级的方法及*** |
CN107894900A (zh) * | 2017-12-06 | 2018-04-10 | 郑州云海信息技术有限公司 | 一种mcu升级的方法及*** |
CN109491681A (zh) * | 2018-10-19 | 2019-03-19 | 北京经纬恒润科技有限公司 | 一种汽车内mcu的升级方法及装置 |
CN110549871A (zh) * | 2019-10-17 | 2019-12-10 | 吉林大学 | 一种基于分布式驱动车辆的整车控制器及控制方法 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112596763A (zh) * | 2020-12-17 | 2021-04-02 | 青岛海信电子产业控股股份有限公司 | 一种智能家居设备无线升级的方法和装置及设备 |
CN117170704A (zh) * | 2023-08-21 | 2023-12-05 | 南京智谱科技有限公司 | 基于硬件iic的远程升级方法和装置 |
CN117170704B (zh) * | 2023-08-21 | 2024-04-30 | 南京智谱科技有限公司 | 基于硬件iic的远程升级方法和装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109828935B (zh) | 一种基于can fd总线的并行刷写方法 | |
US20200310782A1 (en) | Gateway device, in-vehicle network system, and firmware update method | |
CN107976986B (zh) | 用于对车辆电子控制模块编程的方法 | |
CN107209644B (zh) | 一种数据处理方法以及NVMe存储器 | |
CN111163179A (zh) | 汽车终端电控模块软件远程升级的***及方法 | |
US20240053977A1 (en) | Gateway device, in-vehicle network system, and firmware update method | |
WO2004079565A3 (en) | Method for providing a software module to an automotive vehicle control unit, and computer program for executing the method | |
US7684926B2 (en) | Electronic control apparatus having first microcomputer which forwards externally supplied updating data to a second microcomputer having a lower data receiving performance than the first microcomputer | |
CN111459519A (zh) | 一种mcu升级方法及装置 | |
WO2024007987A1 (zh) | 数字钥匙***的车端固件升级方法、装置、设备及介质 | |
CN113094072A (zh) | 车辆升级方法、装置、电子装置及存储介质 | |
CN114363385A (zh) | 一种云端更新汽车端软件的方法、***、设备及存储介质 | |
CN116578524B (zh) | 多核控制器、控制方法、车辆控制***及可读存储介质 | |
CN112925551A (zh) | 对象升级方法、装置、设备和存储介质 | |
CN113448596A (zh) | 一种车辆控制器刷写***、方法及相关设备 | |
CN108989428B (zh) | 蓝牙终端升级方法、服务器、计算机可读存储介质及*** | |
CN115695077A (zh) | 一种总线数据接收方法、装置、电子设备及存储介质 | |
CN115277671A (zh) | 车辆的ota升级方法、装置、车辆及存储介质 | |
CN115080085A (zh) | 一种用以解决oem中eol标定的方法及*** | |
CN114666329B (zh) | 一种app管理方法、智能终端及计算机可读存储介质 | |
CN112511609B (zh) | 数据传输方法、装置及存储介质 | |
CN114706526A (zh) | 云原生存储数据卷的自动扩容方法、***及设备 | |
CN107171824B (zh) | 一种终端的wifi断线处理方法、终端及存储装置 | |
KR100666712B1 (ko) | 푸시 에이전트 서비스 장치 및 방법, 그리고 이를 수용한개방형 모바일 비즈니스 지원 시스템 | |
CN116466973B (zh) | 一种多并发固件升级方法、***、计算机设备及存储介质 |
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 | ||
CB02 | Change of applicant information |
Address after: 4 / F, building 1, No.14 Jiuxianqiao Road, Chaoyang District, Beijing 100020 Applicant after: Beijing Jingwei Hirain Technologies Co.,Inc. Address before: 8 / F, block B, No. 11, Anxiang Beili, Chaoyang District, Beijing 100101 Applicant before: Beijing Jingwei HiRain Technologies Co.,Ltd. |
|
CB02 | Change of applicant information |