一种软件刷新防错刷写方法与流程

1.本发明涉及汽车变速器软件技术领域，特别涉及一种软件刷新防错刷写方法。


背景技术：

2.随着汽车市场对配置要求更新频率的增加,对整车厂而言,与配置和功能密切相关的控制器的更新也要提高效率来应对市场变化。针对仅需要更新控制器软件就可以满足配置或功能变化的情况,控制器刷写功能，升级功能是最直接有效的方式。但是在工程实际中，刷写不规范，售后流程不健全，工作繁重，往往导致刷写入控制器的软件出现这样或者那样的错误，严重的甚至造成批量事故，导致汽车厂严重抱怨，造成供应商索赔。并且由于消费者使用过程导致的相关软件问题，往往需要人为更新，若升级中出现任何问题，或引发退车可能，导致消费者对整车厂评价不高，严重影响整车厂信誉。故如何提高刷新控制器的准确性及效率是供应商急需解决的问题。
3.ecu在汽车电子产品开发中相对安全性，可靠性的指标要求很高，所以软件更新的情况在软件下载过程及售后都有可能出现，为方便售后服务，节约成本，同时避免对ecu硬件产品的破坏，汽车行业按照各种标准采用专用的诊断测试设备，通过标准的通信接口对ecu控制程序或者数据进行更新，bootloader就是为了完成上述功能，常驻在ecu内部flash特定位置的程序，基于客户定义的bootloader机制或者协助用户定制bootloader的机制，按照uds等通信协议，配合精简的底层驱动完成bootloader的程序开发，以实现程序的功能。


技术实现要素：

4.本发明提供一种软件刷新防错刷写方法，本发明能在保证控制器刷新效率的同时提高刷写准确性，提高软件开发工作的效率。
5.解决上述问题的技术方案如下：基于多通道sspc容性负载识别方法，包括以下步骤：一种软件刷新防错刷写方法，包括以下步骤：s1：刷新程序前，将bin文件起始值进行识别。
6.s2：刷新程序前，识别需要刷写的文件大小。
7.s3：读取硬件版本号时，采用10 02服务进入底层软件读取，并同时对比硬件版本号，规避翻库时有应用层硬件版本号导致的翻库tcu软件刷新不成功，在读取底层硬件版本号后并采用11 03复位，并进行软件刷新；s4：10 01服务与10 03服务间隔100ms，避免发送命令间隔时间太短带来的tcu不响应；s5：刷写过程中36服务传输数据时，分包大小采用1044；s6：针对应用层bin软件文件利用crc32或crc16文件进行校验，保证控制器数据刷写的一致性；
s7：设定11 03复位时间为3.5s提升软件刷新成功的概率；s8：在整个软件刷新过程采用通讯保持方式，当tcu报文持续时间为4s并无反馈时，发送通讯保持服务3e 80；s9：软件刷新完成后根据需要读取硬件版本、软件版本、软件件号并通过显示屏显示，方便刷新程序人员查看与对比；s10：加入写入did018b功能，并采用22服务读取写入的内容以便判断是否加入了弹射功能；s11：根据需求确定是否需要写入手柄信息，并将手柄信息打印出对应的log文件；s12：将变速箱的流水号写入控制器中，并采用22服务读取得到变速箱序列号，打印出的log文件采用10进制形式显示；s13：将4合一bin文件刷写入控制器中，减少配置文件，防止误操作情形。
8.优选地，在步骤s1中，将需要刷新的所有软件起始值进行提前识别，提前识别出不是想要刷新进入的软件，若出现识别出确实非正常软件造成，提示刷写失败及失败原因，避免错刷写软件情形。
9.优选地，在步骤s3中，通过c语言编程写函数，提前识别所有需刷写的文件的大小及长度，并将长度变量作为局部变量放入编写的语句中，根据识别出的长度大小可判断软件是否重复识别。
10.优选地，在执行步骤s3之前，通过uds读取控制器的底层的硬件版本号，提高翻库时硬件版本号写在应用层的软件刷新成功的概率，并判断待刷新的控制器硬件是否为所需的硬件，如果对比正确继续进行刷写，如果对比失败，提示刷写失败及失败原因，避免错误选择控制型号。
11.优选地，步骤s5中，最后一包的长度根据实际情况大小进行传输，将分包限制为tcu反馈的最大以下，提升刷新成功的概率。
12.优选地，步骤s11中，开发配置中通过2e服务写机械手柄或电子手柄，若写入错误，通过log文件打印提示错误问题。
13.本发明的软件刷写防错开发方法将控制器、软件、软件件号分块处理，针对软件刷新的相关硬件、对应软件版本、对应软件件号、人为填加在刷写配置中，若将要刷写的软件与实际符合，则刷新通过；反之则不能通过。这样,在保证控制器刷新效率的同时提高刷写准确性，提高软件开发工作的效率。
附图说明
14.图1为本发明的流程图。
具体实施方式
15.如图1所示，本发明的一种软件刷新防错刷写方法，包括以下步骤：s1：刷新程序前，将bin文件起始值进行识别；在本步骤中，将需要刷新的所有软件起始值进行提前识别，提前识别出不是想要刷新进入的软件，若出现识别出确实非正常软件造成，提示刷写失败及失败原因，避免错刷写软件情形。
16.s2：刷新程序前，识别需要刷写的文件大小。在本步骤中，通过c语言编程写函数，
提前识别所有需刷写的文件的大小及长度，并将长度变量作为局部变量放入编写的语句中，根据识别出的长度大小可判断软件是否重复识别。
17.在执行步骤s3之前，通过uds读取控制器的底层的硬件版本号，提高翻库时硬件版本号写在应用层的软件刷新成功的概率，并判断待刷新的控制器硬件是否为所需的硬件，如果对比正确继续进行刷写，如果对比失败，提示刷写失败及失败原因，避免错误选择控制型号。
18.s3：读取硬件版本号时，采用10 02服务进入底层软件读取，并同时对比硬件版本号，规避翻库时有应用层硬件版本号导致的翻库tcu软件刷新不成功，在读取底层硬件版本号后并采用11 03复位，并进行软件刷新；s4：10 01服务与10 03服务间隔100ms，避免发送命令间隔时间太短带来的tcu不响应，避免时间间隔太短导致控制器来不及反应出现的刷新失败问题。
19.s5：刷写过程中36服务传输数据时，分包大小采用1044。本步骤中，最后一包的长度根据实际情况大小进行传输，将分包限制为tcu反馈的最大以下，提升刷新成功的概率。
20.s6：针对应用层bin软件文件利用crc32或crc16文件进行校验，保证控制器数据刷写的一致性。在刷写驱动文件及app文件时，采用crc32或crc16算法对文件进行校验，保证数据刷写的一致性，防止误刷软件情形，同时也有利于与其他刷写工具进行刷新时对比，看是否刷写的软件为同一版软件。
21.s7：设定11 03复位时间为3.5s提升软件刷新成功的概率。采用11 03服务进行软件复位，并且限制复位时间为3.5s，提高刷新配置对软件的刷写能力，减少配置的修改次数，同时提升软件刷新时间。
22.s8：在整个软件刷新过程采用通讯保持方式，当tcu报文持续时间为4s并无反馈时，发送通讯保持服务3e 80。采用3e 80服务进行通讯保持，避免当tcu离线时间稍长时导致的不回复产生刷新失败。为避免此类情况发生，当tcu报文持续时间4s无反馈时，发送通讯保持服务提升刷新成功概率，兼容不同反应时间的tcu。
23.s9：软件刷新完成后根据需要读取硬件版本、软件版本、软件件号并通过显示屏显示，方便刷新程序人员查看与对比。
24.s10：加入写入did018b功能，并采用22服务读取写入的内容以便判断是否加入了弹射功能，为程序刷写成员提供判断依据。
25.s11：根据需求确定是否需要写入手柄信息，并将手柄信息打印出对应的log文件。本步骤中，开发配置中通过2e服务写机械手柄或电子手柄，若写入错误，通过log文件打印提示错误问题。根据实际项目需求也可不写手柄信息，操作灵活多样供软件刷新者使用，提示信息亦能及时传递出。
26.s12：将变速箱的流水号写入控制器中，并采用22服务读取得到变速箱序列号，打印出的log文件采用10进制形式显示。在特性数据刷写开始时，为方便追踪将变速箱流水号写入控制器中，并采用22服务读取得到变速箱序列号，同时打印出log文件并采用10进制形式进行显示，防止现场操作人员误刷软件入控制器。
27.s13：将4合一bin文件刷写入控制器中，减少配置文件，防止误操作情形，避免配置文件过多导致的误配置情形，防止翻库及零星刷写导致的误刷写问题，同时避免4bin文件在软件管理上所带来的管理混轮局面。
28.在软件刷写过程中，根据整车厂提供的刷写流程及相应的肯定及否定响应码进行肯定及否定回复，在刷写软件过程中分为一般分为预编程、编程、及后编程三个部分，预编程一般采用 10 03服务、 10 02服务、 10 01服务进行模式跳转，模式跳转结束后进行正式软件刷新与请求，依次请求10 03服务、 27 01服务、 27 02服务 、22f1 8a服务、 22 f0 89服务、22 f1 89服务、31 01 02 03服务 、10 83服务、85 82服务及 28 83 03 服务。
29.服务启用前，利用配置文件中的读函数识别不同bin文件的首数据，针对同一系列的文件，首数据均为相同，若不同则采取打印log方式回复，bin文件丢失，以此作为依据检验是否具有刷新所需要的文件，并且在服务启用前利用程序编写方式将配置文件的驱动bin，数据bin，大小均识别开来，并采用log文件方式打印出，方便开发人员查看长度是否正确，若长度问题出现明显错误则可立即判断问题所在，当然，每次刷写工具启动时均应该从0开始计数，防止刷写工具误识别文件长度，将第一次识别的值作为第二次识别的首数值。
30.为实现软件可识别底层硬件版本号，启用10 03服务跳转10 02服务，以此进入底层，达到读取底层硬件版本的目的，将所读取的硬件版本与配置填充的版本进行对比，达到防错刷写文件与硬件版本不匹配的目的出现问题能做到及时提示。读取底层版本号并对比完成利用11 03服务复位，复位后即可进行正常软件刷写流程。
31.编程阶段采用10 01 服务、10 03 服务 、10 02服务、 27 01服务、 27 02服务、 22 f1 70读版本信息、 22 f1 71读版本信息、 2ef1 84 写指纹信息、34 00 44 请求下载 、36 服务、 37 服务进行请求与反馈流程操作，在10 03与10 02服务间时间长度限值为100ms，充分留足控制反馈与刷写工具接受的时间，在36服务传输数据根据uds最大可接受范围进行有效改进，34服务的首地址按固定格式添加，传输数据的长度利用识别出的bin文件长度进行填充，通过右移24位，16位，8位分别填入不同的buffer位，将36服务的传输限值大小在1044，最后一包根据实际剩余值传输。37服务根据实际开发过程退出。
32.37服务退出完成后，利用31 01 ff 01 检验数据有效性及完整性，36服务完成或对驱动及app文件进行crc16计算，刷写工具内部根据计算的结果反馈crc校验值，与tcu反馈的值进行自动对比，若对比成功则进入后续服务请求中，刷写工具及tcu反馈的值生成txt格式数据，对比不成功时则可以方便的查找对比的数据与tcu反馈的数据差距，查找失败原因。
33.后编程阶段采用11 03服务、 10 03服务、 28 80 03服务、 85 81服务、 10 81服务。在11 03 服务复位采用延时函数设定时间3.5s 提高刷写效率，采用28 85服务使能数据发送与传输。软件刷新过程中在预编程10 83后启动3e 80通信保持间隔时间为4s，后编程步骤85 81服务中关闭通信保持。
34.特性数据写入放入程序刷新完成后，利用2e服务进行写入、利用数组提前填充did及每个数据长度，以此写入。在写入特性数据前首先写入变速箱序列号，通过识别出变速箱序列号的长度及位置调用2e服务写入，写入完成后采用22服务读取写入的did，根据实际情况转换为更有利于操作者识别出的数据，一般采用uds命令所读取的数据均为asc码，asc码不利于查看及技术交流，采用asc转十进制的方式并输出txt文件体现，方便查阅与交流。
35.根据工程实际需求，采用2e服务写入手柄信息值，手柄信息在特殊的场景有不同的要求，通过配置手柄信息的不同值以达到可人为筛选是否需要写入手柄信息。为更好管理刷新软件的数量，采用一个bin的方式比4个bin方式更加便捷，通过将4bin合一的bin文
件首地址及长度识别出，做到只刷写一个bin文件，以高效实现文件管理。
36.本发明的具体操作过程如下：1）读函数，指向对应bin文件，识别对应首地址，判断是否为所需文件。
37.2）while循环函数，利用while循环，识别对应的bin文件大小，利用变量memsize体现。
38.3）请求会话模式 10 03服务，诊断id：0x7e1，长度0x02。
39.4）请求默认会话模式10 02，诊断id：0x7e1，长度0x02。
40.5）请求22 f0 89读取硬件版本号，诊断id：0x7e1，长度0x03。
41.6）配置param内容，将硬件版本提前识别并采用if语句判断，查看版本内容是否一致。
42.7）请求会话模式10 03服务，诊断id：0x7e1，长度0x02。
43.8）请求会话模式28 85服务，诊断id：0xdf，长度0x02。
44.9）请求3e 80服务，诊断id：0x7df，长度0x02。
45.10）请求复位11 03服务，诊断id：0x7e1，长度0x02。
46.11）请求会话模式10 01服务，诊断id：0x7e1，长度0x02。
47.12）请求会话模式10 03服务，诊断id：0x7e1，长度0x02。
48.13）设置延时函数时间delay 100ms函数。
49.14）请求会话模式10 02服务，诊断id：0x7e1，长度0x02。
50.15）请求34服务下载，地址34800，诊断id：0x7e1，长度0x11，传输缓存txbuffer[8]》》 24 ，txbuffer[9]》》16，txbuffer[10]》》8，txbuffer[11]。
[0051]
16）请求36服务，诊断id：0x7e1，长度0x02，分包大小1044，填充方式15 10 36 0x。
[0052]
17）请求31 01 ff 01服务，诊断id：0x7e1，长度0x04。
[0053]
18）crc16算法。
[0054]
19) crc值接收缓存rxbuffer[] = rxbuffer[]函数自动判断。
[0055]
20) 请请求11 03服务，诊断id：0x7e1，长度0x02。
[0056]
21）请求85 81服务，诊断id：0x7e1，长度0x02。
[0057]
22）请求会话模式22 f1 89服务，诊断id：0x7e1，长度0x03。
[0058]
22）请求会话模式22 f0 89服务，诊断id：0x7e1，长度0x03。
[0059]
22）请求模式22 f1 88服务，诊断id：0x7e1，长度0x03。
[0060]
22）请求会话模式10 03 服务，诊断id：0x7e1，长度0x02。
[0061]
23）请求关闭3e 80服务，诊断id：0x7df，长度0x02。
[0062]
24）请求2e 01 87服务，诊断id：0x7e1，长度0x02。
[0063]
25）转换asc码。
[0064]
26）请求2e 01 83服务，诊断id：0x7e1，长度0x02。
[0065]
27）4bin合一请求34 00 44不同首地址刷写，逐步完成所有bin文件刷写。
[0066]
为使本发明的目的、技术方案和优点更加清楚，结合本发明实施例中的附图，对本发明实施例中的技术方案进行更加详细的描述。所描述的实施例是本发明的一部分实施例，而非全部的实施例。通过参考附图描述的实施例为示例性的，旨在用于解释本发明，而不能简单地理解为对本发明的限制。基于本发明的实施例，本领域技术人员在没有作出创
造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。