首页 / 车载芯片的升级方法、升级装置、控制器和存储介质

车载芯片的升级方法、升级装置、控制器和存储介质实质审查 发明

技术领域

[0001] 本申请涉及车载设备技术领域,特别是涉及一种车载芯片的升级方法、车载芯片的升级装置、整车控制器、计算机可读存储介质和计算机程序产品。

相关背景技术

[0002] 伴随着人们对汽车功能的不断追求,车载芯片的升级也成为智能汽车的常见功能。以对ECU(Electronic Control Unit,电子控制单元)的交换芯片进行升级为例,常见的升级方法是利用MCU(Microcontroller Unit,微控制单元)接入上位机电脑接口,并利用CAN(Controller AreaNetwork,控制器域网)从上位机电脑获取交换芯片的升级数据进行升级,或者针对需要升级的交换芯片,各自插入下载有升级包的U盘分别升级。
[0003] 然而,在当前对交换芯片进行升级的方式中,需要在上位机电脑上安装专门的升级工具、配备专门的升级线缆,且需要对操作(售后)人员的进行额外的技能培训等,从而增加了企业的管理成本,以及额外连接线缆和软件操作也会增加出错概率,导致芯片升级的效率较低和成功率不高。

具体实施方式

[0060] 为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
[0061] 本申请实施例中的术语“和/或”指的是包括相关联的列举项目中的一个或多个的任何和全部的可能组合。还要说明的是:当用在本说明书中时,“包括/包含”指定所陈述的特征、整数、步骤、操作、元件和/或组件的存在,但是不排除一个或多个其他特征、整数、步骤、操作、元件和/或组件和/或它们的组群的存在或添加。
[0062] 本申请中的术语“第一”、“第二”等是用于区别不同对象,而不是用于描述特定顺序。此外,术语“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
[0063] 另外,本申请中尽管多次采用术语“第一”、“第二”等来描述各种操作(或各种元件或各种应用或各种指令或各种数据)等,不过这些操作(或元件或应用或指令或数据)不应受这些术语的限制。这些术语只是用于区分一个操作(或元件或应用或指令或数据)和另一个操作(或元件或应用或指令或数据)。
[0064] 本申请实施例提供的车载芯片的升级方法,可以应用于如图1所示的应用环境中。其中,终端102通过通信网络与服务器104进行通信。数据存储系统可以存储服务器104需要处理的数据。数据存储系统可以集成在服务器104上,也可以放在云上或其他网络服务器上。
[0065] 在一些实施例中,参考图1,服务器104响应触发用于升级车载芯片的启动程序,下载携带有应用程序数据和Switch固件数据的升级文件包到Flash存储器中;其中,应用程序数据用于对Flash存储器中待升级的应用程序进行升级;在应用程序升级完成后,获取用于升级车载芯片中的Switch固件的第一类例程控制数据;基于第一类例程控制数据调用预设的功能接口,以将Switch固件数据从Flash存储器写入到车载芯片中,以对Switch固件进行升级。
[0066] 在一些实施例中,终端102(如移动终端、固定终端)可以以各种形式来实施。其中,终端102可为包括诸如移动电话、智能电话、笔记本电脑、便携式手持式设备、个人数字助理(PDA,Personal Digital Assistant)、平板电脑(PAD)等等的移动终端,终端102也可以是自动柜员机(Automated Teller Machine,ATM)、自动一体机、数字TV、台式计算机、固式计算机等等的固定终端。
[0067] 下面,假设终端102是固定终端。然而,本领域技术人员将理解的是,若有特别用于移动目的的操作或者元件,根据本申请公开的实施方式的构造也能够应用于移动类型的终端102。
[0068] 在一些实施例中,服务器104运行的数据处理组件可以加载正在被执行的可以包括各种附加服务器应用和/或中间层应用中的任何一种,如包括HTTP(超文本传输协议)、FTP(文件传输协议)、CGI(通用网关界面)、RDBMS(关系型数据库管理系统)等。
[0069] 在一些实施例中,服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。服务器104可以适于运行提供前述公开中描述的终端102的一个或多个应用服务或软件组件。
[0070] 在一些实施例中,应用服务或软件组件运行的操作系统可以包括各种版本的Microsoft Windows®、Apple Macintosh®和/或Linux操作系统、各种商用或类UNIX®操作系统(包括但不限于各种GNU/Linux操作系统、Google Chrome®OS等)和/或移动操作系统,诸如iOS®、Windows®Phone、Android®OS、BlackBerry®OS、Palm®OS操作系统,以及其它在线操作系统或者离线操作系统,在这里不做具体的限制。
[0071] 在一些实施例中,本申请提供的车载芯片的升级方法应用于该车载芯片的升级系统中,且该车载芯片的升级系统用于被服务器104所控制,以执行车载芯片的升级方法。参考图2,图2为根据一示例性实施例示出的一种车载芯片的升级系统的结构框图。
[0072] 如图2所示,该车载芯片的升级系统包括诊断设备和ECU(Electronic Control Unit,电子控制单元),其中,在ECU中配置有MCU(Microcontroller Unit,微控制单元)和交换芯片(例如,Switch芯片)。
[0073] 在一实施例中,诊断设备通过CAN(Controller AreaNetwork,控制器域网)总线连接于ECU中的MCU,MCU又与交换芯片相连接,从而诊断设备可以通过CAN总线将升级数据传输到MCU的Flash存储器中存储,MCU又可以将升级数据写入到交换芯片的Switch固件中存储。
[0074] 在一些实施例中,CAN总线包括CAN_H线和CAN_L线。其中,CAN_H线和CAN_L线分别代表CAN总线中的高电平线和低电平线。CAN总线使用不平衡的差分信号传输,CAN_H线和CAN_L线之间的电压差决定了数据的传输状态。例如,CAN_H线和CAN_L线之间的电压差可以为2.5V,当CAN_H线比CAN_L线高时表示逻辑1,当CAN_H线比CAN_L线高时表示逻辑0。
[0075] 在一些实施例中,在交换芯片中的Switch固件可以是一些用于控制开关功能的软件程序。其中,特定的引脚可以配置为数字输入或输出,并且可以通过Switch固件来控制这些引脚的状态。Switch固件可以实现对引脚的配置、读取和控制,从而实现与外部设备的交互和通信。通过Switch固件,可以实现交换芯片与外部开关、按钮、传感器等设备的连接和控制,从而扩展交换芯片的功能和应用领域。因此,Switch固件在交换芯片中可以起着类似于控制开关的作用,帮助实现系统的功能和交互。
[0076] 在一些实施例中,在MCU中的Flash存储器是一种非易失性存储器,其用于存储程序代码和数据。其中,Flash存储器通常用来存储一些程序代码(例如,用于升级应用程序的应用程序数据和升级交换芯片的Switch固件数据),以便MCU能够执行特定的功能。在一些实施例中,Flash存储器具有快速读取和擦除的特性,从而可以对存储的程序代码频繁地读取和更新,例如将Switch固件数据从Flash存储器中写入到交换芯片中。
[0077] 参考图3,图3为根据一示例性实施例示出的一种Flash存储器的结构框图。其中,在Flash存储器中预先划分有多个flash区域,以用于存储不同的数据,以及该多个flash区域分别被设置有对应不同的区域地址(例如高地址和低地址),以将不同的存储空间划分为不同的flash区域,并分别设置它们的起始地址和结束地址。
[0078] 如图3所示,在Flash存储器中预先将存储空间划分为启动文件区域、参数区域、应用程序区域、应用程序备份区域、日志区域,以及该应用程序区域和应用程序备份区域再划分成应用程序区域、switch固件区域、文件校验区域。
[0079] 其中,启动文件区域主要负责对MCU的应用程序进行升级更新;参数区域存放应用程序的起始地址、switch固件的起始地址、校验数据的起始地址等相关信息;应用程序区域存放当前升级的应用程序数据;备份应用程序区域存放升级之前的应用程序数据;日志区域应用程序运行过程中的异常运行信息。
[0080] 在一些实施例中,启动文件区域、参数区域、应用程序区域、应用程序备份区域、日志区域配置还可以由低到高的依次配置有对应的区域地址(区域地址包括起始地址和结束地址),即启动文件区域、参数区域、应用程序区域、应用程序备份区域、日志区域分别按照预设的区域地址由低到高进行排列。
[0081] 在实际应用中,可以通过设置寄存器或配置文件来指定每个flash区域的起始地址和结束地址。这样,MCU在访问存储空间时就可以根据地址范围来确定数据或程序存储在哪个flash区域中。例如,针对启动文件区域和日志区域,启动文件区域用于存储启动程序代码,日志区域用于存储日志数据,从而可以将启动文件区域设置为低地址范围,而日志区域设置为高地址范围,以便MCU能够在程序中更轻松地访问和管理这两个不同类型的数据。
[0082] 在一些实施例中,诊断设备通过UDS(统一诊断服务)协议与ECU中的MCU进行通信。其中,UDS协议是一种用于汽车维修和诊断的标准化服务。UDS协议定义了ECU与诊断设备之间的通信标准,使诊断设备能够与车辆的各种MCU进行通信,例如switch芯片升级、读取故障码、实时数据等信息,并进行诊断和维修操作。
[0083] 在一些实施例中,本申请中的UDS协议可以包括以下功能:
[0084] 读取故障码:诊断设备可以读取车辆各个MCU存储的故障码,帮助定位问题所在。
[0085] 清除故障码:诊断设备可以清除MCU中存储的故障码,重置车辆的故障状态。
[0086] 读取实时数据:诊断设备可以读取车辆各个MCU的实时数据,如发动机转速、车速等,帮助进行故障诊断。
[0087] 控制单元编程:诊断设备可以对车辆的MCU进行编程和配置,更新软件版本等操作。
[0088] 在一些实施例中,诊断设备可以基于UDS协议向车辆的MCU下发例程控制数据,以使MCU执行相应的功能操作。
[0089] 其中,例程控制数据是指诊断设备向MCU发送的一系列指令和数据,用于执行特定的诊断例程或控制操作。这些例程控制数据可以包括switch芯片升级、读取故障码、清除故障码、读取实时数据、执行特定测试等操作所需的指令和参数。通过向MCU发送例程控制数据,诊断设备可以与车辆的各个MCU进行通信,并进行诊断、测试和配置操作。
[0090] 在一些实施例中,如图4所示,提供了一种车载芯片的升级方法,以该方法应用于图1中的服务器104为例进行说明,该方法包括以下步骤:
[0091] 步骤S11:响应触发用于升级车载芯片的启动程序,下载携带有应用程序数据和Switch固件数据的升级文件包到Flash存储器中。
[0092] 在一实施例中,本申请中的车载芯片是属于电动汽车领域中的交换芯片,其用于电动汽车的电子系统和控制单元,包括用于实现汽车网络数据的交换和路由。在某些具体实施例中,该车载芯片可以是Switch芯片,其中Switch芯片是一种特殊的交换芯片,其用于构建局域网中的交换机,实现局域网内部的数据交换和转发。
[0093] 具体地,在车载芯片的升级系统响应触发升级车载芯片的工作程序时,服务器控制车载芯片的升级系统中的诊断设备向启动程序发送升级指令;然后,在启动程序接收到升级指令后,控制MCU从诊断设备中下载携带有应用程序数据和Switch固件数据的升级文件包到Flash存储器对应指定的flash区域中存储。
[0094] 在一些实施例中,应用程序数据用于对Flash存储器中待升级的应用程序进行升级。其中,在MCU下载升级文件包完成后,待升级的应用程序同步完成升级,即MCU对升级文件包的下载过程即为MCU对应用程序的升级过程。
[0095] 在一些实施例中,在升级文件包中还携带有校验码。其中,该校验码用于在MCU下载升级文件包的过程中,校验MCU接收升级文件包所对应数据报文的完整性和准确性。
[0096] 在一实施例中,在服务器校验数据报文不完整或者不准确的情况下,控制MCU停止下载升级文件包后续的数据报文,并生成一负响应码发送于诊断设备。或者,在服务器校验数据报文完整以及准确的情况下,控制MCU继续下载升级文件包后续的数据报文。
[0097] 步骤S12:在应用程序升级完成后,获取用于升级车载芯片中的Switch固件的第一类例程控制数据。
[0098] 在一示例性实施例中,服务器在应用程序升级完成后,获取用于升级车载芯片中的Switch固件的第一类例程控制数据的过程,具体包括如下步骤:在应用程序升级完成后,生成一升级反馈消息发送于诊断设备;在诊断设备接收到升级反馈消息的情况下,获取诊断设备基于UDS协议逐个发送的第一类例程控制数据。
[0099] 具体地,在MCU下载升级文件包完成后,即表明MCU完成对应用程序的升级过程之后,服务器控制MCU生成一用于表征应用程序升级完成的升级反馈消息,并发送于诊断设备;然后,在诊断设备接收到升级反馈消息之后,控制诊断设备基于UDS协议逐个向MCU发送用于升级车载芯片中的Switch固件的第一类例程控制数据。
[0100] 其中,该第一类例程控制数据为诊断设备向MCU发送的一系列指令数据,这些指令数据用于指示MCU执行升级车载芯片中的Switch固件。
[0101] 步骤S13:基于第一类例程控制数据调用预设的功能接口,以将Switch固件数据从Flash存储器写入到车载芯片中,以对Switch固件进行升级。
[0102] 具体地,服务器控制MCU根据第一类例程控制数据调用专门用于写flash数据的功能接口,以指示该功能接口将存储于相应flash区域中的Switch固件数据写入到交换芯片对应指定的区域中存储。
[0103] 其中,在MCU根据第一类例程控制数据,将Switch固件数据从flash区域写入到交换芯片对应指定的区域中存储完成后,服务器再控制MCU向诊断设备反馈Switch固件升级完成的正响应码,以指示已完成对交换芯片的升级。
[0104] 上述车载芯片的升级的过程中,一方面,本方案通过先触发用于升级车载芯片的启动程序,以下载携带有应用程序数据和Switch固件数据的升级文件包到Flash存储器中,然后再在应用程序升级完成后,基于第一类例程控制数据调用预设的功能接口,以将Switch固件数据从Flash存储器写入到车载芯片中,以对Switch固件进行升级,从而优化了车载芯片的升级流程,有效提高了升级车载芯片的效率,降低了人力和物力的消耗;另一方面,本方案通过区别于的传统芯片升级方式,通过先利用升级文件包中的应用程序数据来对待升级的应用程序进行升级,然后在应用程序升级完成后,再利用用于升级车载芯片的第一类例程控制数据调用预设的功能接口,以将Switch固件数据写入到车载芯片中,从而能够在无需配备专门的升级工具或者升级线缆的情况下,完成对Switch固件的升级,有效降低了企业的管理成本,并提高了对车载芯片中的Switch固件进行升级的效率和成功率,有利于电动车辆的安全使用。
[0105] 本领域技术人员可以理解地,在具体实施方式的上述方法中,所揭露的方法可以通过更为具体的方式以实现。例如,以上所描述的服务器基于第一类例程控制数据调用预设的功能接口,以将Switch固件数据从Flash存储器写入到车载芯片中,以对Switch固件进行升级的实施方式仅仅是示意性的。
[0106] 在一示例性实施例中,参阅图5,图5为本申请中对应用程序进行升级一实施例中的流程示意图。其中,在步骤S11中,即服务器响应触发用于升级车载芯片的启动程序,下载携带有应用程序数据和Switch固件数据的升级文件包到Flash存储器中的过程,具体包括如下步骤:
[0107] 步骤S111:响应预设的诊断设备向启动程序发送升级指令,以触发启动程序从Flash存储器的参数区域中读取出待升级的应用程序的存储地址。
[0108] 具体地,在服务器响应触发升级交换芯片的工作程序时,服务器控制诊断设备向启动程序发送升级指令;然后,在启动程序接收到升级指令时,控制启动程序按照升级指令从Flash存储器的参数区域中读取出待升级的应用程序的存储地址。
[0109] 步骤S112:基于存储地址,从诊断设备中逐帧下载升级文件包到Flash存储器对应的flash区域中进行存储,以对待升级的应用程序进行升级。
[0110] 具体地,服务器控制诊断设备逐帧的向MCU发送升级文件包的升级数据,MCU再根据待升级的应用程序的存储地址,将接收的升级数据下载到对应的flash区域中进行存储,以对待升级的应用程序进行升级。
[0111] 其中,在升级文件包下载完成后,待升级的应用程序同步完成升级,即MCU对升级文件包的下载过程即为MCU对应用程序的升级过程。
[0112] 在一示例性实施例中,在步骤S122之前,即服务器在从诊断设备中逐帧下载升级文件包到Flash存储器对应的flash区域中进行存储之前,具体还包括如下步骤:
[0113] 步骤一:接收诊断设备发送的针对于升级文件包的首帧数据报文。
[0114] 其中,该首帧数据报文用于携带升级文件包的文件大小、名称、格式等信息,其不包括应用程序数据、Switch固件数据、文件校验码。
[0115] 步骤二:解析首帧数据报文中的数据内容,以确定升级文件包的数据容量。
[0116] 具体地,服务器控制MCU对该首帧数据报文的数据内容进行解析,以升级文件包的文件大小确定升级文件包的数据容量。
[0117] 步骤三:基于数据容量和Flash存储器对应的容量阈值之间的大小关系,对升级文件包进行容量校验,得到对应的容量校验结果。
[0118] 具体地,Flash存储器用于存储程序数据的数量容量有一个预设的容量阈值,从而服务器将升级文件包的数据容量和Flash存储器的容量阈值进行大小比对,以得出对应的容量校验结果。
[0119] 步骤四:在容量校验结果表征校验成功的情况下,指示接收诊断设备发送的连续帧数据报文;或者在容量校验结果表征校验失败的情况下,生成一容量告警消息发送于诊断设备。
[0120] 具体地,若容量校验结果表征校验成功,即在升级文件包的数据容量小于或等于Flash存储器的容量阈值的情况下,服务器指示MCU接收诊断设备后续发送过来的连续帧数据报文。若容量校验结果表征校验失败,即在升级文件包的数据容量大于Flash存储器的容量阈值的情况下,服务器指示MCU禁止接收诊断设备后续发送过来的连续帧数据报文,并生成一容量告警消息发送于诊断设备,以召唤人工处理。
[0121] 在一示例性实施例中,在步骤S122中,即服务器执行从诊断设备中逐帧下载升级文件包到Flash存储器对应的flash区域中进行存储的过程,具体包括如下步骤:
[0122] 步骤一:接收诊断设备发送的针对于升级文件包的连续帧数据报文。
[0123] 其中,在诊断设备向MCU发送首帧数据报文之后,诊断设备再继续向MCU发送针对于升级文件包的连续帧数据报文。
[0124] 其中,在该连续帧数据报文中携带有应用程序数据、Switch固件数据、文件校验码。
[0125] 步骤二:提取各连续帧数据报文中的报文校验码,以基于报文校验码和Flash存储器中的基准校验码之间的匹配关系,对各连续帧数据报文依次进行数据校验,得到对应的数据校验结果。
[0126] 具体地,服务器指示MCU依次提取各连续帧数据报文中的报文校验码;然后,再控制MCU将各连续帧数据报文的报文校验码和MCU中预存的基准校验码进行比对匹配,以得到对应的数据校验结果。
[0127] 其中,该比对匹配用于校验MCU接收的各连续帧数据报文的完整性和准确性。
[0128] 步骤三:在数据校验结果表征校验成功的情况下,将对应的连续帧数据报文下载到flash区域中进行存储;或者,在数据校验结果表征校验失败的情况下,停止接收连续帧数据报文,并生成一负响应码发送于诊断设备。
[0129] 具体地,若数据校验结果表征校验成功,即在连续帧数据报文匹配于基准校验码的情况下,服务器指示MCU将对应接收的连续帧数据报文下载到flash区域中进行存储。若数据校验结果表征校验失败,即在连续帧数据报文不匹配于基准校验码的情况下,服务器指示MCU禁止接收诊断设备后续发送过来的连续帧数据报文,并生成一负响应码发送于诊断设备,以召唤人工处理。
[0130] 在一示例性实施例中,在步骤S122中,即服务器执行从诊断设备中逐帧下载升级文件包到Flash存储器对应的flash区域中进行存储的过程中,具体还包括如下步骤:
[0131] 步骤一:基于预设的监控程序,实时获取Flash存储器的性能状态。
[0132] 步骤二:基于性能状态,生成一流控报文指令发送于Flash存储器。
[0133] 其中,流控报文指令用于控制MCU接收连续帧数据报文的速率。
[0134] 具体地,预先在MCU中设置一个监控程序,以实时监控MCU在当前的性能状态;然后,再根据MCU的性能状态实时的(如每隔1S)生成一个流控报文指令发送于MCU,以控制MCU接收连续帧数据报文的间隔时间、速度或者数量,从而限制MCU在当前正在处理连续帧数据报文的数量或者待处理的连续帧数据报文的数量,以保证MCU下载升级文件包的稳定性和准确性。
[0135] 在一示例性实施例中,参阅图6,图6为本申请中对车载芯片进行故障诊断一实施例中的模块示意图。其中,服务器可以具体包括如下步骤:
[0136] 步骤一:获取诊断设备发送的用于诊断车载芯片故障的第二类例程控制数据。
[0137] 其中,该第二类例程控制数据为诊断设备向MCU发送的一系列指令数据,这些指令数据用于指示MCU从交换芯片中读取故障数据,并写入到对应指定的flash区域中存储。
[0138] 具体地,首先用户在诊断设备的用户界面中触发用于诊断交换芯片故障的功能控件,以触发服务器开始执行芯片故障诊断的流程。然后,服务器控制诊断设备基于UDS31协议,向MCU下发用于诊断交换芯片故障的第二类例程控制数据,以使MCU依次接收各个第二类例程控制数据。
[0139] 其中,在MCU在接收各个第二类例程控制数据时,需要对第二类例程控制数据进行识别,以确定接收的第二类例程控制数据是否为用于诊断交换芯片故障的诊断指令。其中,若第二类例程控制数据不为用于诊断交换芯片故障的诊断指令,则控制MCU执行第二类例程控制数据所对应的逻辑处理;若第二类例程控制数据为用于诊断交换芯片故障的诊断指令,则控制MCU执行以下的步骤二。
[0140] 步骤二:基于第二类例程控制数据调用预设的功能接口,以将故障数据从车载芯片写入到Flash存储器中进行存储。
[0141] 步骤三:从Flash存储器中读取出故障数据,以将故障数据返回到诊断设备中进行故障诊断。
[0142] 具体地,服务器控制MCU调用应用程序中专门用于写故障数据的功能接口,以通过该功能接口根据例程控制数据,从交换芯片中读取出故障数据,并将故障数据写入Flash存储器对应指定的flash区域中;然后,再控制MCU从flash区域中提取出故障数据,以发送到诊断设备中进行故障诊断。
[0143] 其中,在根据例程控制数据,将故障数据从交换芯片写入到对应指定的flash区域中存储完成后,服务器向诊断设备反馈故障数据读取完成的正响应码,以完成对故障数据的读取。
[0144] 为了更清晰阐明本公开实施例提供的车载芯片的升级方法,以下以一个具体的实施例对该车载芯片的升级方法进行具体说明。在一示例性实施例中,参考图7至8,图7为根据一示例性实施例示出的一种应用程序的升级方法的模块示意图,图8为根据一示例性实施例示出的一种Switch固件的升级方法的模块示意图。其中,该应用程序的升级方法和Switch固件的升级方法均应用于服务器104中,其具体包括如下内容:
[0145] 步骤一:控制诊断仪向Flash存储器的启动文件区域中的启动程序发送升级指令,以触发MCU启动升级流程。
[0146] 其中,升级指令用于指示启动程序从参数区域中读取并返回待升级的应用程序的起始地址。
[0147] 步骤二:控制诊断仪逐帧的向MCU发送关于升级文件包的数据报文。
[0148] 其中,升级文件包为上位机PC预先封装好并上传到诊断仪中存储的升级数据包。
[0149] 其中,在升级文件包中包含应用程序数据、Switch固件数据、文件校验码三部分。
[0150] 其中,Switch固件数据为交换芯片中用于控制开关功能的软件程序的程序数据。
[0151] 其中,文件校验码为每一数据报文或者整个升级文件包自身携带的校验码。
[0152] 步骤三:根据待升级的应用程序的起始地址,指示MCU依次将数据报文下载到Flash存储器中存储。
[0153] 其中,在MCU下载各数据报文的过程中,MCU需要解析出每一数据报文自带的校验码,并与对应的基准校验码相比较,以确定每一数据报文是否校验通过。
[0154] 其中,在数据报文校验通过时,MCU将数据报文写入到指定的flash区域中存储。
[0155] 其中,在数据报文校验未通过时,停止接收关于升级文件包后面的数据报文,并向诊断仪返回NRC负响应码,以召唤人工处理。
[0156] 其中,对每一数据报文进行校验用于校验文件数据的完整性和准确性。
[0157] 其中,基于程序规范,对升级文件包的首帧数据报文不做校验验证;其中,该首帧数据报文用于携带升级文件包的文件大小、名称、格式等信息,其不包括应用程序、Switch固件、文件校验码三部分。
[0158] 其中,在下载升级文件包的过程中,MCU是基于Flash存储器中各个划分区域对应由低到高的地址次序,先后访问各个Flash区域
[0159] 其中,在MCU中设置一个监控程序,以监控MCU的性能状态(包括MCU正在处理/待处理的数据报文的数量),以实时的(如每隔1S)生成一个流控报文指令,以用于控制MCU接收连续帧数据报文的间隔时间、速度或者数量。
[0160] 步骤四:在升级文件包的数据报文全部被MCU下载完成时,完成对应用程序的升级流程并向诊断仪发送正响应码。
[0161] 步骤五:在应用程序升级完成后,在诊断仪的用户界面中触发用于升级交换芯片的switch固件升级指令,以开始执行升级switch固件的流程。
[0162] 其中,在诊断设备的显示界面中显示有一个控件,该控件用于触发switch固件升级指令。
[0163] 步骤六:控制诊断仪基于UDS31服务,向MCU下发例程控制数据,以使MCU依次接收各个例程控制数据。
[0164] 其中,例程控制数据是一个指令序列,需要MCU一个一个的接收并依次的处理。
[0165] 步骤七:控制MCU识别接收的各个例程控制数据是否为用于升级switch固件的升级指令。
[0166] 其中,若例程控制数据是用于升级switch固件的升级指令,则进入步骤八;若例程控制数据不是用于升级switch固件的升级指令,则基于该例程控制数据进行其对应的逻辑处理。
[0167] 步骤八:控制MCU调用应用程序中用于写Flash的功能接口,以通过该功能接口根据例程控制数据,将Switch固件数据从flash区域写入到交换芯片对应指定的区域中存储。
[0168] 其中,在根据例程控制数据,将Switch固件数据从flash区域写入到交换芯片对应指定的区域中存储完成后,向诊断仪反馈Switch固件升级完成的正响应码,以完成对交换芯片的升级。
[0169] 这样,一方面,本方案通过先触发用于升级车载芯片的启动程序,以下载携带有应用程序数据和Switch固件数据的升级文件包到Flash存储器中,然后再在应用程序升级完成后,基于第一类例程控制数据调用预设的功能接口,以将Switch固件数据从Flash存储器写入到车载芯片中,以对Switch固件进行升级,从而优化了车载芯片的升级流程,有效提高了升级车载芯片的效率,降低了人力和物力的消耗;另一方面,本方案通过区别于的传统芯片升级方式,通过先利用升级文件包中的应用程序数据来对待升级的应用程序进行升级,然后在应用程序升级完成后,再利用用于升级车载芯片的第一类例程控制数据调用预设的功能接口,以将Switch固件数据写入到车载芯片中,从而能够在无需配备专门的升级工具或者升级线缆的情况下,完成对Switch固件的升级,有效降低了企业的管理成本,并提高了对车载芯片中的Switch固件进行升级的效率和成功率,有利于电动车辆的安全使用。
[0170] 应该理解的是,虽然图2‑图8的附图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以通过其它的顺序执行。而且,图2‑图8中的至少一部分步骤可以包括多个步骤或者多个阶段,这些步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
[0171] 可以理解的是,本说明书中上述方法的各个实施例之间相同/相似的部分可互相参见,每个实施例重点说明的是与其他实施例的不同之处,相关之处参见其他方法实施例的说明即可。
[0172] 图9是本申请实施例提供的一种车载芯片的升级装置的结构框图。参照图9,该车载芯片的升级装置10包括:程序下载模块11、数据获取模块12、芯片升级模块13。
[0173] 其中,该程序下载模块11,用于响应触发用于升级所述车载芯片的启动程序,下载携带有应用程序数据和Switch固件数据的升级文件包到Flash存储器中;所述应用程序数据用于对所述Flash存储器中待升级的应用程序进行升级;
[0174] 其中,该数据获取模块12,用于在所述应用程序升级完成后,获取用于升级所述车载芯片中的Switch固件的第一类例程控制数据;
[0175] 其中,该芯片升级模块13,用于基于所述第一类例程控制数据调用预设的功能接口,以将所述Switch固件数据从所述Flash存储器写入到所述车载芯片中,以对所述Switch固件进行升级。
[0176] 在一实施例中,在所述响应触发用于升级所述车载芯片的启动程序,下载携带有应用程序数据和Switch固件数据的升级文件包到Flash存储器中的方面,该车载芯片的升级装置10还用于执行:
[0177] 响应预设的诊断设备向启所述启动程序发送升级指令,以触发所述启动程序从所述Flash存储器的参数区域中读取出所述待升级的应用程序的存储地址;
[0178] 基于所述存储地址,从所述诊断设备中逐帧下载所述升级文件包到所述Flash存储器对应的flash区域中进行存储,以对所述待升级的应用程序进行升级;
[0179] 其中,在所述升级文件包下载完成后,所述待升级的应用程序同步完成升级。
[0180] 在一实施例中,在所述升级文件包中还携带有校验码;
[0181] 在所述从所述诊断设备中逐帧下载所述升级文件包到所述Flash存储器对应的flash区域中进行存储的方面,该车载芯片的升级装置10还用于执行:
[0182] 接收所述诊断设备发送的针对于所述升级文件包的连续帧数据报文;
[0183] 提取各所述连续帧数据报文中的报文校验码,以基于所述报文校验码和所述Flash存储器中的基准校验码之间的匹配关系,对各所述连续帧数据报文依次进行数据校验,得到对应的数据校验结果;
[0184] 在所述数据校验结果表征校验成功的情况下,将对应的所述连续帧数据报文下载到所述flash区域中进行存储;或者
[0185] 在所述数据校验结果表征校验失败的情况下,停止接收所述连续帧数据报文,并生成一负响应码发送于所述诊断设备。
[0186] 在一实施例中,在所述接收所述诊断设备发送的针对于所述升级文件包的连续帧数据报文之前,该车载芯片的升级装置10还用于执行:
[0187] 接收所述诊断设备发送的针对于所述升级文件包的首帧数据报文;
[0188] 解析所述首帧数据报文中的数据内容,以确定所述升级文件包的数据容量;
[0189] 基于所述数据容量和所述Flash存储器对应的容量阈值之间的大小关系,对所述升级文件包进行容量校验,得到对应的容量校验结果;
[0190] 在所述容量校验结果表征校验成功的情况下,指示接收所述诊断设备发送的连续帧数据报文;或者
[0191] 在所述容量校验结果表征校验失败的情况下,生成一容量告警消息发送于所述诊断设备。
[0192] 在一实施例中,该车载芯片的升级装置10还用于执行:
[0193] 基于预设的监控程序,实时获取所述Flash存储器的性能状态;
[0194] 基于所述性能状态,生成一流控报文指令发送于所述Flash存储器;
[0195] 其中,所述流控报文指令用于控制所述Flash存储器接收所述连续帧数据报文的速率。
[0196] 在一实施例中,在所述应用程序升级完成后,获取用于升级所述车载芯片中的Switch固件的第一类例程控制数据的方面,该车载芯片的升级装置10还用于执行:
[0197] 在所述应用程序升级完成后,生成一升级反馈消息发送于诊断设备;
[0198] 在所述诊断设备接收到所述升级反馈消息的情况下,获取所述诊断设备基于UDS协议逐个发送的第一类例程控制数据。
[0199] 在一实施例中,该车载芯片的升级装置10还用于执行:
[0200] 获取诊断设备发送的用于诊断所述车载芯片故障的第二类例程控制数据;
[0201] 基于所述第二类例程控制数据调用预设的功能接口,以将故障数据从所述车载芯片写入到所述Flash存储器中进行存储;
[0202] 从所述Flash存储器中读取出所述故障数据,以将所述故障数据返回到所述诊断设备中进行故障诊断。
[0203] 图10是本申请实施例提供的一种整车控制器20的框图。例如,整车控制器20可以为一种电子设备、电子组件或者服务器阵列等等。参照图10,整车控制器20包括处理器21,其进一步处理器21可以为处理器集合,其可以包括一个或多个处理器,以及整车控制器20包括由存储器22所代表的存储器资源,其中,存储器22上存储有程序数据,例如应用程序。在存储器22中存储的程序数据可以包括一个或一个以上的每一个对应于一组可执行指令的模块。此外,处理器21被配置为用于调取所述存储器22中存储的程序数据时实现如上述的车载芯片的升级方法。
[0204] 在一些实施例中,整车控制器20为电子设备,该电子设备中的计算系统可以运行一个或多个操作系统,包括以上讨论的任何操作系统以及任何商用的服务器操作系统。该整车控制器20还可以运行各种附加服务器应用和/或中间层应用中的任何一种,包括HTTP(超文本传输协议)服务器、FTP(文件传输协议)服务器、CGI(通用网关界面)服务器、超级服务器、数据库服务器等。示例性数据库服务器包括但不限于可从(国际商业机器)等商购获得的数据库服务器。
[0205] 在一些实施例中,处理器21通常控制整车控制器20的整体操作,诸如与显示、数据处理、数据通信和记录操作相关联的操作。处理器21可以包括一个或多个处理器组件来执行计算机程序,以完成上述的方法的全部或部分步骤。此外,处理器组件可以包括一个或多个模块,便于处理器组件和其他组件之间的交互。例如,处理器组件可以包括多媒体模块,以方便利用多媒体组件控制用户整车控制器20和处理器21之间的交互。
[0206] 在一些实施例中,处理器21中的处理器组件还可以称为CPU(Central Processing Unit,中央处理单元)。处理器组件可能是一种电子芯片,具有信号的处理能力。处理器还可以是通用处理器、数字信号处理器(Digital Signal Processor, DSP)、专用集成电路(Application Specific Integrated Circuit, ASIC)、专用集成电路(Application Specific Integrated Circuit, ASIC)、现场可编程门阵列(Field‑Programmable Gate Array, FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器组件等。另外,处理器组件可以由集成电路芯片共同实现。
[0207] 在一些实施例中,存储器22被配置为存储各种类型的数据以支持在整车控制器20的操作。这些数据的示例包括用于在整车控制器20上操作的任何应用程序或方法的指令、采集数据、消息、图片、视频等。存储器22可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(SRAM)、电可擦除可编程只读存储器(EEPROM)、可擦除可编程只读存储器(EPROM)、可编程只读存储器(PROM)、只读存储器(ROM)、磁存储器、快闪存储器、磁盘、光盘或石墨烯存储器。
[0208] 在一些实施例中,存储器22可以为内存条、TF卡等,可以存储整车控制器20中的全部信息,包括输入的原始数据、计算机程序、中间运行结果和最终运行结果都保存在存储器22中。在一些实施例中,它根据处理器指定的位置存入和取出信息。在一些实施例中,有了存储器22,整车控制器20才有记忆功能,才能保证正常工作。在一些实施例中,整车控制器
20的存储器22按用途可分为主存储器(内存)和辅助存储器(外存),也有分为外部存储器和内部存储器的分类方法。外存通常是磁性介质或光盘等,能长期保存信息。内存指主板上的存储部件,用来存放当前正在执行的数据和程序,但仅用于暂时存放程序和数据,关闭电源或断电,数据会丢失。
[0209] 在一些实施例中,整车控制器20还可以包括:电源组件23被配置为执行整车控制器20的电源管理,有线或无线网络接口24被配置为将整车控制器20连接到网络,和输入输出(I/O)接口25。整车控制器20可以操作基于存储在存储器22的操作系统,例如Windows Server,Mac OS X,Unix,Linux,FreeBSD或类似。
[0210] 在一些实施例中,电源组件23为整车控制器20的各种组件提供电力。电源组件23可以包括电源管理系统,一个或多个电源,及其他与为整车控制器20生成、管理和分配电力相关联的组件。
[0211] 在一些实施例中,有线或无线网络接口24被配置为便于整车控制器20和其他设备之间有线或无线方式的通信。整车控制器20可以接入基于通信标准的无线网络,如WiFi,运营商网络(如2G、3G、4G或5G),或它们的组合。
[0212] 在一些实施例中,有线或无线网络接口24经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中,有线或无线网络接口24还包括近场通信(NFC)模块,以促进短程通信。例如,在NFC模块可基于射频识别(RFID)技术,红外数据协会(IrDA)技术,超宽带(UWB)技术,蓝牙(BT)技术和其他技术来实现。
[0213] 在一些实施例中,输入输出(I/O)接口25为处理器21和外围接口模块之间提供接口,上述外围接口模块可以是键盘,点击轮,按钮等。这些按钮可包括但不限于:主页按钮、音量按钮、启动按钮和锁定按钮。
[0214] 图11是本申请实施例提供的一种计算机可读存储介质30的框图。该计算机可读存储介质30上存储有计算机程序31,其中,计算机程序31被处理器执行时实现如上述的车载芯片的升级方法。
[0215] 在本申请各个实施例中的各功能单元集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在计算机可读存储介质30中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机可读存储介质30在一个计算机程序31中,包括若干指令用以使得一台计算机设备(可以是个人计算机,系统服务器,或者网络设备等)、电子设备(例如MP3、MP4等,也可以是手机、平板电脑、可穿戴设备等智能终端,也可以是台式电脑等)或者处理器(processor)以执行本申请各个实施方式方法的全部或部分步骤。
[0216] 图12是本申请实施例提供的一种计算机程序产品40的框图。该计算机程序产品40中包括程序指令41,该程序指令41可由整车控制器20的处理器执行以实现如上述的车载芯片的升级方法。
[0217] 本领域内的技术人员应明白,本申请的实施例可提供有车载芯片的升级方法、车载芯片的升级装置10、整车控制器20、计算机可读存储介质30或计算机程序产品40。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机程序指令41(包括但不限于磁盘存储器、CD‑ROM、光学存储器等)上实施的计算机程序产品40的形式。
[0218] 本申请是参照根据本申请实施例中的车载芯片的升级方法、车载芯片的升级装置10、整车控制器20、计算机可读存储介质30或计算机程序产品40的流程图和/或方框图来描述的。应理解可由计算机程序产品40实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序产品40到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的程序指令41产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0219] 这些计算机程序产品40也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机程序产品40中的程序指令41产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0220] 这些程序指令41也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的程序指令41提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0221] 需要说明的,上述的各种方法、装置、电子设备、计算机可读存储介质、计算机程序产品等根据方法实施例的描述还可以包括其他的实施方式,具体的实现方式可以参照相关方法实施例的描述,在此不作一一赘述。
[0222] 本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本公开的真正范围和精神由权利要求指出。
[0223] 应当理解的是,本公开并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

当前第1页 第1页 第2页 第3页
相关技术
升级装置相关技术
存储介质相关技术
冯玖江发明人的其他相关专利技术