车载ECU应用程序更新系统方案、更新技术的制作方法

车载ecu应用程序更新系统方案、更新技术
技术领域
1.本发明实施例涉及汽车计算机控制系统和嵌入式工业控制局域网领域，具体涉及一种 车载电子控制单元(electronic control unit,ecu)应用程序更新系统方案、更新技术。


背景技术：

2.车载ecu，又称“车载电脑”，它由微控制器(mcu)、存储器(rom、ram)、输入 /输出接口(i/o)、模数转换器(a/d)以及整形、驱动等大规模集成电路组成，应用在动力 控制系统、车身电子控制系统、车载电子控制装置、底盘控制系统等，其最重要的作用是提 高汽车性能以及舒适性、娱乐性和经济性。
3.为了完善车载ecu的性能、增强ecu的稳定性、修补漏洞，通常汽车制造商会对车 载ecu应用程序进行更新。
4.车载ecu是嵌入式系统工业汽车领域具体应用的体现，车载ecu应用程序更新技术 需要应用到嵌入式软件更新技术。嵌入式软件更新技术按软件编程方式，通常分为在系统编 程技术(in system programmable,isp)和在应用编程技术(inapplication programmable,iap)两种 嵌入式软件更新技术。isp技术通过串口、调试接口等接口来实现，这类技术实时性、可靠性、 稳定性比较好，但缺点是操作复杂，需要专业技术人员现场操作。iap技术可通过网络来实 现，网络分有线网络和无线网络。有线网络如802.3(以太网)、控制器局域网络(controllerareanetwork,can)等协议的局域网络。无线网络如蓝牙、802.11a/b/e等系列协议、分组核心网 2g/3g/4g/5g等数据业务相关协议(代表如gprs、3gpp)。基于网络技术的更新技术特点是 维护操作便捷、灵活。采用无线网络更新技术需要更新系统具备支持无线信号接收和发送的 通信装置，硬件成本高，在稳定性、宽带速率上不如有线网络。
5.未来嵌入式软件更新技术需求，主要朝着操作便捷，更新过程稳定、可靠，软件更新 后系统稳定性和可靠性有保障等方面发展。因此开发一套成本低、可靠性和稳定性比较好的 软件更新系统，将是未来嵌入式软件更新技术的主要发展趋势。
6.can总线协议是由以研发和生产汽车电子产品著称的德国bosch公司开发的，并最 终成为国际标准(iso 11898)，是国际上应用最广泛的现场总线之一。在北美和西欧，can 总线协议已经成为汽车计算机控制系统和嵌入式工业控制局域网的标准总线，并且拥有以 can为底层协议专为大型货车和重工机械车辆设计的j1939协议。


技术实现要素：

7.本发明实施例的目的是提供一种基于can协议的j1939协议和在应用编程技术的车载 ecu应用程序更新系统方案、更新技术，一方面可充分利用现成车载网络节省硬件成本，另 一方面其有线形式的总线网络保障了数据通信实时、可靠，解决了系统硬件成本高、操作专 业性和流程复杂性高、通信过程延时大、通讯过程不稳定和不可靠、数据传输速率
慢、数据 漏传/错传等问题。
8.为实现上述目的，本发明实施例提供了一种车载ecu应用程序更新系统方案，包括： 现场实施步骤、系统功能需求、系统业务模型、系统总体结构、系统网络体系结构、系统通 讯协议制定、系统通讯过程制定、系统硬件设计、系统软件设计、更新成功验证。
9.现场实施步骤包括搭建并连接更新系统各器件，开启更新控制程序，执行传输新应用 程序数据包至目标ecu，更新成功验证。
10.系统功能需求包括发送更新请求、响应更新请求、发送应用程序数据包、擦除存储器 数据、接收应用程序数据包、数据写入存储器、终止发送应用程序数据包、更新后验证八个 功能。
11.系统业务模型包括更新系统服务端向目标ecu发起应用程序更新请求，目标ecu响应 所述更新请求并建立通信连接，服务端下发新应用程序数据包至所述目标ecu，目标ecu 擦除存储器flash中待更新的应用程序，目标ecu将数据写入flash中指定位置，目标ecu 判断是否写入完毕，若写入完毕，向服务端发送写入完毕请求以断开所述通信连接，否则继 续写入，服务端收到所述写入完毕请求，断开通信连接。
12.系统总体结构包括更新系统的网络结构采用服务器-客户机结构模式，更新系统服务端 为客户端即上位机，此处采用pc机，目标ecu为服务器端即下位机，此处采用具有can 口的嵌入式驱动板，上位机和所述下位机之间通过usb-can转换器连接。usb-can转换器 有两个端口，分别是usb口和can口,usb口连接pc机usb口，can口连接所述驱动板 can口。
13.系统网络体系结构采用底层基于can2.0总线协议的sae j1939协议族。物理层采用 can协议规范的iso 11898协议标准，数据链路层采用sae j1939-21协议，应用层采用saej1939-71协议。其有益效果是，系统结构简单、借助车载ecu广泛使用的can总线网络节 省了硬件成本，通信可靠性、稳定性也有所保障。
14.系统通讯协议制定包括种帧类型定义，分别定义了连接管理帧(transportprotocol-connection management,tp.cm)和数据帧(transport protocol-data transfermessage,tp.dt)。接管理帧包括请求帧(connection mode request to send,tp.cm_rts)、响应 帧(connection mode clear to send,tp.cm_cts)、结束帧(end of message acknowledgment,tp.cm_endofack)。tp.cm_rts、tp.cm_cts、tp.cm_endofack包括各字节定 义、值确定、发送者确定。数据帧tp.dt包括各字节定义、值确定、发送者确定。
15.系统通讯过程制定包括通信控制、通讯连接过程、更新状态转移、更新流程。
16.通信控制包括上位机具备发起会话连接、控制连接、传输数据、接收数据、关闭连接 等，下位机具备响应请求、断开连接、发送和接收数据等。
17.通讯连接过程采用握手通讯连接建立可靠的通信过程，即请求/响应这样一问一答的通 信机制，双方中，若有一方未接收到对方发来的信息，则进入重发机制，若重发失败后则断 开连接，即收到对方信息才进行下一步操作。其有益效果是，此设计保证系统通信的可靠性， 避免因掉电或其它干扰引起通信过程未收到请求或响应导致数据传输错误。
18.更新状态转移包括上位机运行状态包括发起更新连接请求、传输应用程序数据包、关 闭更新连接三个基本状态以及所述各状态间转移。下位机运行状态包括系统初始化、运行启 动控制程序、运行应用程序、运行更新程序四个基本状态以及所述各状态间转
移。其有益效 果是，此设计保证系统程序执行逻辑性、可靠性更强。
19.更新流程包括上位机发起更新请求，建议通信连接；下位机响应更新请求；上位机收 到响应后下发更新的应用程序数据包；下位机接收更新的应用程序数据包并按要求擦除flash 指定存储块和写入接收数据；下位机接收和写入完毕数据包后，向上位机发送结束传输请求， 并自动运行更新成功验证程序，系统重启；上位机接收到结束传输请求后，断开所述连接。 其有益效果是，更新流程简单、稳定、可靠。
20.系统硬件设计包括上位机主要硬件功能模块包括输入/输出设备模块、存储器模块、usb 接口模块、can接口模块、usb-can转换模块。上位机输入/输出设备模块、存储器模块、 usb接口模块通过pc及相关设备实现，usb-can转换模块通过usb-can转换器实现。下 位机主要硬件功能模块包括微控制器模块、存储器模块、can接口模块、调试模块、串口模 块、时钟和复位模块、电源模块。下位机微控制器模块采用stm32f103vet6微控制器实现， can接口模块采用tja1050can收发器实现，存储器模块采用flash闪存实现。
21.系统软件设计包括上位机主要软件功能模块包括操作系统、usb接口驱动、can接口 驱动、usb-can转换程序、更新控制程序、应用程序数据。下位机涉及主要软件功能模块包 括启动控制程序、更新程序、应用程序。其中更新程序又包括can驱动程序、数据接收/发 送程序、flash驱动程序、更新成功验证程序。
22.更新成功验证是将写入数据与传输数据比对，比对一致即更新成功，否则失败：
23.为实现上述目的，本发明实施例还提供了一种车载ecu应用程序更新技术，包括iap 技术、启动控制程序、flash分区设计。iap技术通过基于can总线协议的sae j1939协议。 启动控制程序通过判断标志值选择擦除、写入、启动指定应用程序。flash分区设计包括将 flash存储器可编辑区划分为两个应用程序存储块和一个判断标志，通过判断标志将新等应用 程序数据写入flash指定位置。
附图说明
24.一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并 不构成对实施例的限定。
25.图1是本发明实施例提供的一种车载ecu应用程序更新系统方案的系统总体结构；
26.图2是本发明实施例提供的一种车载ecu应用程序更新系统方案的系统通信时序图；
27.图3是本发明实施例提供的一种车载ecu应用程序更新系统方案的上位机升级控制程 序设计；
28.图4是本发明实施例提供的一种车载ecu应用程序更新系统方案的下位机bootloader 子程序设计；
29.图5是本发明实施例提供的一种车载ecu应用程序更新系统方案的下位机应用子程序 设计；
30.图6是本发明实施例提供的一种车载ecu应用程序更新系统方案的下位机dt帧处理 子程序设计；
31.图7是本发明实施例提供的一种车载ecu应用程序更新系统方案的下位机flash分区 设计；
32.图8是本发明实施例提供的一种车载ecu应用程序更新系统方案的tp.cm_rts帧和 tp.cm_endofack帧数据域定义；
33.图9是本发明实施例提供的一种车载ecu应用程序更新系统方案的tp.cm_cts帧数 据域定义；
34.图10是本发明实施例提供的一种车载ecu应用程序更新系统方案的tp.dt帧定义；
具体实施方式
35.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施 例的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明实施例 的各实施方式中，为了使读者更好地理解本发明实施例而提出了许多技术细节。但是，即使 没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本发明实施例的所 要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本发明实施例的具体 实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。
36.本发明的第一实施方式涉及一种车载ecu应用程序更新系统方案，包括现场实施步骤、 系统功能需求、系统业务模型、系统总体结构、系统网络体系结构、系统通讯协议制定、系 统通讯过程制定、系统硬件设计、系统软件设计、更新成功验证。
37.下面对本实施方式进行具体说明，以下内容仅为方便理解提供的实现细节。
38.本实施方式中，现场实施步骤包括：若车主发现发动机性能下降，希望对其汽车该性 能进行提升，需要将汽车开到汽车ecu软件更新服务站。技术人员根据其要求判定需要更新 的目标ecu，技术人员通过更新服务器，此处一般采用pc机，在此pc机看作上位机，pc 机通过obd转换器连接至汽车车载自动诊断系统接口(on board diagnostics,obd)，该接口 处有can接口。obd转换器一端为can接口，一端为usb接口。技术人员通过上位机已 开发好的ecu更新控制程序，向目标ecu发起更新请求，将从原汽配厂家发来的新的应用 程序数据包，通过obd转换器传送到can网络中的目标ecu处。此处目标ecu看作下位 机，下位机负责响应上位机的更新操作。下位机接收到更新请求后，判断可以执行更新，向 上位机发送响应信息，上位机收到响应信息后，向下位机发送新等应用程序数据包，下位机 擦除flash待更新的应用程序存储块并写入接收数据，下位机写入完毕后向上位机发送结束更 新信息，同时启动更新成功验证程序验证是否更新成功，验证成功则更新成功，否则更新失 败。上位机收到结束更新信息后断开链接，更新结束。做ecu更新服务的汽车重新发动机后， 运行目标ecu新等应用程序。
39.本实施方式中，系统功能需求包括上位机发送更新请求，下位机响应更新请求，上位 机发送应用程序数据，下位机擦除flash存储器待更新的应用程序数据，擦除完毕后将接收的 新等应用程序数据包写入flash存储器中待更新的应用程序存储块中，写入完毕后下位机发送 终止更新信息，同时动更新成功验证程序验证是否更新成功，验证成功则更新成功，否则更 新失败。上位机收到结束更新信息后断开链接，更新结束。
40.本实施方式中，系统分为更新服务端即上位机和目标ecu即下位机两端，上位机为客 户端，下位机为服务器端。上位机向下位机发起应用程序更新请求，下位机接收到更新请求 后，判断是否可以执行更新，是向上位机发送响应信息，否发送不可执行更新信息。若
上位 机接收到了响应信息，此时双方建立了通信连接。上位机收到响应信息后，开始执行向下位 机发送新的应用程序数据包。下位机收到应用程序数据包后，判断待更新的应用程序所在存 储块位置，执行擦除存储器flash中待更新的应用程序数据操作，擦除完毕后将接收的新的应 用程序数据写入flash中待更新的应用程序存储块中。每次接收数据包时下位机判断是否按包 序号发送，否发送错误报告，要求重新发送，是按序号发送则写入flash指定位置。每次写入 后判断是否写入完毕，若写入完毕，向服务端发送结束更新的信息请求以断开通信连接，否 则继续写入。上位机收到所述写入完毕请求，断开通信连接，本次更新结束。
41.本实施方式中，系统总体结构如图1所示，更新系统服务端为客户端即上位机，此处 采用pc机，设备应用普遍便于获取。目标ecu为服务器端即下位机，此处采用具有can 口的嵌入式驱动板，设备功能全套，应用普遍便于获取。上位机和所述下位机之间通过 usb-can转换器连接。usb-can转换器有两个端口，分别是usb口和can口,usb口连 接pc机usb口，can口连接所述驱动板can口，解决pc机和带can口的嵌入式驱动板 之间等通信协议转换问题。
42.本实施方式中，系统网络体系结构中，下位机osi对等层协议结构模型采用底层基于 can2.0总线协议的sae j1939协议族。物理层采用can协议规范的iso 11898协议标准， 完成数据编码和解码、数据收发、故障检测等功能。数据链路层采用sae j1939-21协议，完 成帧结构、通信控制、错误检测等定义。应用层采用sae j1939-71协议，完成应用的管理和 支持通用的机制。
43.本实施方式中，系统通讯协议制定，包括种帧类型定义，分别定义了连接管理帧tp.cm 和数据帧tp.dt。接管理帧包括请求帧tp.cm_rts、响应帧tp.cm_cts、结束帧 tp.cm_endofack。本系统对每种帧数据域具体字段的定义与sae j1939协议设计有所不同， 需要根据系统需求作具体设计，但基本保留了sae j1939协议的设计思想，具体设计如下：
44.在一个例子中，本实施方式中包含tp.cm_rts帧和tp.cm_endofack帧数据域定义 如图8所示，tp.cm_cts帧数据域定义如图9所示，tp.dt帧定义如图10所示，tp.dt为 数据传输信息帧，它由发起端传输，其数据长度为8，数据页为0，pf为235，ps值为0， 优先级默认为7(最低级)，参数组号(parameter group number,pgn)值由其结构定义可计算，该 帧中，包序号占2个字节，值为1-255，数据段为6个字节，tp.dt帧数据域定义起始0-1字 节存放帧序号seq，占2个字节，2-7字节存放数据data，占6个字节。
45.在一个例子中，本实施方式中包含sae j1939 pgn结构定义，据sae j1939-21协议对 参数组号的定义，其由6个0位、保留位、数据页位dp、pdu格式pf(8位)和专用pdu域 ps(8位)组成，这些位域转换为一个参数组号。参数组号中，6个最重要的比特设置为0，然 后将保留位、数据页位dp和pdu格式字段(8位)字段复制到后面的18位中。参数组号分配 以线性方式分配，一个参数组的分配必须记住设置以下特点：优先级、更新率、包中到其他 网络设备重要的数据和与参数组号相关的数据长度。
46.在一个例子中，本实施方式中包含sae j1939帧仲裁域结构定义，p(priority)：这3位 是用来优化传输到总线的帧延迟。任何帧可以设置优先级，从最高级0(000)到最低级的 7(111)，默认所有面向控制的帧优先级为3(011)，其它专有帧、请求帧和应答帧优先级是6(110)。 本研究中，由于系统功能不需要特别高的优先级，故设置默认帧优先级p为最低
级7(111)， 若有其它的需求可自行设置较高的优先级。r(reserved bit)：保留位，这1位通过保留以供 将来sae使用。所有帧应该设定sae保留位为0。保留位未来定义可能是扩展pdu格式字 段,定义一个新的pdu格式。本研究中，r位设置为显性位0。dp(data page)：这1位设置 的目的是对两页参数组中某一页作选用,本研究中设置dp位为显性位0，srr(substituteremote request)和ide(identifier extension)为替代远程请求位和标识扩展位，这两位在 can2.0b中已详细定义，此处都设置为隐性位“1”，标准格式数据帧的优先级较扩展帧高。 pf(protocol data unit format)：数据单元格式为8位，pdu格式由pf值决定，据此pdu分 成两类格式pdu1和pdu2。ps(protocol data unit specific)：专用pdu域，其值由pf的值 决定，ps值决定pdu格式。
47.在一个例子中，本实施方式中包含sae j1939 pgn结构定义，据sae j1939-21协议对 参数组号的定义，其由6个0位、保留位、数据页位dp、pdu格式pf(8位)和专用pdu域 ps(8位)组成，这些位域转换为一个参数组号。参数组号中，6个最重要的比特设置为0，然 后将保留位、数据页位dp和pdu格式字段(8位)字段复制到后面的18位中。参数组号分配 以线性方式分配，一个参数组的分配必须记住设置以下特点：优先级、更新率、包中到其他 网络设备重要的数据和与参数组号相关的数据长度。
48.在一个例子中，本实施方式中包含sae j1939帧id结构定义，它由3位的帧优先级p, 保留位r,数据页位dp,8位1字节的帧格式pf,8位1字节的帧特定域ps，以及8位1字节的 源地址sa组成。
49.本实施方式中，系统通讯过程制定，系统通讯过程制定包括通信控制、通讯连接过程、 更新状态转移、更新流程。
50.在一个例子中，本实施方式中的上位机更新状态转移包括上位机发起更新请求对话， 若收到下位机响应命令执行传输更新程序数据包，否则关闭更新对话，然后重启进入下一轮 更新。下位机更新状态转包括下位机上电时运行系统初始化程序，包括硬件初始化，初始化 完毕后运行启动程序bootloader，启动程序根据启动标志位值判定运行指定应用程序，若收 到更新命名则转入执行更新程序，否则不做任何响应，更新完毕后系统重启，进入下一轮更 新状态转移。更新流程。
51.在一个例子中，本实施方式中的更新流程包括系统通信时序，如图2所示，步骤包括 s1-s9:
52.s1，用户在上位机控制台界面向下位机发出一个更新请求帧tp.cm_rts；
53.s2，下位机收到上位机发来等tp.cm_rts帧后判断是否可以执行更新；
54.s3，若判断可以执行更新，下位机向上位机发送响应帧tp.cm_cts，否则发送不可执 行更新信息，上位机收到下位机发来的响应帧tp.cm_cts后双方建立好通信连接；
55.s4，上位机收到tp.cm_cts帧后发送第一个数据帧tp.dt；
56.s5，下位机接收到第一个tp.dt帧后，先找到flash中待更新程序对应位置，然后执行 擦除，再将接收数据包写入到flash中，数据帧采用单帧传输，即数据包一个一个按包序号传 输，益处是在下位机按包序号接收并写入，确保数据正确按序写入；
57.s6，上位机向下位机依次发送数据包，直至发送最后一个数据包；
58.s7，下位机判断接收到最后一个数据包时，将最后一个数据包写入flash；
59.s8，同时下位机向上位机发送结束帧tp.cm_endofack；
60.s9，上位机收到tp.cm_endofack帧后打印更新完毕信息，同时断开通信连接，更新 结束。
61.在一个例子中，当上位机要对下位机执行应用程序更新操作时，上位机技术人员通过 用户界面来执行更新操作。用户通过界面向下位机发起更新请求，下位机收到上位机发来的 更新请求并发回一个响应给上位机，上位机收到下位机的更新响应后通信连接成功。双发通 信通过usb-can适配器作数据协议格式转换。此后，上位机开始向下位机传送应用程序数 据包，下位机接收数据时，首先判定待更新应用程序在flash存储区域的位置，然后擦除相应 flash存储块，最后将数据写入flash。每个数据包接收过程有严格的包序号校验，确保不漏 传或错传每一个数据包。写完数据后下位机发送结束数据传输命令，上位机收到此命令后断 开通信连接。下位机运行更新成功验证程序，若验证通过，重启系统，运行新应用程序，表 明下位机应用程序更新成功；若验证失败，会有相应提示表示更新失败，此处设计为三个led 全亮为通过，否则为失败。
62.本实施方式中，系统硬件设计中包括的下位机总体硬件结构，下位机总体硬件结构包 括stm32f103vet6微控制器模块、程序存储器模块、数据存储器模块、can接口模块、调 试模块、串口模块、电源模块、时钟和复位模块等。其中，can接口模块主要负责can帧 的收发，它提供了can总线与stm32f103vet6微控制器之间的接口，通信采用的协议为 can2.0b协议。
63.本实施方式中，系统软件设计包括上位机升级控制程序设计、下位机软件总体设计、 下位机bootloader子程序设计、下位机应用子程序设计、下位机dt帧处理子程序设计、can 接口函数调用关系。
64.在一个例子中，本实施方式中的上位机升级控制程序设计，如图3所示，步骤包括s1-s9：
65.s1，开启usb-can转接口设备，打开can通道，初始化can控制模块，打开can 接收线程；
66.s2，发送应用程序数据文件，读取文件总字节数和总包数，将数据总字节数和总包数 封装到tp.cm_rts帧中，对下位机发起更新请求；
67.s3，判断是否收到tp.cm_cts帧。这里采用握手通信过程确保通信过程可靠；
68.s8，若未收到进入重传机制重传tp.cm_rts帧。这里重传机制为一个循环判断，此设 计为了保证数据传输过程中丢失，提高更新效率和更新的稳定性；
69.s9，判断是否重传了3次。若3次s内重传收到tp.cm_cts帧，则进一步检测是否收 到tp.cm_tp.cm_cts帧。
70.s7，若重传3次还未收到tp.cm_cts帧则结束传输。
71.s4，若收到了tp.cm_cts帧，则进一步判断是否收到未收到tp.cm_endofack帧。 tp.cm_endofack帧判断在每个数据包发送前校验，确保不多发和写入一个无关数据包，保 证更新的数据准确性。
72.s6，若未收到tp.cm_endofack帧，则从第一帧依次按包序号传输tp.dt帧。
73.s5，若收到tp.cm_endofack帧，则更新完毕，下位机重启。
74.在一个例子中，本实施方式中的下位机软件总体设计，步骤包括：
75.系统上电，进行硬件初始化，如各类管脚，各类接口，系统时钟等初始化；
76.运行bootloader程序。这里启动程序通过存储器中的判断标志值确定选择启动flash 存储块中哪一个应用程序，判断标志值每次更新写入完毕应用程序数据后其值加1，通过判 断标志值设计，下次系统启动时为上次写入的最新应用程序，此设计确保更新的应用程序能 及时启动运行，同时也保证快速看到更新后的效果；
77.运行应用程序。
78.在一个例子中，本实施方式中的下位机bootloader子程序设计，如图4所示，步骤包 括s1-s7：
79.s1，系统初始化，主要完成系统时钟、按键、串口、can口相关功能的初始化。此处 设置系统时钟为72mhz，串口波特率设置为115.2kbps，can口波特率设置为100kbps，设置 can工作模式为收发模式，滤波模式接收所有帧等。
80.s2，根据判断标志flag的值判定启动flash中哪一块应用程序。此处设置应用程序app1 起始地址为0x08010000，应用程序app2起始地址为0x08040000。
81.s3，做好选择判断后启动相应应用程序。这里通过判断标志找到相应应用程序存储块 位置；
82.s5，找到位置后需判断应用程序存储块sram中是否有应用程序。此处判断是看栈指 针是否指向0x20000000；
83.s6，如果有应用程序，则运行选择启动存储块中的应用程序；
84.s7，如果无应用程序，则结束。
85.在一个例子中，本实施方式中的下位机应用子程序设计，如图5所示，步骤包括s1-s8：
86.s0，首先进行can初始化，如can口、can中断及can相关功能的初始化。此处 设置串口的波特率为115.2kbps，can口波特率为100kbps，设置can工作模式为收发模式， 滤波模式接收所有帧等；
87.s1，判断是否有收到can帧；
88.s2，若有收到can帧，即can口发来的数据接收中断，则进入can接收中断处理函 数，读取can接收缓存区中的数据；
89.s3，然后判断此数据是否为上位机发来的tp.cm_rts帧。此设计确保及时响应更新请 求；
90.s4，若为tp.cm_rts帧，则进入tp.cm_rts帧处理程序。处理完后回到can帧检测 处。此设计确保程序随时待命执行更新请求；
91.s5，若不是tp.cm_rts帧，则进一步判断是否为数据帧tp.dt；
92.s6，若为tp.dt帧，则进入tp.dt帧处理程序；
93.s7，tp.dt帧处理程序执行完毕后，更新完毕；
94.s8，若不是tp.dt帧，则结束。
95.针对在线更新过程中会可能出现突然掉电，传输误码，各种干扰导致升级失败等情况， 本系统做了如下设计工作，包括：
96.通信机制设计，上位机采用单帧数据发送机制，下位机接收到的每一帧来自上位机的 数据，需要做校验，若校验正确则将数据写入到flash中，若不正确则提示错误。通过此设计， 降低更新过程误传、漏传、通信无故断开等问题发生的概率。
数据域的第3-8共6个字节为传输的有效数据，其填充的内容，通过依次读取can发送缓冲 区中的数据获得。
145.bootloader程序选择启动核心代码，包括：
146.data_read＝(u16)(*(u32*)(flash_switch_boot_address))；
147.usart1_printf(usart1,"data_read flash1＝％d\r\n",data_read)；
148.if(data_read％2){
149.applicationaddress＝flash_app2_address；}
150.else{
151.applicationaddress＝flash_app1_address；}
152.flashstatus＝flash_complete；
153.flashstatus＝flash_erasepage(programme_addr i*flash_page_size)；
154.if(flashstatus！＝flash_complete){
155.usart1_printf(usart1,"write flash err\n")；}
156.bootloader程序完成应用程序的启动选择，通过data_read的值余除2进行判断，若不 能余除2，则下位机接收的数据存储在flash_app2_address存储地址，反之，则存储在 flash_app1_address存储地址。
157.本发明的第一实施方式涉及一种车载ecu应用程序更新技术，包括iap技术、启动控 制程序、下位机flash分区设计。
158.在一个例子中，本实施方式中的iap技术通过车载can总线接口实现更新服务端和目 标ecu之间的通信和数据传输。
159.在一个例子中，本实施方式中的启动控制程序，为了提升系统更新后的可靠性，新的程 序在写入下位机内部程序存储器时，原有的应用程序不会被覆盖掉，但不影响系统新应用程 序工作。因此本系统考虑采用交叉存储的方式，设置一个判断标志，通过判断标志的值来判 断接收后的新应用程序写入应用程序2存储块还是应用程序1存储块，每次更新完成后判断 标志值值加1，bootloader程序功能为选择启动应用程序app1还是应用程序app2。由于每 次更新完成后系统重启，判断标志的值都与上一次启动的值不一样，这就保证了新应用程序 写入不会覆盖到原先的应用程序，这种机制很好的保证了程序更新的可靠性，以防系统更新 程序后丢失掉重要的数据，给系统带来不可靠的隐患。
160.在一个例子中，本实施方式中的下位机flash分区设计，如图7所示，根据bootloader 程序大小将512kb的flash分两个区，即地址从0x08000000-0x0800 ffff共64kb存储空间 的bootloade程序和地址从0x08010000-0x0807 ffff共448kb的空间的应用程序。由于采 用是刚出厂的开发板，程序存储器为空白的，在更新操作开始前，需要用户将编译好的应用 程序和bootloader程序通过程序烧写工具烧录进程序存储块制定区域。