KWP诊断通讯协议

1、基于K线白KKWP200的、议标准主要包括ISO/WD14230-1-14230-4,各部分协议与OSI模型的对应关系如表所示表1KWP 2 0 0 0 协 议 与OI S 模 型 的对应关系OSI 模型基 于 K 线 的 K WP 2 0 0 0基 于 CAN 总 线 的 KWP 2 0 0 0应用层I SO 14230-3I SO15765-3络层N/AI SO15765-2数据链路层I SO 14230-2ISO 11898- 1物理层I SO14230-1SO9 1 41 -用户选择表述层N/AN/A会话层N/AN/A传输层N/AN/AISO14230-1规定了KWP200的、议的物理

2、层规范（K线、L线），它在ISO9141-2的基础上把数据KWP200O勺数据链路层协议，包括报文结构、交换系统扩展到了24V电压系统。ISO14230-2规定了初始化过程、通讯连接管理、定时参数和错误处理等内容。K 线的报文包括报文头、数据域和校验和三部分，其中报文头包含格式字节、目标地址（可选）、源地址（可选）和附加长度信息（可源地址（可选）和附加长度信息（可Fmtgt1Src1Len1WP00报文3SI2)Dat aCS最长551）Fmt 的 A1A0 位2） 服务标识符 （ServiceID）， 数据域的第 1 个字节KWP200（0KeywordProtocol2000）是欧洲汽车领

3、域广泛使用的一种车载诊断协议标准，该协议实现了一套完整的车载诊断服务，并且满足E-OBD（EuropeanOnBoardDiagnose）标准。KWP200的、议仅对其中三个子层进行了定义说明，即：应用层（第七层）、数据链路层（第二层）和物理层（第一层）。物理层：这部分描述了基于IS09141用以实现诊断服务的物理层，用于配置硬件系统，指导接口电路的设计，同时将在IS09141-2中描述的物理层扩展成可以满足提供12V或24V电压的车辆的条款。数据链路层：这部分定义了数据的传送格式，描述了诊断服务的通用要求，允许1个诊断仪控制在1个随车ECU侬1如电子燃油喷射、自动变速箱及防抱死系统等)中的诊

4、断功能。这些随车ECUK于车辆中，通过串行数据链路相连接。应用层：这部分包含如下规范:服务标识符的字节编码及其十六进制数值；诊断服务请求与响应参数的字节编码；标准参数的十六进制数值。根据IS014230的规定，KWP2000!信消息基本格式如图1所示。一条消息Z勾包括头部(header)、数据字节(data-byte)、校验和(checksum)等三部分。图1KWP2000的报文格式Fmt格式字节(Formatbyte)Tgt目标地址字节(Targetaddressbyte)Src源地址字节(Sourceaddressbyte)Len长度字节(Lengthbyte)Sid服务标志符字节(Sev

5、iceIdentificationbyte)，分请求服务和响应服务两类CS校验和字节(Checksumbyte)上标1表示可选，由格式字节(Fmt)决定上标2表明服务标识(Sid)是数据段的一部分(Data)在开始诊断服务之前，诊断设备必须对ECU发动机enginecontrolunit)进行初始化，通过ECU的响应获取ECU的源地址、通讯波特率、支持的报文格式、定时参数等信息。ECU所支持的报文和定时参数信息包含在ECUM回的“关键字(KeyWord)”中(这也是协议命名的由来)。关键字由两个字节构成，如图2所示，关键字的低字节中各位的含义如表1所示。图2关键字格式表1关键字低字节中各位的含

6、义测试器(诊断设备)可以采用两种方式对ECU®行初始化，即5Baud初始化和快速初始化。对于这两种初始化的时序在数据链路层协议中均有明确规定。完成初始化过程后，测试器和ECUT可进行应用层的诊断服务和响应。IS014230-3规定了应用层的服务规范，包括诊断管理功能组、数据传输功能组、诊断信息传输功能组、输人/输出控制功能组、远程启动ECUJ程功能组、数据上载/下载功能组和扩展功能组。KWP2000最初是基于K线的诊断协议。由于K线物理层和数据链路层在网络管理和通讯速率上的局限性，使得K线无法满足日趋复杂的车载诊断网络的需求。而CAN(ControllerAreaNetwork)网络

7、由于其非破坏性的网络仲裁机制、较高的通讯速率(可达1Mbps)和灵活可靠的通讯方式，在车载网络领域广受青睐。因此，近年来欧洲汽车领域广泛采用了基于CAN总线的KWP2000即ISO15765协议，而基于K线白KWP200的理层和数据链路层协议将逐步被淘汰。KWP200的、议分析和基于CANoe的开发测试摘要：本文介绍了欧洲汽车领域广泛采用的车载诊断协议KWP2000针对KWP200修断服务在K线(ISO14230)和CAN总线(ISO15765)上的两种实现方式，对协议的核心内容和发展历史进行了较为深入的剖析和对比。本文还介绍了采用Matlab/Simulink/StateFlow进行协议开发

8、的一般流程，以及该协议在Vector公司的CANoe软硬件平台上的应用实现和开过程。关键词：KWP2000K线，CAN总线，开发，CANoe1前言在汽车故障诊断领域，针对诊断设备和汽车ECU间的数据交换，各大汽车公司几乎都制订了相关的标准和协议。其中，欧洲汽车领域广泛使用的一种车载诊断协议标准是KWP200(0KeywordProtocol2000)，该协议实现了一套完整的车载诊断服务，并且满足E-OBD(EuropeanOnBoardDiagnose)标准。KWP200最初是基于K线的诊断协议，由于K线物理层和数据链路层在网络管理和通讯速率上的局限性，使得K线无法满足日趋复杂的车载诊断网络的

9、需求。而CAN网络(ControllerAreaNetwork)由于其非破坏性的网络仲裁机制、较高的通讯速率(可达1Mbps)和灵活可靠的通讯方式，在车载网络领域广受青睐，越来越多的汽车制造商把CAN总线应用于汽车控制、诊断和通讯。近年来欧洲汽车领域广泛采用了基于CAN总线的KWP2000即ISO15765协议,而基于K线白KWP2000I理层和数据链路层协议将逐步被淘汰。在网络协议开发和测试应用方面，美国MathWorks公司和德国Vector公司提供了功能强大的开发和测试工具，可分别用于协议栈源码的开发和ECUW试。2基于K线白KWP2000、议基于K线白KKWP2000、议标准主要包括I

10、SO/WD14230-114230-4,各部分协议与OSI模型的对应关系如表1所示。表1KWP200的、议与OIS模型的对应关系OSI模型应用层表述层会话层传输层网络层数据链路层物理层ISO 14230-1 规定了基于K线白K KWP2000ISO 14230-3N/A基于CAN总线的KWP2000ISO 15765-3N/AN/AN/AN/AISO 14230-2ISO 14230-1 , ISO9141-2N/AN/AISO 15765-2ISO 11898-1用户选择KWP2000、议的物理层规范（K线、L线），它在ISO 9141-2的基础上把数据交换系统扩展到了24V电压系统。ISO

11、14230-2规定了KWP200的数据链路层协议，包括报文结构、初K线的报文包括报文头、数据域和校验始化过程、通讯连接管理、定时参数和错误处理等内容。和三部分，其中报文头包含格式字节、目标地址（可选）、源地址（可选）和附加长度信息（可选）如表2所示。表2基于K线白KKWP200报文结构3报文头数据域校验和FmtTgt1）Src1）Len1）SId2）.Data2）.CS最长4字节最长255字节1字节1）可选字节，取决于格式字节Fmt的A1A（0i2）服务标识符（ServiceID）,数据域的第1个字节在开始诊断服务之前，诊断设备必须对ECUS行初始化，通过ECU的响应获取ECU的源地址、通讯波

12、特率、支持的报文头格式、定时参数等信息。ECU所支持的报文头和定时参数信息包含在ECU返回的“关键字（KeyWord）”中（这也是协议命名的由来）。关键字由两个字节构成，如图1所示，关键字的低字节中各位的含义如表3所示。£ i ffl G salm 4L R f PI lir Ffr TF I图1关键字格式3表3关键字低字节中各位的含义3Bit=0=1AL0不支持格式字节中的数据长度信息支持格式字节中的数据长度信息AL1不支持附加长度字节支持附加长度字节HB0不支持一个字节的报文头支持一个字节的报文头HB1不支持在报文头中包含目标地址/源地址支持在报文头中包含目标地址/源地址TP0*

13、）采用正常定时参数设置采用扩展定时参数设置TP1*）采用扩展定时参数设置采用正常定时参数设置*）只允许TP0,TP1=0,1或者1,0诊断设备可以采用两种方式对ECU行初始化一一5Baud初始化和快速初始化，对于这两种初始化的时序在数据链路层协议3中均有明确规定。完成初始化过程后，诊断设备和ECUPT可进行应用层的诊断服务和响应。ISO14230-3规定了应用层的服务规范，包括诊断管理功能组、数据传输功能组、诊断信息传输功能组、输入/输出控制功能组、远程启动ECU例程功能组、数据上载/下载功能组和扩展功能组。在诊断服务请求/响应过程中，诊断设备和ECU、须遵循图2所示的时序和相关定时参数。对于

14、初始化和诊断服务过程中出现的各种定时错误，在数据链路层和应用层协议里面都有相应的处理规范，诊断设备及ECU的应用程序都必须严格遵守。ECU 1ECU2该断设备服务响应服务响应服得请*旧用一 P2 .-一 1 一 L; 4 让一口 口一一口P : “p ;图2K线诊断服务时序图33基于CAN总线的KWP2000、议基于CAN总线的KWP2000、议实际上指的就是ISO/WD15765-115765-4,该协议把KWP200应用层的诊断服务移植到CAN总线上。数据链路层采用了ISO11898-1协议，该协议是对协议的进一步标准化和规范化；应用层采用了ISO15765-3协议，该协议完全兼容基于K线

15、的应用层协议14230-3,并加入了CAN总线诊断功能组；网络层则采用ISO15765-2协议，规定了网络层协议数据单元（N_PDU如表4所示）与底层CANB据帧、以及上层KWP200服务之间的映射关系，并且为长报文的多包数据传输过程提供了同步控制、顺序控制、流控制和错误恢复功能。表4网络层协议数据单元（N_PDU格式7地址信息协议控制信息数据域N_AI1）N_PCI2）N_Data3）1）地址信息：包含源地址（SA）、目标地址（TA）、目标地址格式（TA_Type）和远程地址（RA）2）协议控制信息：包含四种帧格式，见表53）数据域：KWP200服务标识符（ServiceID）+服务参数应用

16、层协议规定了四种服务数据结构，<Service_Name>.Request、<Service_Name>.Indication<Service_Name>.Response和<Service_Name>.Confirm,分别用于诊断设备（Tester）的服务请求、ECU的服务指示、ECU的服务响应和Tester的服务确认。这些数据结构中包含了地址信息、服务请求ID和服务请求参数等内容。基于CAN总线的KWP200哈断服务流程如图3所示。图3基于CAN总线的KWP200哈断服务流程图从上面的服务流程可以看出，基于CAN总线的KWP2000、议支持多

17、包数据传输，并且多包数据的管理和组织是在网络层完成的，应用层不必关心数据的打包和解包过程。为实现这一功能，网络层定义了四种PDU（以PCI类型进行区分，如表5所示）：单帧（SingleFrame,SF）数据域及PCI可在一个CANB据帧中容纳时，服务报文以单帧CAN报文进行发送。第一帧（FirstFrame,FF）数据域及PCI不能在一个CANB据帧中容纳时，服务报文以多帧CA咐艮文进行发送，其中第一帧（FF）除传送数据外，还包含了多包数据的长度信息。连续帧（ConsecutiveFrame，CF）多包数据中除第一帧外的连续数据帧，除传送数据外，还包含了多包数据的包序号。流控制帧（FlowCo

18、ntrol，FC）用于多包数据传输过程中的流控制，不包含数据，只包含流控制状态、数据块大小和最小间隔时间等流控制信息。表515765协议网络层四种PDUX寸应的PCI格式7Byte#1Byte#2Byte#3N_PDU名称Bit#7-4Bit#3-0N/AN/A单帧（SF）N_PCItype=0SF_DL1)N/AN/A第一帧（FF）N_PCItype=1FF_DL2)N/A连续帧（CF）N_PCItype=2SN3)N/AN/A流控制帧（FC）N_PCItype=3FS4)BS5)STmin6)PCI 的长度不包括在内。1） 单帧数据中数据域的字节长度，2） 多包数据的数据域字节总长度。3）

19、 多包数据的数据包编号。4） 流控制状态信息。5） 数据块大小。6） 多包数据传输的最小时间间隔。多包数据的传输流程如图4所示。发送节点首先发送“第一帧”，告知接收节点将要发送的数据的总长度；接收节点分配好资源、准备接收数据，然后以一帧“流控制帧”告知发送节点一次可以发送的数据包数目和时间间隔；发送节点接下来就根据接收节点的接收能力将编好序号的数据包依次发送过去。发辽卷卡捱收节点图4多包数据传输流程图在数据传送过程中，一个网络层PDU编排成一个CANB据帧，它们之间的对应关系由寻址模式(Addressingmode)决定。基于ISO15765协议规定了四种寻址模式：正常寻址模式(Normal)

20、、正常固定寻址模式(Normalfixed)、扩展寻址模式(Extended)和用于远程诊断的混合寻址模式(Mixed)。其中，正常固定寻址模式必须采用CANT展帧，并且SAEJ1939为该寻址模式下的KWP2000诊断服务保留了两个专用参数组编号(PGN:其中PF=218(PF的具体定义请参考SAEJ1939数据fcn )。正常固定寻链路层协议)的参数组用于物理寻址(phy),PF=21弼参数组用于功能寻址(第一帧(FF)011(b in)218(dec)-phy219(dec)-fcnN TAN SAN PCIN Data连续帧(CF)011(b in)218(dec)-phy219(de

21、c)-fcnNTAN SAN PCIN Data流控制(FC)011(b in)218(dec)-phy219(dec)-fcnNTAN SAN PCIN/AN_PDUCAN2眼标识符CANB据域口28262524231615870123单帧011(b00218(dec)-phyN_TAN_SAN_PCIN_DataPDUCANB据帧之间的对应关系如表6所示。址模式的表6正常固定寻址模式下NPDUWCANB据帧之间的对应关系(SF)219(dec)-fcn45678CANB据域的第一个字节用于填充远程地址混合寻址模式与正常固定寻址模式类似，唯一的区别是(RA),N_PCI和诊断服务数据的填充位

22、置向后移动一个字节。混合寻址模式用于跨越网段进行远程诊断，远程诊断的机制如图5所示。图中CAN和CAN两个不同的子网通过网桥相连，网桥在子网1中的源地址为200,在子网2中的源地址为10,位于子网1中的诊断设备(源地址为241)可通过网桥对子网2中的ECU(源地址为62)进行诊断。图5跨越网段的远程诊断4两种协议的简单比较从前面基于K线和基于CAN总线的KWP200岫议可以看出，两种协议在物理层、数据链路层及网络层（15765）上存在以下主要差别，这也是K线被CAN总线取而代之的主要原因所在：K线通讯速率较低，最大波特率仅为10400bps；CAN总线通讯速率较高，最大波特率可达1Mbps。K

23、线采用单端信号传输，抗干扰能力较弱，可靠性较差；CAN总线采用差分信号传输，抗干扰能力强，信号传输的可靠性高。K线诊断在启动应用层诊断服务之前必须对ECUS行初始化建立连接，并且初始化过程比较复杂；而基于CAN总线的诊断设备不需要对ECUt行初始化即可进行诊断服务。K线诊断应用程序开发者必须亲自管理数据传输过程中的字节间定时，并处理底层通讯错误；CANB据帧以整帧报文的形式进行发送，应用程序开发者不必管理字节间定时，并且CAN总线物理层和数据链路层具备完善的错误检测和错误恢复机制，应用程序不必监视和处理底层通讯错误。K线网络结构单一，网络管理功能很弱；而利用CAN总线可构建复杂的网络结构，可跨

24、越网段进行远程诊断。K线网络采用破坏性的仲裁机制，当诊断设备采用功能寻址与多个ECUt行通讯时，为避免总线冲突，ECUFF发者必须采取措施保证多个ECU顺序访问总线；而CAN网络采用非破坏性的仲裁机制，并且仲裁过程由数据链路层完成，当诊断设备采用功能寻址与多个ECU®行通讯时，ECLFF发者不必考虑总线访问冲突问题。K线服务报文最大字节长度仅为255,无法满足更长报文的传输要求，并且在长报文的传输过程中用户必须自己采取措施进行连接管理，可靠性和兼容性较差；而CAN总线诊断服务报文最大字节长度可达4096（12位），对于长报文的传输，网络层协议还具备标准化和规范化的同步控制、顺序控制、

25、流控制和错误恢复等功能，具备很高的可靠性、兼容性。5KWP200O议栈的开发及测试从前面的协议分析可以看出，无论是基于K线还是CAN总线的KWP2000、议，都是逻辑非常复杂的系统，并且具有严格的定时和错误处理规范。如果采用纯手工的方式来进行KWP2000、议栈的开发，不仅要耗费大量的时间和人力，其通用性、完备性、可靠性和可维护性都很难保证。而MATLAB/Simulink/StateFlow不仅具备方便快捷的上层实时仿真环境，还集成了高效的嵌入式代码自动生成工具，为协议栈的开发和维护提供了强大的支持平台。此外，由德国Vector公司的CANoe软件和相关硬件板卡组成的应用开发平台，可用于汽车

26、网络（CANLin等）的上层协议开发和系统测试，该平台同时支持基于K线和CAN总线的KWP200修断协议，可作为ECUffi诊断设备的测试标准。图6是协议源码开发过程示意图。首先在MATLAB/Simulink/StateFlow中遵照协议标准进行KWP200岫议栈开发，在仿真调试环境下实现通讯逻辑、定时控制和错误处理，待系统完善后利用StateFlow嵌入式代码生成工具自动生成协议栈C代码，并与目标系统的底层驱动进行集成，然后植入目标系统形成应用程序，最后再利用CANoe乍为标准进行系统集成测试。图6KWP200O议栈开发及测试流程在MATLAB/Simulink/StateFlow中进行协

27、议栈仿真开发是协议栈开发过程中的关键环节，在这一过程中必须严格遵照协议标准来实现通讯逻辑，往往需要经过多次“设计-仿真-修改”循环才能使系统最终趋于完善。MATLAB勺图形界面提供了方便快捷的仿真输入/输出接口，可大幅度加快开发进度。CANoe的KWP2000、议测试环境如图协议栈开发完成后可利用CANoN乍为标准进行系统集成测试,7所示。CANoe的支门户.国股山户界而数黑交换及逻辑控制程序网指净思放和:内底层道泄模共冏给毅据M业拄制RuuL_HOJ2图7CANoe的KWP200测试环境示意图CANoe中的KWP200实际指的是基于CAN总线的KWP2000即15765协议。由于CANoeB

28、认的硬件板卡是CAN#,因此在建立仿真程序时，只需将ECU勺网络模块设置为即可进行CAN总线的KWP2000服务测试。中包含15765应用层协议中规定的服务请求、服务指示、服务响应和服务确认接口函数，用户调用这些函数即可完成Tester端和ECU端的KWP200畛断服务。此外，该模块中的功能函数还可对ECU的源地址、目标地址、寻址模式等参数进行动态设置。需要注意的是，目前只提供了部分KWP200服务的接口函数，如果用户需要进行其它的KWP200服务测试，必须根据KWP200而用层协议构造服务报文数据，然后调用该模块中的KWP_DataReq()和KWP_GetRxData()函数进行报文的发送

29、和接收。进行基于K线白KKWP200服务测试时，需要将模块加入CANo明真环境，并使用一个代理节点来实现CAN网络和K线之间的报文车七发。此时CANoe用计算机的串口，并通过一个串口/K线转换器与实际的ECU相连，如图8所示。CANoe诊断节点R0代理节点cam (虚拟)图8CANoe中基于K线白KKWP200测试连接示意图6结束语KWP200是一套非常完善的车载故障诊断协议标准，协议的分层结构使得KWP200修断服务并不依赖于某种特定的网络介质，其应用层可以移植到任何一种物理层和数据链路层协议之上。基于CAN总线的KWP200顺应了目前车载网络发展的大趋势，将逐步取代K线诊断协议，成为下一代

30、车载诊断协议的主流之一。MATLAB/Simulink/Stateflow为协议栈开发提供了方便直观的图形用户接口和功能强大的仿真调试环境及代码生成工具，为嵌入式开发开辟了一条高效快捷之路。Vector公司的CANo/口相关硬件板卡是一个功能强大的应用开发平台，可针对基于K线和CAN总线的KWP200进彳TECU和诊断设备的上层协议开发、测试及仿真。摘要：结合国外汽车厂商广泛采用的车载诊断协议KWP2000,LIN总线下的ECUB线编程进行研究和方法设计，并对具体的硬件设计与软件实现进行了分析与阐述。关键词：KWP2000ECU线编程；LIN总线；MC9s08AW601.引言在汽车故障诊断领域

31、，针对诊断设备和汽车ECU间的数据交换，各大汽车公司几乎都制订了相关的标准和协议。其中，国外汽车厂商，包括大众、通用、奔驰、戴姆勒-克莱斯勒、JEER三菱、道奇等广泛使用的一种车载诊断协议标准是KWP2000(KeyWordProtocol2000)。该协议实现了较为完整的车载诊断服务，并且满足OBDII诊断要求。LIN总线(LocalInterconnectionNetwork)是一种单线车载网络，采用类似于标准串口的通讯格式，由于其协议简单，通信可靠性好，实现成本低，近年来得到了迅速的发展。2.基于KWP2000ECU4线编程研究ECU的在线编程指ECUb于工作状态时通过网络通信更新其中的

32、应用程序，从而实现改善控制器性能、提高安全性、改善排放、改善燃油经济性、提高用户满意度等目的，在设计和试制阶段，该功能的实现为程序的更新提供极大的方便。与传统的一对一的在线编程方式不同，由于KWP2000网络上传输，必须考虑其它控制器的反应，必须对目标控制器作出正确的识别，必须保证数据传输的完整性等等。基于KWP200协议ECUE线编程包括以下步骤：1)切换到扩展诊断状态：该步骤用于将控制器切换到一个特别的诊断状态，使得系统可以响应扩展诊断命令。2) 识别ECU该步骤用于上位机识别特定ECU及相应软硬件和数据的版本信息，上位机由此可决定能否执行FLASHY线编程。3) 关闭网络上所有控制器的故

33、障码识别和存储功能：该步骤禁止控制器在接下来的编程期间检测和记录故障。4) 关闭常规信息传递：该步骤禁止所有控制器的常规信息传送，使网络上只有诊断和网络管理消息收发，为在线编程让出足够的总线带宽。5) 启动在线编程模式：将控制器切换到代码保护区运行Bootloader程序，该模式关闭了中断，因此具有较快的响应速度。6) 开启安全限制：允许在线编程过程中的安全功能，开启这些安全功能后使得ECUM以执行特定的过程。7) 下载软件锁：上位机将关键代码下载到ECU执行这些代码可完成FLASH的擦除和重写。8) 擦除FLASHECSM亍上一步骤收到的关键代码，擦除完成后，ECUW清除该段关键代码。9)

34、下载数据：该过程下载新的程序到ECU的FLASH10) 校验数据：在此过程中ECU佥查下载的数据，如果判断为正确，则在FLASH中写入识别码和代码校验数据。11) 复位ECUECUa行复位，恢复到正常工作状态。12) 开启常规信息传递：重新开启网络上其它控制器上的常规信息传递。13) 开启故障码识别和存储功能：重新开启网络上其它控制器的故障码识别和存储功能。3.基于KWP2000ECU4线编程设计与实现硬件设计系统CPU用Freescale公司的MC9s08AW60该芯片内部集成了标准串口控制器，LIN总线驱动器采用了PHILIPS公司的TJA1020,驱动部分电路如图1,由硬件部分实现了通信

35、协议的物理层和数据链路层。图1.LIN总线驱动部分电路图软件设计与实现内存地址分配MC9S08AW60存储空间分配如图2:图2.存储空间分配示意图以下代码实现了上述的芯片配置。/*设代码保护区为0xfc000xffff*/constvolatileNVPROTSTR_NVPROT0x0000ffbd=0xfa;/*关闭芯片后门锁，打开中断向量表重映射，新的中断向量表地址为0xfbc00xfbff*/constvolatileNVOPTSTR_NVOPT0x0000ffbf=0x3e;软件实现ECU程序的状态切换流程图如图3:图3.程序状态切换流程图说明：1)根据上位机的KWP200指令，程序在

36、以下5种工作状态中切换，如表1:表1程序工作状态表2)通信中用到以下KWP200命令，如表2:命令对应代码切换到扩展诊断过程命令1092查询目标查询ECUID1a87ECUiR别码查询应用代码ID1a9c命令查询Bootloader程序1a9eID查询数据区ID1a9d禁止故障码记录命令8502ff000101禁止常规通信数据收发命令2802开启安全限请求密码种子2705制命令回复安全密码2706切换到编程模式命令1085数据传送命请求下载数据34xx令数据传送36xx请求结束下载37xx数据校验31e101开启常规通信数据收发命令2902开启故障码记录命令8502ff0002复位命令1101表2:命令说明表3)由于芯片结构的原因，程序在写flash时必须跳到RAM执行，以下代码定义了用于存储关键代码的RAM在间和指向该空间的函数CriticalProcess()。volatileunsignedcharcriticalProcess100;/*定义RAMS间用于存储关键代码*/#defineCriticalProcess(void(