Interpreters April 01 2011

Service Programming System (SPS) Interpreter Programmers Reference Manual
Creation Date: March 1, 1993 Version Date: April 01, 2011 Authoring Group: GM Customer Care & Aftersales - Product Engineering Document Name: Interpreters_April_01_2011.docx
The information contained within this document is proprietary to General Motors Company (GM)
1993-2011 General Motors Company, GM Customer Care & Aftersales. All Rights Reserved.
Page
Table of Contents
Service Programming System (SPS) ................................................................................................................... 1 Table of Contents ................................................................................................................................................. 2 Overview .............................................................................................................................................................. 6 Utility File Structure .............................................................................................................................................. 7 Format of Header Information ....................................................................................................................... 8 Format of Interpreter Instructions .................................................................................................................. 9 Device (ECU) Specific Control Routines and/or Service Request Data Routines ............................................. 10 Reprogramming Algorithm Overview ................................................................................................................. 11 Additional Utility File Information - Best Practices and recommendations ......................................................... 12 Programming Storage Buffers Recommended Usage ................................................................................... 15 Interpreter 0 - UART Communications Programming Op-Codes ...................................................................... 16 UART Support for No Communication Faults.............................................................................................. 17 UART Return Type Processing ................................................................................................................... 18 00 Op-Code: Enable Normal Communications ........................................................................................... 19 01 Op-Code: Request message from the device ........................................................................................ 20 02 Op-Code: Request memory dump from the device using Mode 2 (Saturn EEPROM) ........................... 21 03 Op-Code: Verify programming of a EEPROM device (NAO EEPROM) ................................................. 23 04 Op-Code: Device control - Mode 4 ......................................................................................................... 24 05 Op-Code: Ram download request - Mode 5 ........................................................................................... 26 08 Op-Code: Disable Normal Communications........................................................................................... 27 09 Op-Code: Enable Normal Communications ........................................................................................... 28 0A Op-Code: Clear Trouble Codes - Mode 10 ............................................................................................ 29 0C Op-Code: Program EEPROM - Mode 12 ............................................................................................... 30 0D Op-Code: Perform Security - Mode 13................................................................................................... 32 20 Op-Code: Receive a normal mode message from device ...................................................................... 33 A3 Op-Code Read Data from Specified Sequential Addresses (Electric Vehicle) Mode 3 ......................... 34 C0 Op-Code: Download Routine to RAM and Execute using Mode 6 ......................................................... 35 C1 Op-Code: Download Routine to RAM and Execute using Mode 16 ....................................................... 37 C2 Op-Code: Download Routine to RAM and Save Two Byte Response using Mode 6 ............................ 39 C3 Op-Code: Download Routine to RAM and Execute using Mode 6 (Electric Vehicle) ............................. 40 C4 Op-Code: Download Routine to RAM using Mode 20 (Holden Telematics) .......................................... 42 C5 Op-Code: Execute Routine using Mode 21 (Holden Telematics) .......................................................... 44 D0 Op-Code: Download Calibration / Software File using Mode 6 .............................................................. 45 D1 Op-Code: Download Calibration or Software Module using Mode 16 .................................................... 47 D2 Op-Code: Download VIN using Mode 6 & 16 ......................................................................................... 48 D4 Op-Code: Download Calibration / Software File using Mode 6 (Saturn EEPROM) ............................... 50 D5 Op-Code: Download Calibration / Software File using Mode 12 (Electric Vehicle) ................................ 52 D6 Op-Code: Erase Flash Block using Mode 22 (Holden Telematics)........................................................ 53 D7 Op-Code: Download Software Module using Mode 23 (Holden Telematics) ......................................... 54 D8 Op-Code: Execute Software Module using Mode 24 (Holden Telematics) ............................................ 56 F0 Op-Code: Wait for Poll from a Device .................................................................................................... 57 Interpreter 1 - Class 2 Communications Programming Op-Codes .................................................................... 58 Class 2 No Communications Processing .................................................................................................... 59 Class 2 Response Processing ..................................................................................................................... 60 01 Op-Code: Setup Global Variables .......................................................................................................... 62 10 Op-Code: Initiate Diagnostic Operation .................................................................................................. 63 14 Op-Code: Clear Diagnostic Information .................................................................................................. 64 20 Op-Code: Return to Normal Mode .......................................................................................................... 65 27 Op-Code: Perform Security - Mode 27 ................................................................................................... 66 28 Op-Code: Disable Normal Communications - Mode 28 ......................................................................... 69 29 Op-Code: Resume Normal Communications - Mode 29 (Obsolete Use Op-Code 20) .......................... 70 31 Op-Code: Start a Diagnostic Routine by Test Number ........................................................................... 71 34 Op-Code: Request the Control Module for Block Transfer - Mode 34.................................................... 72 1993-2011 General Motors Company, GM Customer Care & Aftersales. All Rights Reserved. Page 2
3B Op-Code: Write block of memory........................................................................................................... 74 3C Op-Code: Read and verify block of memory .......................................................................................... 81 3E Op-Code: Modify Block of Memory ........................................................................................................ 83 40 Op-Code: Read/Write Data Buffer .......................................................................................................... 85 52 Op-Code: Write Checksum to Block 82 / 8E .......................................................................................... 88 72 Op-Code: Set Programming Voltage ...................................................................................................... 90 84 Op-Code: Set Communications Parameters (Add Delay) ...................................................................... 91 A0 Op-Code: Request High Speed Communications - Mode A0 ................................................................ 92 A1 Op-Code: Begin High Speed Communications - Mode A1 .................................................................... 93 A8 Op-Code: GM Propriety Test Mode ........................................................................................................ 94 AE Op-Code: Request Device Control - Mode AE ...................................................................................... 95 B0 Op-Code: Block Transfer to RAM and Execute - Mode 36 .................................................................... 96 B2 Op-Code: Block Transfer to RAM and Save Two Byte Response - Mode 36 ........................................ 99 B3 Op-Code: Block Transfer to Download VIN as a Calibration - Mode 36 .............................................. 100 B4 Op-Code: Block Transfer to Download Calibration File - Mode 36 ...................................................... 102 Interpreter 2 KWP2000 Communications Programming Op-Codes ................................................................ 105 KWP2000 No Communications Processing .............................................................................................. 106 KWP2000 Response Processing .............................................................................................................. 107 01 Op-Code: Setup KWP2000 Programming (Target and Source Bytes) ................................................ 109 03 Op-Code: Set Number of Repetitions ................................................................................................... 110 10 Op-Code: SR 10 to Start Diagnostic Session ....................................................................................... 111 11 Op-Code: SR 11 ECU Reset ................................................................................................................ 113 14 Op-Code: SR 14 Clear Diagnostic Trouble Codes ............................................................................... 114 20 Op-Code: SR 20 to Stop Diagnostic Session ....................................................................................... 115 23 Op-Code: SR 23 to Read Memory by Address and Save Bytes........................................................... 116 27 Op-Code: SR 27 for Security Access Request ..................................................................................... 118 30 Op-Code: SR 30 to Input/Output Control by Local Identifier ................................................................. 120 31 Op-Code: SR 31 to Start Routine by Local Identifier ............................................................................ 121 32 Op-Code: SR 32 to Stop Routine by Local Identifier ............................................................................ 122 33 Op-Code: SR 33 to Request Routine Results by Local Identifier ......................................................... 123 34 Op-Code: SR 34 for Download Request............................................................................................... 124 37 Op-Code: SR 37 for Request Transfer Exit .......................................................................................... 126 38 Op-Code: SR 38 to Start Utility File Routine by Address ...................................................................... 127 39 Op-Code: SR 39 to Stop Utility File Routine by Address ...................................................................... 129 3A Op-Code: SR 3A to Request Routine Results by Address ................................................................... 131 3B Op-Code: SR 3B to Write Data by Local Identifier ............................................................................... 132 3D Op-Code: SR 3D to Write Memory by Address ................................................................................... 134 71 Op-Code: SR 31 to Start Routine by Local Identifier and Save 2 Bytes ............................................... 136 78 Op-Code: SR 38 to Start Utility File Routine by Address and Save 2 Bytes ......................................... 138 81 Op-Code: SR 81 to Start Communications ........................................................................................... 140 82 Op-Code: SR 82 to Stop Communications ........................................................................................... 141 83 Op-Code: SR 83 to Access Communications Parameters ................................................................... 142 84 Op-Code: SR 83 to Set Communications Parameters ......................................................................... 144 90 Op-Code: SR 36 to Transfer a Routine to ECU .................................................................................... 145 93 Op-Code: SR 36 to Transfer a Calibration File to ECU ........................................................................ 148 Interpreter 3 - GMLAN Communications Programming Op-Codes ................................................................. 152 GMLAN No Communications Processing .................................................................................................. 153 GMLAN Response Processing .................................................................................................................. 154 01 Op-Code: Setup Global Variables ........................................................................................................ 156 10 Op-Code: Mode 10 Initiate Diagnostic Operation ................................................................................. 157 14 Op-Code: Mode 04 Clear DTC's ........................................................................................................... 158 1A Op-Code: Mode 1A Read Data by Identifier ......................................................................................... 159 20 Op-Code: Mode 20 Return To Normal Mode ....................................................................................... 160 22 Op-Code: Mode 22 Read Data by Parameter Identifier (PID) .............................................................. 161 25 Op-Code: Mode AE Security Code ....................................................................................................... 162 27 Op-Code: Mode 27 Security Access ..................................................................................................... 163 34 Op-Code: Mode 34 Request Download ................................................................................................ 165 3B Op-Code: Mode 3B Write Data by Identifier ......................................................................................... 167 84 Op-Code: Set Communications Parameters ........................................................................................ 170 A2 Op-Code: Mode A2 Report Programmed State and Save Response .................................................. 171 AA Op-Code: Mode AA Read Data by Packet Identifier ............................................................................ 172 AE Op-Code: Mode AE Request Device Control ....................................................................................... 174
Page
B0 Op-Code: Mode 36 Block Transfer to RAM ......................................................................................... 175 Communications Independent Programming Op-Codes ................................................................................. 178 50 Op-Code: Compare Bytes .................................................................................................................... 179 51 Op-Code: Compare Checksum ............................................................................................................ 180 53 Op-Code: Compare Data ...................................................................................................................... 181 54 Op-Code: Change Data ........................................................................................................................ 183 55 Op-Code: Evaluate RPO (for use in vehicle assembly plants only) ...................................................... 185 56 Op-Code: Interpreter Identifier .............................................................................................................. 186 EE Op-Code: End with ERROR ................................................................................................................. 187 F1 Op-Code: Set Global Memory Address ................................................................................................ 188 F2 Op-Code: Set Global Memory Length .................................................................................................. 189 F3 Op-Code: Set Global Header Length ................................................................................................... 190 F4 Op-Code: Ignore Responses for Milliseconds ...................................................................................... 191 F5 Op-Code: Override the Utility File Message Length Value ................................................................... 192 F7 Op-Code: No Operation Op-Code ........................................................................................................ 193 F8 Op-Code: Goto Field continuation ........................................................................................................ 194 FB Op-Code: Set and Decrement Counter ................................................................................................ 195 FC Op-Code: Delay for ?? Seconds/Minutes ............................................................................................ 196 FD Op-Code: Reset counter ...................................................................................................................... 197 FF Op-Code: End with SUCCESS ............................................................................................................. 198 System Errors and Op-Code Failures .............................................................................................................. 199 Procedure for Adding New Op-Codes or Exceptions to Existing Op-Codes .................................................... 200 Appendixes....................................................................................................................................................... 201 Appendix A - UART Interpreter Examples ................................................................................................. 202 Appendix B - Class 2 Interpreter Examples ............................................................................................... 203 Appendix C - KWP2000 Interpreter Example ............................................................................................ 204 Appendix D GMLAN Utility File Guidelines ............................................................................................. 206 Revision History (Appendix D: GMLAN Utility File Guidelines) ..........................................................207 Assumptions ........................................................................................................................................208 Programming Flow ..............................................................................................................................209 Step $01 Set Target and Source Address .......................................................................................211 Step $02 Start Perform Seed and Key............................................................................................212 Step $03 SetUp Prepare to Download Flash Routine #1 from Utility File ......................................213 Step $04 Download Flash Routine #1 from Utility File .....................................................................214 Step $05 Request the Operating Software Part Number .................................................................215 Step $06 Evaluate the Application Software Part Number Value.....................................................216 Step $07 ProgOp Set the Global Header Length...........................................................................217 Step $08 Prepare to Download the Operating Software ..................................................................218 Step $09 Download the Operating Software ....................................................................................219 Step $0A ProgCal Set the Global Header Length..........................................................................220 Step $0B Prepare to Download the First Calibration Module ...........................................................221 Step $0C Download the First Calibration Module ............................................................................222 Step $0D Prepare to Download the Second Calibration Module .....................................................223 Step $0E Download the Second Calibration Module .......................................................................224 Step $0F ProgState Request the Programmed State....................................................................225 Step $10 Evaluate the Programmed State Value ............................................................................226 Step $11 Part 2 Write the VIN .......................................................................................................227 Step $12 Write the Tester Serial Number ........................................................................................228 Step $13 Write the Programming Date ............................................................................................229 Step $14 Retry1 Initialize Retry counter and decrement ...............................................................230 Step $15 Retry1 Delay .....................................................................................................................231 Step $16 Retry2 Initialize Retry counter and decrement ...............................................................232 Step $17 Retry2 Delay .....................................................................................................................233 Step $18 Retry3 Initialize Retry counter and decrement ...............................................................234 Step $19 Retry3 Delay .....................................................................................................................235 Step $1A Retry4 Initialize Retry counter and decrement ...............................................................236 Step $1B Retry4 Delay .....................................................................................................................237 Step $1C Success Exit Interpreter with Success...........................................................................238 Step $1D Error Exit Interpreter with Error ......................................................................................239 SPS Editor Output of Interpreter Instructions ......................................................................................240
Page
GMLAN Message Flow Diagrams .......................................................................................................241 Appendix E - Revision Log (Interpreters Document) ............................................................................... 244 Appendix F - Related Documents .............................................................................................................. 250 Appendix G $54 Op-Code Additional Information................................................................................... 251 Appendix H $55 Op-Code Additional Information - GATS Option String Processing ............................. 253
Page
Overview
This manual is designed for developers who will be writing the interpretive sections of the Utility Files and for the system programmers who will be writing the Interpreter software. The purpose of the manual is to explain the Interpreter concept as well as instruct a user exactly how to write interpreter instructions. This document will be updated regularly, so user input is a must for maximum benefit. The main input to the Interpreter Concept is the Utility File. Step by step instructions on how to reprogram a control module is provided by the Utility File. Utility Files were developed to keep the proliferation of tool reprogramming software to a minimum. The Utility file is viewed as three distinct sections: the Header Information (24 bytes), the Interpreter Instructions (size varies) and the device specific programming routines (a.k.a. Programming Algorithm (PA)). Even though the Utility file is viewed as three distinct parts, it will always be treated as a single entity necessary for reprogramming a Control Module.
The Interpreter Concept uses Interpreters that allow reprogramming support of new products, without having to hard code or create independent software packages. An Interpreter is a module that understands the format of Utility Files as well as the use of each of its Op-Codes. The Interpreter follows the Interpreter Instructions in the Utility files until an exit point is reached. There are two Op-Codes that will end the programming event: If the EE Op-Code (End with Error) is executed by the interpreter, Programming has Failed. If the FF Op-Code (End with SUCCESS) is executed by the interpreter, Programming was Successful. NOTE: Refer to Communications Independent Programming Op-Codes
Page
Utility File Structure

The Utility File is one contiguous block of data consisting of three distinct sections as depicted below:
Header Information (24 bytes)

Used to setup the programming session
The Header Information defines information that remains constant during the entire reprogramming event. An example of this information is the "Type of Interpreter", once the software starts using an Interpreter it will not change to an Interpreter using another communications protocol.
Interpreter Instructions
A set of sequentially numbered steps to control the programming session
The Interpreter Instructions are the Op-Codes that guide the terminal application through a reprogramming event. Each instruction line is 16 bytes long and consists of four sections: 1 byte Step Number, 1 byte Op-Code, 4 byte Action Field, and 10 bytes of goto fields.
Device (ECU) Specific Control Routines and / or Service Request Data Routine
The Device Specific Control Routines are programming routines used for performing various functions during the reprogramming event. The number of routines varies, depending on how each ECU. Examples of control routines are: erase flash memory, turn on reprogramming voltage, or read flash manufacturer and ID. Service Request Data Routines provide a means to pass additional data in Service Request. Examples of this data are Routine Entry Options and Record Values.
Even though the Utility File is viewed as three sections, it must be handled as a single file. The following subsections, Format of Header Information, Format of Interpreter Instructions and Format of Device Specific Programming Routines, provide greater insight to the design of the three sections of the Utility File. The routine section of the utility file is an optional section and is controller specific.
Page
Format of Header Information

The Utility Files will have the following header information starting at byte 00: 2 bytes $00-$01 2 bytes $02-$03 4 bytes $04-$07 2 bytes $08-$09 2 bytes $0A-$0B 2 bytes $0C-$0D Checksum of the Utility File Module ID of the Utility File Part Number of Utility File Utility File Design Level Suffix Type of Header/Utility Type of Interpreter Not used by interpreter, left here for commonality 0x0000 is the module ID for the Utility File Not used by interpreter, left here for commonality Not used by interpreter, left here for commonality 0x0000 for a standard single section file Header/Utility. 0xXXXX starting step number for the second section. 00 for UART communications. 01 for Class 2 communications. 02 for KW2000 communications 03 for GMLAN communications The length of the Header plus the Interpretive code (programming instructions) section. Required even without routine data to indicate end of interpreter instructions. 02 for two byte addressing or 03 for three byte addressing. 04 for four byte addressing - GMLAN CAN ONLY Data address information The number of data bytes to build into each data packet. This may be over written by Op-Code instructions
2 bytes $0E-$0F
Offset to routine section from byte $00
2 bytes $10-$11 4 bytes $12-$15 2 bytes $16-$17
Type of addressing (2,3 or 4 byte) Data address information Number of data bytes in a message
Example Header Information 790E00000000000000000000000100A80002000020000040 (ASCII Hex Format)

Check sum Module ID Part # Design Level Suffix Header/ Utility Type Interpreter Type Offset Type of Addressing Data Address # Of Data Bytes in Message
790E
0000
00000000
0000
0000
0001
00A8
0002
00002000
0040
Page
Format of Interpreter Instructions

Each line of interpreter instructions is 16 bytes long and defined as follows: Step ## Op-Code ## Action Fields ## ## ## ## Goto Fields ## ## ## ## ## ## ## ## ## ##
Any position not used in an instruction line must be filled with zero. All numbers in the interpreter instructions must be entered as hexadecimal values. (Note: All entries made to a utility file must be in caps) Step Field (1 byte - valid steps 01 - FF) The Step is a sequential number, increasing by one, indicating the order of the instruction file. The Step is used as a reference for goto field branching in the instructions. The first step number in the interpretive code must be 1 (0x01) and the last step cannot be greater than 255 (0xFF). An Interpreter error will occur if a step zero (0x00) is encountered. Op-Code Field (1 byte) Op-Codes are assigned values that identify what type of function/service the service tool should perform. Action Fields (4 bytes) The Action Fields are used as parameters or indicating exceptions. By setting appropriate exceptions in the Action fields, the behavior of the Op-Code can be modified. All unused Action Fields shall be set to 0x00. GOTO Fields (5 - 2 byte pairs) The Goto Fields are used to determine the next step. Goto fields are defined as pairs. For Op-Codes that send a message to a control module based on the responses returned from the control module, the first byte is the response byte and the second byte is the interpreter step that is executed next. Comparison of the Goto Field pairs is done from left to right and will stop when the first matching code is found. The Goto Field pair is read as follows: On response return code ?? - Then_- Goto step ?? Two specific numbers FD and FF are defined to handle response codes / events. In case of a no communications fault event the FD code will determine the next step. The FF code is read as "ANY". If there is a response code or event return code that is not listed in the Goto Field pairs, then the FF Goto Field code will determine the next step. For Op-Codes which send a message to a control module, the FF code must be in the last Goto Field pair to handle all possible response codes / events.
NOTE:
In the case of negative response processing, it is possible to receive a negative response code that is equal to the expected service identification response for a positive response message. To resolve this issue, it is necessary to put a duplicate response code in the goto fields: the first goto response will be for positive response messages and the second will handle the negative response messages. For a more detailed description, see the Response processing section of this document. The response return codes are the control module responses to a transmitted message. Not all Op-Codes send a message to a control module, some perform other functions (i.e. Op-Code 50 and 51). The first byte of the goto pair should be zero for Op-Codes not requiring a response from the module. If more than five Goto Fields are needed for an interpreter instruction, do not close the step with an 'FF'. If the tool does not see an 'FF' return code and a return code has not been found, the tool continues searching for a return code in the Goto Fields of the next step in the interpreter instructions. The 'F8' OpCode must be used on the goto continuation line (for more information see 'F8' Op-Code description).
Page
Device (ECU) Specific Control Routines and/or Service Request Data Routines
The Device (ECU) Specific Control Routines are pieces of code that are transferred to an ECU. The suppliers or the Flash vendors develop the control routines. Examples of Control Routines are: erase flash memory, checksum memory, or reset ECU. The user has the option to include Control Routines in the Utility File or to embed the routines in the ECU's memory. This entire section of the Utility File is optional. If this section is omitted all required Control Routines shall be embedded in the ECU's memory and therefore no user optional data shall be needed for any Service Requests. If this section is in the Utility File, it shall be formatted as follows: The routines in the Utility File must be laid out as follows: 4 bytes 2 byte X bytes 4 bytes 2 byte Y bytes : 4 bytes 2 byte Z bytes Address information Length of the routine 1 (not including address and length) Routine 1 data Address information Length of the routine 2 (not including address and length) Routine 2 data : Address information Length of the routine N (not including address and length) Routine N data.
The routines are one contiguous block of data. They are separated only for presentation purposes. The address can be used by the tool as a destination address (Note: The address information could also come from the global address or the header address or might be not used at all.). The length is used to locate the routines in the routine(s) portion of the Utility File. The length of a routine is the total number of data bytes not including the 2 byte length and the 4 byte address. The first routine in the routine section will be referenced as routine number 1. The routine numbers are not included in the routines section of the Utility File. However, the routine number will be used in the Op-Code to call the routine. The tool will internally keep track of the routine numbers. If an Op-Code calls for routine 3, the tool will skip over the first two routines and return the data in the third routine. The tool will determine where each routine is located by using the routine lengths that precede each routine located in the routines section of the Utility File.
Page
10
Reprogramming Algorithm Overview

The Reprogramming Algorithm is not required to be part of the Utility File. An application may store its Reprogramming Algorithm within the controller software instead of downloading them into RAM from the Utility File (routine section). Applications using Flash devices that do not store the Reprogramming Algorithm in the Utility File may copy their Flash I/O routines from controller software to RAM prior to reprogramming. This is necessary because it is not possible to execute from one Flash segment while trying to erase or write to another in the same Flash device. Using the Utility File to download the Reprogramming Algorithm offers a way to keep the reprogramming capability out of the controller software. This eliminates the danger of being able to write and erase controller software while executing normal operation controller software. The Reprogramming Algorithm is downloaded to the controller by the reprogramming tool per the Programming Instructions. The Reprogramming Algorithm is executed by the controller and should reside in Keep-Alive Memory if available. The Reprogramming Algorithm portion of the Utility File is flash device and hardware dependent. There is no distinction between subroutines that are hardware dependent and those that are flash device dependent. If additional suppliers exist for a reprogrammable controller or components of a controller, the Utility File must include all the necessary Reprogramming Algorithms for all suppliers of the controller and/or components. It is typically preferred to keep the size of the Reprogramming Algorithm as small as possible when the Reprogramming Algorithm is part of the Utility File. This may be necessary due to a lack of RAM available for reprogramming or Flash reprogramming event time limitations. Reprogramming requires the use of RAM that does not conflict with locations used in the normal operation download itself to execute the Reprogramming Algorithm and to buffer the new software and/or calibrations that will be reprogrammed. The ideal situation is to have a contiguous RAM region for each purpose, which takes advantage of the maximum downloaded message size. The Reprogramming Algorithm should be as efficient and fast as possible because of time constraints (i.e. an assembly plant reprogramming environment). The Reprogramming Algorithm typically consists of the following 5 basic functions: 1. Executive Routine The communications executive logic coordinates the reprogramming event. It has knowledge of the size of the data and addresses to be reprogrammed. It coordinates error handling of the Flash and Communications I/O routines and determines when the reprogramming event is complete. 2. Communications I/O Routines The Communications I/O Routines consist of the minimum amount of I/O support that is required for reprogramming. This piece is typically a subset of the normal operation Communication I/O routines. When designing the Communication I/O routines, it is possible to make assumptions on what part of the Communications I/O software must be supported since the Programming Instructions will be written in conjunction with the Reprogramming Algorithm. 3. Reprogrammable Device I/O Erase/Write Routines The Reprogrammable Device I/O Erase and Write Routines allow access to the reprogrammable device and include functions such as turning programming voltage on and off, erasing, writing, and checking the erase status of the memory. Error checking of these functions is performed to inform the Executive Routine whether or not to continue Reprogramming. 4. Checksum Verify Routine Checksums are typically calculated to verify that each block was transferred into RAM properly. At the end of reprogramming a section, the memory that has been written to is typically check summed to ensure that it was written successfully. 5. Exit Routine The Exit Routine ensures RAM is left in the erased state that is acceptable to the operational softwares initialization logic. The communications hardware may need to be reconfigured to normal operation conditions. At the end, a power up reset is typically invoked to put the Controller back into its normal operational state.
Page
11
Additional Utility File Information - Best Practices and recommendations

All Communication Protocols: 1. There shall be no additional steps between the interpreter instructions and the beginning of the routine section (routine #1). 2. The only protocol that supports two part utility files is GMLAN CAN. All other protocols shall have the utility file header bytes $0A-$0B set to $0000. 3. To calculate the offset to the routine section, first multiply the number of interpreter instructions by 16 (number of data bytes in an interpreter instruction) and then add 24 (number of data bytes in the utility file header). All values should be calculated as decimal values and the sum should be converted to hexadecimal and placed into bytes $0E-$0F of the utility file header. If the SPS Editor program is used to create the utility file, the program will calculate the offset. 4. Any interpreter instruction that sends a message on the vehicle communication bus shall implement the FD (no communications fault) and FF (unexpected response) return codes in the Goto section of the interpreter instruction. S1130000071AC10100005A08FD09FF1B00000000FF 5. Each interpreter instruction that uses Op-Code 27 (security access) shall use the same security algorithm value for a given device ID. 6. Op-Code FC (Delay) has a setting for seconds or minutes (AC3). Care should be taken to ensure that the setting is set to seconds for most programming events. The minutes feature is primarily used for vehicle theft deterrent re-learns. 7. It is recommended that re-try logic be built into the utility file using a combination of the FC (delay) and FB (set and decrement counter) Op-Codes. S113000003FC0200000000040000000000000000FF S113000004FB010600000002001B000000000000FF 8. When using the FB (set and decrement counter) Op-Code, the value of the Loop limit (AC1) must be > 1 as the counter value is decremented prior to processing the Goto instructions. S113000012FB0103000000010010000000000000FF 9. Care should be taken to reference Op-Code information by communication protocol as many of the OpCodes are used in multiple protocols and the action field requirements vary by protocol. 10. If an interpreter instruction is removed from a utility file, the offset to the routine and the Goto fields must be updated to reflect this modification. 11. No extra bytes after the last routine sections allowed.
UART Protocol: TBD Class 2 Protocol: 1. Op-Code 29 (mode $29) is obsolete and should be replaced with Op-Code 20 (mode $20) in any new utility files. Op-Code $29 is supported for legacy issues only. 2. For part number comparisons using Op-Code 3B (mode $3B) other than the VIN, the first goto field shall indicate a matching part number, the second goto field will provide the path to follow when the part numbers differ. Keyword 2000 Protocol: 1. There shall be a delay after ECU Reset and a start/stop communication to assure that the controller is still OK after Reset 2. Seed &Key: Error code 37 is handled internally (external loop not necessary) 3. Op-Code FC Delay for Seconds/Minutes KWP 2000 requires AC1=01 to send Tester Present (AC1=00 Default Tester Present is only for UART and GMLAN)
Page
12
(continued) GMLAN CAN Protocol: 1. All GMLAN CAN Utility files shall have Op-Code 01 as the first interpreter instruction. 2. All SPS_TYPE_A and SPS_TYPE_B ECU's shall support mode $1A DID $B0 (ECU diagnostic address). See GMW3110 specification. 3. All SPS_TYPE_C ECUs shall enable and support two special case CANIds as defined in GMW3110 chapter 11. 4. Items 1,2 and 3 allow the programming code to map the utility file device ID to the ECU request and response CANIds. 5. Any interpreter instruction which needs to sent after a ECU reset shall be implemented in part two of the utility file. The utility file header bytes $0A-$0B shall be set to the interpreter instruction number for the beginning of part two. A FF Op-Code is required before the beginning of part two of the utility file. 6. Only the GMLAN CAN protocol supports 4 byte addressing. 7. GMLAN CAN utilizes pre utility (programming setup) and post utility (programming conclusion) file processes as documented in GMW3110. Pre Utility file process example for HS GMLAN CAN: <04 00 00 01 01 00 00 00 00 FE 3E <04 00 00 01 01 00 00 00 00 FE 1A B0 >04 00 00 00 00 00 00 07 E8 00 5A B0 11 <04 00 00 01 01 00 00 00 00 FE 10 02 >04 00 00 00 00 00 00 07 E8 00 50 <04 00 00 01 01 00 00 00 00 FE 28 >04 00 00 00 00 00 00 07 E8 00 68 <04 00 00 01 01 00 00 00 00 FE A2 >04 00 00 00 00 00 00 07 E8 00 E2 00 <04 00 00 01 01 00 00 00 00 FE A5 01 >04 00 00 00 00 00 00 07 E8 00 E5 <04 00 00 01 01 00 00 00 00 FE A5 03
Post Utility file process example for HS GMLAN CAN: <04 00 00 01 01 00 00 00 00 FE 20 >04 00 00 00 00 00 00 06 44 00 60 <04 00 00 01 01 00 00 00 00 FE 1A B0 >04 00 00 00 00 00 00 07 E8 00 5A B0 11 Certain Op-Codes commonly used in Class 2 are not defined for GMLAN CAN as they are part of the pre and post utility file processes and run automatically. 8. GMLAN CAN supports Op-Code 53 Compare Data functions. In combination with Op-Code 1A, OpCode 53 can be used to read the operational software part number and program operational software and calibrations or program only calibrations. S1130000071AC10100005A08FD09FF1B00000000FF S1130000085301010000000A000B000000000000FF 9. For Single Wire GMLAN CAN, the pre utility file process as defined in GMW3110 handles the high voltage wake up message. 10. If the VIN, Repair Shop Code, Programming Date or End Model Part Number are written to the ECU, it is recommended that this be done in part two of the utility file after programming and ECU reset. Repair shop code and Programming Date should be stored in flash memory.
Page
13
(continued)
11. The utility file needs to comprehend how the ECU reacts to a request for a part number if the part is not fully programmed. For example, some ECUs when running out of boot will go to a fixed memory location and report out the contents of those memory locations as the part number. If the data file had been previously successfully programmed the reported data is correct. If programming was interrupted you may get bogus data (e.g. FF FF FF FF) or you may get a valid part number even though the complete data file had not been programmed. This can occur if the boot code retrieves the part number from the memory where the GMLAN header is written and programming had been interrupted after the header data was written to flash. There are several ways to get around this. One would be to have the boot check the validity of that particular data file and reject the part number request with reject code $31 if the data file was not fully programmed. The utility file could then be setup to jump to the appropriate line to reprogram the partially programmed data component. A second method to get around this is to use a combination of $A2 and $50 Op-Codes. The $A2 Op-Code will retrieve the programmed state of the ECU and dump it into one of the utility file buffers. The $50 Op-Code can then be used to verify that software is programmed before proceeding to the Op-Codes to check the software part numbers. If the software were not programmed then the utility file would jump directly to program op-software. If software is programmed then check the part numbers to see if the software needs to be updated (see above use of the $1A and $53 Op-Codes). If the software part numbers match then the utility file can jump to just program the calibration section. Note also that the use of the $50 Op-Code needs to comprehend whether or not the ECU supports any of the memory failure responses ($5x) that the ECU may send when checking to see if software is present. 12. The utility files should be designed to compare part numbers of software components to determine if software and calibrations are to be programmed or just calibrations (see above descriptions on use of Op-Code $1A and Op-Code $53). It is not necessary (or desirable) to check individual calibration file part numbers in the utility file unless the ECU supports reprogramming of subsets of the calibration data files. If all calibration data files must be programmed as part of the same programming event it is not necessary to compare these part numbers. 13. The module Id field in the $B0 Op-Code must match the module Id field in the drawing file for the data part as well as the module Id field in the WWAPI wrapper. 14. The utility file should include an $A2 Op-Code after programming all data files. Success of the programming event would then be determined based on an $A2 response of $00 (fully programmed). Putting the $A2 Op-Code at the end ensures that a data size mismatch of the last programmed data file cannot result in a passed programming event and a non-functioning ECU. 15. The conclusion of part 1 and part 2 of the utility file are both signified by encountering either the end with success ($FF) Op-Code or end with error ($EE) Op-Code. There only needs to be one end with success and one end with error Op-Code. Both parts can conclude by jumping to the same end with success or end with error Op-Code. 16. It is not necessary to put Op-Code $01 in part 2 of the utility file. The value used in part 1 of the utility file will also be used in part 2.
Page
14
Programming Storage Buffers Recommended Usage

1. There are currently twenty 2-byte storage buffers and twenty 256-byte storage buffers available for use during a programming event. When referenced within an OpCode, the buffer number is entered in HEX (0x00 0x13). 2. The 2-byte buffers were originally designed for use with 2 byte checksums. In most cases, two bytes of data should be stored into the 2-byte buffers for proper operation. OpCode $50 is the corresponding compare data OpCode for 2-byte buffers. 3. The 256-byte buffers were designed to store data (ex. OpCode $1A), compare data (ex. OpCode $53), change data (ex. OpCode $54) or write data (ex. OpCode $3B). OpCode examples are GMLAN. These buffers can hold 1-256 bytes of data. 4. The Programming Buffers are automatically initialized to all 00's (cleared) at the beginning of every programming event. 5. The Programming Buffers are not cleared between part 1 and part 2 of a GMLAN programming event.
Page
15
Interpreter 0 - UART Communications Programming Op-Codes
Page
16
UART Support for No Communication Faults

Supported By: UART Interpreter 0 Description: Normal processing of a request message is to re-send the request up to three times if the transmission of a request fails. However, if the transmission is successful and no controllers respond to the request, then the request will fail with a no communications fault. The goto fields in the interpreter can be used to force the tool to execute another step rather than re-sending the same ALDL message. This is accomplished by putting a FD in one of the first bytes of a goto field (G0, G2, G4, G6, or G8). The no communications screen will still be displayed but after verification the tool will goto the step specified by the FD rather than re-send the same ALDL message. The option also exists to have the tool ignore any no communication faults. If this is necessary, it needs to be explained in the devices reprogramming specification because this processing is handled internal to the tool software. Typical Interpreter Line: Step XX Pseudo Code: Op-Code OP Action Fields 01 03 F4 00 Goto Fields AA 09 FD 12 FF 4A 00 00 00 00
XX OP AC0 AC1 AC2 AC3
G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
If the Op-Code (OP) Ignores No Communication Faults Continue reprogramming process Else Display the no communication screen Verification is received Check the goto fields for a FD return code (G0, G2, G4, G6, or G8) If a FD Return Code is Found Flag appropriate step to execute next and return Else Do While No Response Send the ALDL message again If This Is the Third Failure End reprogramming process as a no comm fault Endif this is the third failure End do while no response Endif an FD return code is found Endif the Op-Code (OP) ignores no communication faults
Page
17
UART Return Type Processing

Supported By: UART Interpreter 0 Description: Several of the mode 6 and 16 Op-Codes set Return Type Processing and Return Code Position. These pieces of information that allow the tool to decipher the varying responses received from the target address. Return type processing and return code position are tied to a single exception Op-Code logic. The exceptions, when used, are documented with the Op-Codes (i.e. C0 Op-Code). Return Type Processing and Return Code Position are not directly modifiable unless the desired combination already exists for an Op-Code. If the combination does not exist, a new exception will need to be created for the appropriate Op-Code. Return Code Position - Tells the tool what byte of the response will contain the actual return code. The return code is the value expected in the goto fields to determine the next step to execute. Return Type Processing - This is used to handle the different formats of responses that result when using OpCodes. For example, the CO Op-Code could return an AA or 06 response depending on the type of module being reprogrammed. Pseudo Code: XX OP AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Do Return Type Processing Zero Check response byte 4 for return codes (set return code position to 3) Expect an AA return code for SUCCESS Enddo return type processing zero Do Return Type Processing One Ignore the response and return Enddo return type processing one Do Return Type Processing Two If Response Byte 3 is the Message Mode If Response Byte 4 is a 15 Check return code in response byte 5 (anything but 06 is a FAILURE) Else Mode number in response byte 3 is SUCCESS Endif response byte 4 is a 15 Else No response received from device Endif response 3 is the message mode Enddo return type processing is two Do Return Type Processing Three If Response Byte 4 is Equal to Block Number (AC1) return SUCCESS Else return FAILURE Endif response byte 4 is equal to Block Number (AC1) Enddo return type processing is three Do Return Type Processing Five (developed for EEPROM applications) Check response byte 3 for response If Response Byte 3 is Mode Number Return SUCCESS Endif response byte 3 is mode number Enddo return type processing five
Page
18
00 Op-Code: Enable Normal Communications

Supported By: UART Interpreter 0 Description: The 00 Op-Code will build a standard mode 0 message to send to a device. A mode 0 command will restart devices transmitting which may have been previously inhibited by a mode 8 command. Action Fields: AC0: AC1: AC2: AC3: G0: Device ID 00 - Not Used 00 - Not Used 00 - Not Used 00 - Don't care
Pseudo Code: XX 00 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Use UART Return Type Processing of One. Build Mode 0 message as below Request Byte 1 2 3 4 Value AC0 01 00 CS Byte Description Device ID Message length Message mode Message checksum
Send Mode 0 message Goto step specified in goto field 1 (G1) Typical Interpreter Line: Step 01 Op-Code 00 Action Fields F4 00 00 00 Goto Fields FF 99 00 00 00 00
00 02
00 00
Page
19
01 Op-Code: Request message from the device

Supported By: UART Interpreter 0 Description: The 01 Op-Code will build a standard mode 1 message to request a data list from a device. Devices may have different data list contents, so check device specifications to determine which data lists to request. Requested data list numbers and exceptions will be used by the tool to process the information returned from the devices. Note: The first byte of the Goto Fields is always set to 0x00 because it is not used (don't care). Action Fields: AC0: AC1: AC2: AC3: G0: Device ID Message number requested 00 - Not Used 00 - Do not wait for an F0 poll before sending mode 1 request 01 - Wait for an F0 poll before sending mode 1 request 00 - Don't care
Use UART Return Type Processing of One Build Mode 1 message as indicated in the table below: Request Byte 1 2 3 4 5 Value AC0 02 01 AC1 CS Byte Description Device ID Message length Message mode Message number requested Message checksum
If the Exception Is One (AC3=01) Wait for an F0 poll before sending message Endif the exception is one Send Mode 1 message Goto UART Return Type Processing Goto step specified in goto field 1 (G1) (this Op-Code ignores no communication fault) Typical Interpreter Line: Step 1F Op-Code 01 Action Fields F4 03 00 00 Goto Fields FF 99 00 00 00 00
00 20
00 00
Page
20
02 Op-Code: Request memory dump from the device using Mode 2 (Saturn EEPROM)
Supported By: UART Interpreter 0 Description: The 02 Op-Code will build a standard mode 2 message to request a 64 byte memory dump from a device. Messages can consist of a single or multiple mode 2s, depending on the action fields. The calculated value is then compared against a previously stored value. In order to work correctly, a D4 Op=Code may need to be run prior to this one in order to create a valid value to compare against. Warning: In order for this code to work correctly, a D4 Op-Code may need to be run first. This will place a valid checksum or CAL ID in global storage against which we will perform a comparison. (Note: This is not necessary if AC3 = 02). Action Fields: AC0: AC1: AC2: AC3: Device ID High byte of address (needed only if AC3 = 02 or 04) Low byte of address (needed only if AC3 = 02 or 04) Exceptions. See pseudo code below 00 = multiple block read and checksum calculation. Compare against stored checksum. 01 = Read block and compare first two bytes to global checksum field 02 = Read block and exit No comparisons 03 = Read block and compare to global CAL ID 04 = Read block and compare ABS controller transmission option byte. 00 - Don't care
G0:
Use UART Return Type Processing Five Build Mode 2 message as indicated in the table below Request Byte 1 2 3 4 5 6 Value AC0 03 02 AC1 AC2 CS Byte Description Device ID Message length Message mode High byte of address to read from Low byte of address to read from Message checksum
If the Exception is One or Three (AC3=01, AC3=03 or AC3 = 04) Send Mode 2 and receive response (64 data Bytes) Compare extracted value to stored value Endif the exception is one or three If the Exception is Two (AC3=02) Send Mode 2 and receive response (64 data Bytes) Compare extracted value to stored value End the exception is two If the Exception is Zero (AC3=0) While entire calibration has not yet been read from controller Send Mode 2 with address of next block Receive response Perform summation algorithm on new data block
Page
21
(continued) End while Compare calculated checksum to stored checksum End the exception is zero Goto UART Response Processing Goto step specified in goto field 1 (G1) Typical Interpreter Line: Step 1F Op-Code 02 Action Fields F4 10 F7 00 Goto Fields FF 99 00 00 00 00
00 20
00 00
Page
22
03 Op-Code: Verify programming of a EEPROM device (NAO EEPROM)

Supported By: UART Interpreter 0 Description: The 03 Op-Code will build a standard null mode 3 message to verify the programming of a device. On EEPROM applications, sending a mode 3 with no address (the entire message consists of only the mode number). As part of the functionality of the EEPROM controller, a response (which consists of only the mode number) to this message indicates that the programming process was successful. No response indicates that a problem occurred during reprogramming. Note: A mode 3 combined with the proper address will return the prom id of the current calibration. The prom id is the last four digits of the calibration part number. The id is accessed and used by the reprogramming software to select the proper calibration archive file prior to utilization of the utility file and interpreter. Action Fields: AC0: AC1: AC2: AC3: G0: Device ID 00 - Send null mode 3 message 00 - Not Used 00 - Not Used 00 - Return code (mode number)
Use UART Return Type Processing of Five Build Null Mode 3 message as indicated in the table below: Request Byte 1 2 3 4 Value AC0 01 03 00 Byte Description Device ID Message length Mode number Placeholder for checksum
Send Mode 3 and check for response Goto UART Return Type Processing If Response Byte 3 is Message Mode Indicate success Else If No Response Fail and indicate error Endif response byte 3 is message mode Goto step specified in goto field 1 (G1) Typical Interpreter Line: Step 0A Op-Code 03 Action Fields F4 00 00 00 Goto Fields 03 02 FD 99 FF 99 00 00 00 00
Page
23
04 Op-Code: Device control - Mode 4

Supported By: UART Interpreter 0 Description: The 04 Op-Code sends an ALDL mode 4 command that sets a bit Action Fields: AC0: AC1: AC2: AC3: Device ID 00 - Not Used 00 - Not Used 00 - Not Used
Use UART Return Type Processing of One Build Mode 4 message as indicated in the table below Request Byte 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Value AC0 0D 04 00 00 00 00 01 00 00 00 00 00 00 00 CS Byte Description Device ID Message length Message mode First data byte Second data byte Third data byte Fourth data byte Fifth data byte Sixth data byte Seventh data byte Eighth data byte Ninth data byte Tenth data byte Eleventh data byte Twelfth data byte Message checksum
Send Mode 4 message and receive response Goto UART Return Type Processing Build a Mode 5 message as exactly as indicated below (the interpreter builds and sends this message as part of the 04 Op-Code. A separate 05 Op-Code does not necessarily need to follow the 04 Op-Code): Request Byte 1 2 3 4 Value AC0 01 05 CS Byte Description Device ID Message length Message mode Message checksum
Use UART Return Type Processing of Zero Wait for an F0 poll (equivalent of the option AC1=01 shown in the description of 05 Op-Code)
Page
24
(continued) Send the Mode 5 message and receive response Goto UART Response Processing Look for response byte 4 in Goto fields If Response Byte 4 is Found in Goto Fields Goto appropriate step Else Goto step indicated by FF goto field Endif response byte 4 is found in goto field Typical Interpreter Line: Step Op-Code 1F 04
Action Fields F4 00 00 00
04 20
Goto Fields FF 99 00 00 00 00
00 00
Page
25
05 Op-Code: Ram download request - Mode 5

Supported By: UART Interpreter 0 Description: The 05 Op-Code will build a standard mode 5 message to send to a device. A mode 5 command will prepare the device to receive executable code from the serial data link. Mode 5 messages are used in conjunction with modes 6 & 16 to download information to devices. The mode 5 command should expect an AA response for success. Action Fields: AC0: AC1: Device ID 00 No wait 01 Wait for an F0 poll before sending mode 5 request 02 Wait for an F0 poll before sending mode 5 message (don't display poll No Comm. failures) 00 - Not Used 00 - Not Used
AC2: AC3:
Use UART Return Type Processing of Zero Build Mode 5 message as below: Request Byte 1 2 3 4 Value AC0 01 05 CS Byte Description Device ID Message length Message mode Message checksum
If Exception is One or Two (AC1=01 or AC1=02) Wait for an F0 poll Endif exception is one or two If Exception is Two (AC1=02) Ignore no communications faults Endif exception is two Send Mode 5 message and receive response Goto UART Return Type Processing Look for response byte 4 in Goto fields If Response Byte 4 (AA) is Found in Goto Fields Goto appropriate step Else Goto step indicated by FF goto field Endif response byte 4 is found in goto field Typical Interpreter Line: Step 10 Op-Code 05 Action Fields F4 01 00 00 Goto Fields 05 0D FF 99 00 00
AA 11
00 00
Page
26
08 Op-Code: Disable Normal Communications

Supported By: UART Interpreter 0 Description: The 08 Op-Code will build a standard mode 8 message to send to a device. A mode 8 command will inhibit devices from transmitting data on the serial data link. Communications will remain inhibited while any ALDL activity exists on the link or the link is inactive for more than five seconds. Action Fields: AC0: AC1: AC2: AC3: Device ID 00 - Not Used 00 - Not Used 00 - Do not wait for an F0 poll before sending mode 8 message Wait for a response from the mode 8 01 - Wait for an F0 poll before sending mode 8 message Wait for a response from the mode 8 02 - Do not wait for an F0 poll before sending mode 8 message Do not wait for a response from the mode 8 03 - Wait for an F0 poll before sending mode 8 message Do not wait for a response from the mode 8 00 - Don't care 08 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
G0: XX
Pseudo Code: UART Return Type Processing is based on exception. Build Mode 8 message as below Request Byte 1 2 3 4 Value AC0 01 08 CS Byte Description Device ID Message length Message mode Message checksum
If the Exception is One or Three (AC3=01 or AC3=03) If the Device ID is F1 Wait for an F0 poll with Tech 2 as Master (For Electric Vehicle) Else Wait for an F0 poll with Tech 2 as Slave (Normal F0 processing) Endif the device ID is F1 Else Do not wait for an F0 poll Endif the exception is one or three Send Mode 8 message If the Exception is Zero or One (AC3=00 or AC3=01) Wait for a response Verify correct response Else Do not wait for a response (ignore) Endif the exception is zero or one Goto step specified in the goto fields Typical Interpreter Line: Step 01 Op-Code 08 Action Fields F4 00 00 00 Goto Fields FF 99 00 00 00 00
00 02
00 00
Page
27
09 Op-Code: Enable Normal Communications

Supported By: UART Interpreter 0 Description: The 09 Op-Code is used to resume normal communications after a 08 (Mode 8) message. The Op-Code will build a Mode 9 message. Action Fields: AC0: AC1: AC2: AC3: G0: Device ID 00 - Not Used 00 - Not Used 00 - Not Used 00 - Don't care
Pseudo Code: XX 09 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Use UART Return Type Processing of One. Build Mode 9 message as below Request Byte 1 2 3 4 Value AC0 01 09 CS Byte Description Device ID Message length Message mode Message checksum
Send Mode 9 message and receive response. Goto UART Return Type Processing (Op-Code ignores no communications faults). Goto step specified in goto field 1 (G1) Typical Interpreter Line: Step 01 Op-Code 09 Action Fields F4 00 00 00 Goto Fields FF 99 00 00 00 00
00 02
00 00
Page
28
0A Op-Code: Clear Trouble Codes - Mode 10

Supported By: UART Interpreter 0 Description: The 0A Op-Code will build both a standard mode 8 and standard mode 10 message to send to a device. A mode 10 command will clear diagnostic trouble codes for a given device. Action Fields: AC0: AC1: AC2: AC3: G0: Device ID 00 - Not Used 00 - Not Used 00 - Not Used 00 - Don't care
Pseudo Code: XX 0A AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Use UART Return Type Processing of One (ignore). Build Mode 8 message as below Request Byte 1 2 3 4 Value F4 01 08 CS Byte Description Device ID Message length Message mode Message checksum
Send the Mode 8 response to break normal communications. Ignore the response. Build Mode 10 message as below Request Byte 1 2 3 4 Value AC0 01 0A CS Byte Description Device ID Message length Message mode Message checksum
Send Mode 10 message and ignore the response. Goto step specified in goto field 1 (G1) Typical Interpreter Line: Step 01 Op-Code 0A Action Fields F4 00 00 00 Goto Fields FF 99 00 00 00 00
00 02
00 00
Page
29
0C Op-Code: Program EEPROM - Mode 12

Supported By: UART Interpreter 0 Description: The 0C Op-Code is used to download data to EEPROM using standard mode 12 ALDL communications. The data that is downloaded is determined by the information contained in the Action Fields. The 0C Op-Code will use return type processing 3 as defined under the Return Code Position and Return Type Processing section of this document. Action Fields: AC0: AC1: AC2: Device ID Block Number being downloaded if AC2 is not $10, Number of Routine being downloaded if AC2 is $10 Data to include in the message $00 - Send VIN (17 bytes) $01 - Send End Model Part Number (4 bytes) $02 - Reset Manufacturers Enable Counter $03 - Write a new key code to the CCU or PCM of the EV1 Electric Vehicle $04 - Write the state of charge information to the EV1 Electric Vehicle PCM $10 - Write Routine including block number as first byte. AC1 contains Routine Number 00 - Do not wait for an F0 poll before sending mode 12 message 01 - Wait for an F0 poll before sending mode 12 message 0C AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
AC3:
Pseudo Code: XX Use UART Return Type Processing of Three Build Mode 12 message as below Request Byte 1 2 3 4 5 5+N 6+N Value AC0 N+2 0C AC1* XX Byte Description Device ID Message length Message mode Block number Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N Message checksum
XX CS
* Use first routine byte if AC2 is $10 If the Exception is Zero (AC2 is 00) Copy the VIN into the data area of the message starting at data byte 1 ElseIf the Exception is One (AC2 is 01) Copy the End Model part number into the data area of the message starting at data byte 1 ElseIf the Exception is Two (AC2 is 02) Reset the manufacturers enable counter to zero ElseIf the Exception is Three (AC2 is 03) (Used for Electric Vehicle) If AC0 is 0xF4 Write key code to the PCM (Electric Vehicle) Else Write key code to the CCU (Electric Vehicle) ElseIf the Exception is Four (AC2 is 04) (Used for Electric Vehicle) While state of charge data remains Create new mode 12 command with appropriate block number Send the new mode 12 and receive response Endwhile
Page
30
(continued) ElseIf the Exception is Ten Hex or Sixteen Decimal (AC2 is $10) Copy Routine specified by AC1 into message. The first byte is used as block number (Request Byte 4) and all following bytes as data (Request Byte 5 and following) Endif exception processing If AC3 is 01 Wait for an F0 poll before sending message Endif AC3 is 01 If AC2 is Not Equal to Four Send 12 message and receive response Endif AC2 is not equal to four Look for response byte 4 in Goto fields (Block Number) If Matching Block Number is Found Goto appropriate step Else Goto step indicated by FF goto field Endif matching block number is found Typical Interpreter Line: Step 21 Op-Code 0C Action Fields F4 01 00 00 Goto Fields FF 99 00 00 00 00
01 22
00 00
Page
31
0D Op-Code: Perform Security - Mode 13

Supported By: UART Interpreter 0 Description: The 0D Op-Code is used to open a control module's memory for reprogramming. The tool uses Action Field zero (AC0) to determine which security algorithm is used. Action Fields: AC0: AC1: AC2: AC3: Security Algorithm Number (Default security algorithm is 00) Device ID 00 - Not Used 00 - Not Used
Pseudo Code: XX 0D AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Use UART Return Type Processing of Zero Build mode 13 security seed request as indicated in the table below Request Value Byte Description Byte 1 AC1 Device ID 2 02 Message Length 3 0D Message mode 4 01 Request number 5 CS Message checksum Send mode 13 seed request and receive response Goto UART Return Type Processing If Both Bytes of the Seed (response bytes 5 & 6) are Zeros Set security response byte 5 to success (AA) Indicate successful response Else Use specified security algorithm to determine device's key Build mode 13 security key response as indicated in the table below Request Value Byte Description Byte 1 AC1 Device ID 2 04 Message Length 3 0D Message mode 4 02 Request number 5 XX High byte of key 6 XX Low byte of key 9 CS Message checksum Send Mode 13 key response and receive response Goto UART Return Type Processing Endif both bytes of the seed (response bytes 5 & 6) are zeros Look for mode 13 key response byte 5 in goto fields If Mode 13 Key Response Byte 5 is Found Goto appropriate step Else Goto step indicated by FF goto field Endif Mode 13 Key Response Byte 5 is Found Typical Interpreter Line: Step 01 Op-Code 0D Action Fields 00 F4 00 00 Goto Fields 27 22 FF 55 00 00
AA 02
00 00 Page 32
20 Op-Code: Receive a normal mode message from device

Supported By: UART Interpreter 0 Description: The 20 Op-Code will eavesdrop on a normal mode conversation and return the first message it finds with the given device ID. This is used to read the current odometer value stored in the Electric Vehicle IPC. Action Fields: AC0: AC1: AC2: AC3: G0: Device ID 00 Not used 00 Store read odometer value for later comparisons. 01 Compare value read against odometer value to be written. If old value is <= new value, test passes. 02 Compare value read against odometer value written. If old value == new value, test passes. 00 Not used 00 Dont Care
Use UART Return Type Processing of Five Build Mode 1 message as indicated in the table below Request Byte 1 2 3 4 Value AC0 01 20 CS Byte Description Device ID Message length Message mode Message checksum
Send message and receive response (up to 256 Bytes) Goto UART Response Processing If the Exception is One or Two (AC2=01 or AC2=02) Extract odometer value from incoming message I Initialize return code to FAILURE If AC2=00 Store read odometer value in VIT2 Structure Set return code to SUCCESS Elseif AC2=01 and received odometer value is <= value in VIT2 structure Set return code to SUCCESS Elseif AC2=02 and received odometer value is = value in VIT2 structure Set return code to SUCCESS Endif Endif the exception is one or two Goto step specified in goto field 1 (G1), this Op-Code ignores no communication faults Typical Interpreter Line: Step 1F OpCode 20 Action Fields 21 00 02 00 Goto Fields 21 20 FD 99 FF 99 00 00 00 00
Page
33
A3 Op-Code Read Data from Specified Sequential Addresses (Electric Vehicle) Mode 3
Supported By: UART Interpreter 0 Description: The A3 Op-Code is used to read the data from the specified two byte addresses of a controller. It was developed specifically for reprogramming the key code of the CCU/RSA controller of the EV1 electric vehicle. To use the Op-Code, the target controller must have normal communication discontinued. The addresses will all be sequential starting from the address indicated in the actions fields. The number of addresses can be varied based on the value of AC1. See the pseudo code for more detailed information concerning Op-Code function. Action Fields: AC0: AC1: AC2: AC3: Target Device ID Number of Addresses to Read (including the address specified in AC2 & AC3) High Byte of Starting Address Low Byte of Starting Address
Pseudo Code: XX D0 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Use UART Return Type Processing Five Build Mode 03 Address Read as indicated in the table below. Contents of the XX locations are detailed in the pseudo code following the table. Request Byte 1 2 3 4 5 6 7 1 + M +1 Value AC0 1+M 03 AC XX XX XX Byte Description Device ID Message mode + (AC1 multiplied by 2) Message mode High byte of starting address Low byte of starting address High byte of second address Low byte of second address High and low byte of each consecutive address to read. 1 byte request checksum
CS
Build mode 03 message through low byte of starting address. Combine the high and low byte of starting address into one number. Increment the starting address by one. Load the new address value in the next two message bytes. Continue to increment and load the addresses until number of addresses indicated in AC1 is met. Send the message and expect a response of 03 in the mode position. Typical Interpreter Line: Step 08 Op-Code A3 Action Fields F3 05 1F 20 00 09 Goto Fields FD 12 FF 4A 00 00 00 00
Page
34
C0 Op-Code: Download Routine to RAM and Execute using Mode 6

Supported By: UART Interpreter 0 Description: The C0 Op-Code builds and sends an ALDL mode 6 download routine message. It is used to send routines with a prolog to the RAM of the device being reprogrammed. Three different messages can be sent: 1) The address to download to (starting from the highest address working backwards) 2) An optional prolog (utility record parameters indicate if one is sent or not) 3) A portion of the routine. If the entire routine can be sent in one message, it will be sent without a prolog. If it cannot be sent in one message, then the routine is split evenly and a prolog is sent with each message except for the last one. A C0 Op-Code should always be preceded by a Mode 5 (Op-Code 05) message unless the module is already prepared to accept a mode 6. Note: See Pseudo code for more information on maximum packet sizes. Action Fields: AC0: AC1: AC2: AC3: Section Number of Routine Section Number of Prolog or Prolog Value. See Exceptions. Device ID Exceptions. See Pseudo Code below
Pseudo Code: XX C0 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Use UART Return Type Processing of Three. Build Download message as indicated in the table below. Contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 6+N 7+N Value AC2 3+N 06 XX XX XX Byte Description Device ID Message length Message mode High byte of message address Low byte of message address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= maximum as defined in pseudo code) 1 byte request checksum
XX CS
If the Exception is Zero (AC3=00) or the Exception is One (AC3=01) Expect an AA return code for SUCCESS (set return type processing to 0) Check response byte 4 for return codes (set return code position to 3) If AC1 is Not 0 Retrieve section AC1 and assign to prolog Endif AC1 is Not 0 Retrieve section AC0 and assign to routine Set maximum packet to 167 (SFI-66U & PCM-66U) Endif exception is zero or exception is one If the Exception is Two (AC3=02) Expect a 06 return code for success (set return type processing to 2) For failures or last packets expect a 15 in response byte 4 and a return code in response byte 5 Check response byte 3 for message mode (set return code position to 2) Retrieve section AC0 and assign to routine Assign value in AC1 as prolog Set maximum packet to 60 bytes (VCM-1) Endif the exception is two If the Exception is Three (AC3=03) - developed for EEPROM applications Expect an 06 return code for success (set return type processing to 5) Check response byte 3 for message mode (set return code position to 2)
Page
35
(continued) Retrieve section AC0 and assign to routine Assign value in AC1 as prolog Set maximum packet to 114 bytes Endif the exception is three If Routine Length is Greater than Maximum Packet # of packets = routine length / (maximum packet - prolog length) Last message length = remainder of routine length / (maximum packet - prolog length) Addresses are calculated from highest load address to lowest load address If Exception is Two or Three (AC3=02 or AC3=03) Use value in AC1 as the prolog; copy AC1 into data byte 1 of message buffer Else Copy prolog into data area of message starting at data byte one Endif exception is two or three Do while More Packets If This is the Last Packet Change message length to last message length+3 Set the two byte packet address to the low two bytes of the four byte address in the routine Copy the last message from the routine overlaying the prolog (no prolog on last packet) Else Calculate appropriate two byte packet address Copy calculated packet address into message buffer Copy a piece of the routine into message buffer Endif this is the last packet Send the message and expect a response If Exception is Two or Three (AC3=02 or AC3=03) If Message Response was SUCCESS (06 in position 3) Loop and continue sending packets Else Indicate FAIL Endif message response was a success Else If Message Response was SUCCESS (AA in position 4) Loop and continue sending packets Else Indicate FAIL Endif message response was SUCCESS Endif exception is two End do while more packets Else Use low two bytes of the four byte address in the routine for message address Copy routine into message buffer, NO prolog on packet Send the message and expect a response Endif routine length is greater than maximum packet If Exception is One (AC3=01) Do while response byte 4 is $55 Wait for another response End do while response is $55 Endif exception is one Look for response byte 4 in Goto fields If Response Byte 4 is Found Goto appropriate step Else Goto step indicated by FF goto field Endif response byte 4 is found Typical Interpreter Line: Step Op-Code 10 C0 Action Fields 01 39 F4 02 Goto Fields 04 0D FD 20 FF 49
06 11
00 00
Page
36
C1 Op-Code: Download Routine to RAM and Execute using Mode 16

Supported By: UART Interpreter 0 Description: This Op-Code is an ALDL mode 16 with three byte addressing. It is used to send routines with a prolog to RAM of the device being reprogrammed. Note: AC1 Op-Code should always follow a Mode 5 (Op-Code 05) message. Action Fields: AC0: AC1: AC2: AC3: Section Number of Routine Use value as high byte of prolog Use value as low byte of prolog Device ID
Pseudo Code: XX C1 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Use UART Return Type Processing of Two. Build Mode 16 Download Request as indicated in the table below. Contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 7+N 8+N Value AC3 4+N 10 XX XX XX XX Byte Description Device ID Message length Message mode High byte of load address Middle byte of load address Low byte of load address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= maximum as defined in pseudo code) 1 byte request checksum
XX CS
For failures or last packets expect a 15 in response byte 4 and a return code in response byte 5 and Expect a 06 return code for success (set return type processing to 2) Check response byte 3 for message mode (set return code position to 2) Retrieve section AC0 and assign to routine Set maximum packet to 60 If Routine Length is Greater than Maximum Packet # Of packets = routine length / (maximum packet - prolog length) Last message length = remainder of routine length / (maximum packet - prolog length) If remainder of the routine length is 0 Reduce the number of messages sent with a prolog by one Endif remainder of the routine length is 0 Addresses are calculated from high to low memory so last packet can be executed once downloaded Copy AC1 into next data byte of data area, this is high byte of prolog Copy AC2 into next data byte of data area, this is low byte of prolog Do while More Packets If This is the Last Packet Change message length to last message length+4
Page
37
(continued) Set three byte message address to the low three bytes of the four byte address in the routine Copy the last message from the routine overlaying the prolog (no prolog in last packet) Else Calculate appropriate two byte packet address for next data packet Copy calculated packet address into message buffer Copy a piece of the routine into message buffer Endif this is the last packet Send the message and expect a response Goto UART Return Type Processing If Message Response was SUCCESS (10 in position 3) Loop and continue sending packets Else Indicate FAIL Endif message response was SUCCESS End do while more packets Else Routine Length is Not Greater than Maximum Packet Copy routine into message buffer, no prolog in message Send the message and expect a response Goto UART Return Type Processing Endif routine length is greater than maximum packet Look for response byte 3 in Goto fields If Response byte 3 is Found Goto appropriate step Else Goto step indicated by FF goto field Endif response byte 3 is found Typical Interpreter Line: Step 10 Op-Code C1 Action Fields 01 4E 75 F4 Goto Fields 05 0D FF 99 00 00
10 11
00 00
Page
38
C2 Op-Code: Download Routine to RAM and Save Two Byte Response using Mode 6
Supported By: UART Interpreter 0 Description: The C2 Op-Code is processed exactly like the C0 Op-Code except for response processing. If a valid response is received from the Mode 6 command, positions 4 and 5 of the response are saved. The Action Field 3 (AC3) is the ID of the bytes saved. The valid ID's are 0x00 thru 0x13. Note: Only twenty (20) two byte responses can be saved before ID positions must be reused. Note: If the routine can be downloaded in one packet no prolog is need. See the Pseudo code for more information on maximum packet sizes. Action Fields: AC0: AC1: AC2: AC3: Section Number of Routine Section Number of Prolog. Device ID ID of saved bytes (0x00 0x13)
The message build and transmit portion of this Op-Code is identical to the C0 Op-Code. The only change is after a successful response is returned from the control module. If Successful Response is Received Save two bytes from the response to storage ID indicated by AC3 (bytes 5 & 6 of response are saved) Endif successful response is received Look for response byte 4 in Goto fields If Response Byte 4 is Found Goto appropriate step Else Goto step indicated by FF goto field Endif response byte 4 is found Typical Interpreter Line: Step 10 Op-Code C2 Action Fields 04 03 F4 09 Goto Fields 05 0D FF 99 00 00
AA 11
00 00
Page
39
C3 Op-Code: Download Routine to RAM and Execute using Mode 6 (Electric Vehicle)
Supported By: UART Interpreter 0 Description: The C3 Op-Code builds and sends an ALDL mode 6 download routine message. It is used to send routines with a prolog to the RAM of the device being reprogrammed. This Op-Code was developed specifically for the EV1 electric vehicle BTCM controller because the controller does not respond to each download and uses a one byte prolog. As with the C0 Op-Code, if the entire routine can be sent in one message, it will be sent without a prolog. If it cannot be sent in one message, then the routine is split evenly and a prolog is sent with each message except for the last one. A C3 Op-Code should always be preceded by a Mode 5 (Op-Code 05) message unless the module is already prepared to accept a mode 6. Note: See Pseudo code for more information on maximum packet sizes. Action Fields: AC0: AC1: AC2: AC3: Section Number of Routine Prolog Value Device ID Not Used
Use UART Return Type Processing of One. Build Download message as indicated in the table below. Contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 6+N 7+N Value AC2 3+N 06 XX XX XX Byte Description Device ID Message length Message mode High byte of message address Low byte of message address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= maximum as defined in pseudo code) 1 byte request checksum
XX CS
Retrieve section AC0 and assign to routine Retrieve the address from the routine header Assign value in AC1 as prolog Set maximum packet size to 60 bytes Send the Mode 6 message and do not expect a response.
If Routine Length is Greater than Maximum Packet # Of packets = routine length / (maximum packet - prolog length) Last message length = remainder of routine length / (maximum packet - prolog length) Addresses are calculated from highest load address to lowest load address Use value in AC1 as the prolog; copy AC1 into data byte 1 of message buffer Do while More Packets
Page
40
(continued) If This is the Last Packet Change message length to last message length+3 Set the two byte packet address to the low two bytes of the four byte address in the routine Copy the last message from the routine overlaying the prolog (no prolog on last packet) Else Calculate appropriate two byte packet address Copy calculated packet address into message buffer Copy a piece of the routine into message buffer DO NOT include a prolog Endif this is the last packet Send the message and do not expect a response Loop and continue sending packets End do while more packets Else Use low two bytes of the four byte address in the routine for message address Copy routine into message buffer, NO prolog on packet Send the message do not expect a response Endif routine length is greater than maximum packet
Typical Interpreter Line: Step 10 Op-Code C3 Action Fields 01 39 F9 00 Goto Fields FD 20 FF 21 00 00
00 11
00 00
Page
41
C4 Op-Code: Download Routine to RAM using Mode 20 (Holden Telematics)

Supported By: UART Interpreter 0 Description: The C4 Op-Code builds and sends ALDL mode 20 messages with three address bytes. It is used to send routines to the RAM of the device being reprogrammed. This Op-Code was developed specifically for the Holden Telematics controller but can be used for any controllers using mode 20 in the same manner. Note: See Pseudo code for more information on maximum packet sizes. Action Fields: AC0: AC1: AC2: AC3: Device ID Routine Number Not Used Not Used
Build Mode 20 RAM Download Request as indicated in the table below. Contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 7+N 8+N Value AC0 4+N 14 XX XX XX XX Byte Description Device ID Message length Message mode High byte of download address Middle byte of download address Low byte of download address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= maximum as defined in pseudo code) 1 byte request checksum
XX CS
Retrieve section AC1 and assign to routine Get download address from routine address Get number of bytes to download from routine size Get packet length from utility file header Do while number of bytes to download not yet 0 If number of bytes to download is greater than packet length Limit packet length to number of bytes to download Endif number of bytes to download is greater than packet length Copy download address into message bytes 4.6 Copy next data block from routine into message starting with byte 7, packet length specifies the number of bytes to copy. Send the message and expect a response If message response was SUCCESS If the response byte 3 is $14 (expected mode) If response byte 4 is $06 (download completed) Increment the download address by the packet size Decrement the number of bytes to download by the packet length
Page
42
(continued) Else Break the loop Endif response byte 4 is $06 (download completed) Else Set message response FAILURE Break the loop Endif the response byte 3 is $14 (expected mode) Else Break the loop Endif message response was SUCCESS Enddo while number of bytes to download not yet 0 If message response was SUCCESS Set response code to response byte 4 Else Set response code to NO COMM Endif message response was SUCCESS Look for response code in Goto fields If response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif response code is found Typical Interpreter Line: Step 10 Op-Code C4 Action Fields E4 03 00 00 Goto Fields 15 0D FF 99 00 00
06 11
00 00
Page
43
C5 Op-Code: Execute Routine using Mode 21 (Holden Telematics)

Supported By: UART Interpreter 0 Description: The C5 Op-Code builds and sends an ALDL mode 21 message with three address bytes. It is used to start a routine in RAM of the device being reprogrammed. This Op-Code was developed specifically for the Holden Telematics controller but can be used for any controllers using mode 21 in the same manner. Action Fields: AC0: AC1: AC2: AC3: Device ID Routine Number Not Used Not Used
Build Mode 21 RAM Execute Request as indicated in the table below. Contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 Value AC0 04 15 XX XX XX CS Byte Description Device ID Message length Message mode High byte of start address Middle byte of start address Low byte of start address 1 byte request checksum
Retrieve section AC1 and assign to routine Get start address from routine address Copy start address into message bytes 4.6 Send the message and expect a response If message response was SUCCESS If the response byte 3 is not $15 (expected mode) Set message response FAILURE Endif the response byte 3 is not $15 (expected mode) Endif message response was SUCCESS If message response was SUCCESS Set response code to response byte 4 Else Set response code to NO COMM Endif message response was SUCCESS Look for response code in Goto fields If response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif response code is found Typical Interpreter Line: Step 10 Op-Code C5 Action Fields E4 03 00 00 06 11 Goto Fields 15 0D FF 99 00 00 00 00 Page 44
D0 Op-Code: Download Calibration / Software File using Mode 6

Supported By: UART Interpreter 0 Description: The D0 Op-Code is used to download a data file using mode 6 messages. The device must be prepared to accept a mode 6 message before this Op-Code can be used. The "data address information" in the header, is used for the first packet of data that is downloaded. The additional packet addresses are determined based off the value of the exception field (AC3). The exception values are defined as follows: 00 - The address will be incremented by the number of bytes that are downloaded in each calibration data packet (i.e. if address 1 = 0x8000 and 0x80 bytes are downloaded in the data packet, then address 2 = 0x8000 + 0x80 = 0x8080). 01 - The address remains the same for all of the calibration data packets. 02 - Uses the same functionality of exception 00 but increases the starting position of the calibration data packet 3 bytes (from 16 to 19) to allow for a longer prolog (Developed for EEPROM applications). See the pseudo code for more detailed information concerning exception function. Action Fields: AC0: AC1: AC2: AC3: ID of file to download Section number of Prolog or Prolog Value. See Exceptions. Device ID Exceptions. See Pseudo Code below
Pseudo Code: XX D0 AC0 AC1 AC2 AC3 Find the file with ID equal to AC0 Load the file into memory Build Mode 6 Download Request as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 6+N+M 7+N+M Value AC2 6+N+M 06 XX XX XX Byte Description Device ID Message length (N is prolog length, M data bytes in message) Message mode High byte of load address Low byte of load address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= maximum as defined in pseudo code) 1 byte request checksum G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
XX CS
If the Exception is Zero (AC3=00) Expect an AA return code for success (set return type processing to 0) Check response byte 4 for return codes (set return code position to 3) Retrieve section AC1 and assign to the prolog Set message length to 6 + prolog length + data packet length Copy high byte of prolog address into data byte 1 of buffer Copy low byte of prolog address into data byte 2 of buffer Copy prolog into buffer starting at byte 3 Copy high byte of data address information from the Header into the data buffer Copy low byte of data address information from the Header into the data buffer Endif the exception is zero
Page
45
(continued) If the Exception is One (AC3=01) Expect a 06 return code for success (set return type processing to 2) For failures or last packets expect a 15 in response byte 4 and a return code in response byte 5 Check response byte 3 for message mode (set return code position to 2) Set message length to 4 + data packet length Copy high byte of data address information from the Header into the data buffer byte 1 Copy low byte of data address information from the Header into the data buffer byte 2 Copy AC1 into data buffer byte 3 to be used as a prolog Endif the exception is one If the Exception is Two (AC3=02) - (developed for EEPROM applications) Expect a 06 return code for success (set return type processing to 2) For failures or last packets expect a 15 in response byte 4 and a return code in response byte 5 Check response byte 3 for message mode (set return code position to 2) Retrieve section AC1 and assign to the prolog Set message length to 6 + prolog length + data packet length Copy high byte of prolog address into data byte 1 of buffer Copy low byte of prolog address into data byte 2 of buffer Copy prolog into buffer starting at byte 3 Copy high byte of data address information from the Header into the data buffer Copy low byte of data address information from the Header into the data buffer Endif the exception is two Do while more data to download Copy M data bytes into message buffer following the front end Put message checksum at end of data buffer Send message and receive the response If Exception is Zero or Two (AC3=00 or AC3=02) Increment message data address by number of data bytes downloaded in message Else If Exception is One (AC3=01) Use the same address for all data packets Endif exception is one Endif exception is zero or two Update and display percent downloaded End do while more data to download Look for response byte 4 in Goto fields If Response Byte 4 is Found Goto appropriate step Else Goto step indicated by FF goto field Endif response byte 4 is found Typical Interpreter Line: Step 08 Op-Code D0 Action Fields 01 03 F4 00 Goto Fields FD 12 FF 4A 00 00
AA 09
00 00
Page
46
D1 Op-Code: Download Calibration or Software Module using Mode 16

Supported By: UART Interpreter 0 Description: Download a data file using mode 16. The device must be prepared to accept a mode 16 message before this Op-Code can be used. Action Fields: AC0: AC1: AC2: AC3: ID of file to download Use value as high byte of prolog Use value as low byte of prolog Device ID G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Pseudo Code: XX D1 AC0 AC1 AC2 AC3 Find the file with ID equal to AC0 Load the file into memory Expect a 06 return code for success (set return type processing to 2) For failures or last packets expect a 15 in response byte 4 and a return code in response byte 5 Check response byte 3 for message mode (set return code position to 2) Build Mode 6 Download Request as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 7+N+M 8+N+M Value AC3 4+M 10 XX XX XX XX Byte Description Device ID Message length (M is data bytes in message) Message mode High byte of load address Middle byte of load address Low byte of load address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte M (M <= maximum as defined in pseudo code) 1 byte request checksum
XX CS
Copy high byte of data load address from the Utility header into message Copy middle byte of data load address from the Utility header into message Copy low byte of data load address from the Utility header into message Copy AC1 into data area of message as the high byte of the prolog into data byte 1 Copy AC2 into data area of message as the high byte of the prolog into data byte 2 Do until all of the data is downloaded Copy next packet of data into message buffer at data byte 3, packet size is from header Copy message checksum at end of data area of message Send message and receive the response Goto UART Return Type Processing Update and display percent downloaded End do when all of the data is downloaded Look for response byte 3 in Goto fields If response byte 3 is found Goto appropriate step Else Goto step indicated by FF goto field Endif response byte 3 is found Typical Interpreter Line: Step 98 Op-Code D1 Action Fields 02 4E 75 00 06 11 Goto Fields 05 0D FF 99 00 00 00 00
Page
47
D2 Op-Code: Download VIN using Mode 6 & 16

Supported By: UART Interpreter 0 Description: The D2 Op-Code is used to download the VIN. The device must be prepared to accept a mode 6 or 16 message before this Op-Code can be used. The Op-Code uses mode 6 for two byte addressing and mode 16 for three byte addressing. See Action Fields for more information on type of addressing. Action Fields: AC0: AC1: Module ID for VIN Prolog routine number for Two byte addressing Prolog ID for Three byte addressing 00 - Use 4E75 as the prolog Device ID 00 Two byte addressing - 01 Three byte addressing
AC2: AC3:
Build Mode 6 or 16 Download Request as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 6+N+M 7+N+M Value AC2 4+M 06 or 10 XX XX XX Byte Description Device ID Message length (M is data bytes in message) Message mode High byte of load address Middle of low byte of load address Low byte of load address or data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= maximum as defined in pseudo code) 1 byte request checksum
XX CS
If the Exception is Zero (AC3=00) Use two byte addressing Expect a 06 return code for success (set return type processing to 2) For failures or last packets expect a 15 in response byte 4 and a return code in response byte 5 Check response byte 3 for message mode (set return code position to 2) Set message mode to 06 Copy high byte of data load address from the Utility header into message Copy low byte of data load address from the Utility header into message Reserve this byte for high byte of module checksum Reserve this byte for low byte of module checksum Copy AC0 into data area of message as the module ID Copy AC1 into data area of message as the prolog Endif the exception is zero If the Exception is One (AC3=01) Use three byte addressing Set the return type processing to 2 Set the return code position to 3
Page
48
(continued) Set message mode to 10 Copy high byte of data load address from the Utility header into message Copy middle byte of data load address from the Utility header into message Copy low byte of data load address from the Utility header into message Reserve this byte for high byte of module checksum Reserve this byte for low byte of module checksum Copy AC0 into data area of message as the module ID If the Prolog Identifier is Zero (AC1=00) Copy 4E into data area of message as the high byte of the prolog Copy 75 into data area of message as the low byte of the prolog Endif the prolog identifier is zero Endif the exception is one Copy VIN data into data area of message following the prolog Calculate module checksum by adding all bytes from module ID through VIN Copy module checksum into module checksum area of message Copy message checksum at end of data area of message Send message and receive the response Goto UART Return Type Processing Update and display percent downloaded If Response Byte in Position 4 is 15 Look for response byte 5 in goto fields If Response byte 5 is Found Goto appropriate step Else Goto step indicated by FF goto field Endif response byte 5 is found Else Error invalid response from module Endif response byte in position 4 is 15 Typical Interpreter Line: Step 98 Op-Code D2 Action Fields 06 00 F4 01 Goto Fields FD A0 FF A9 00 00
06 99
00 00
Page
49
D4 Op-Code: Download Calibration / Software File using Mode 6 (Saturn EEPROM)

Supported By: UART Interpreter 0 Description: The D4 Op-Code is used to download a data file using mode 6 messages. The device must be prepared to accept a mode 6 message before this Op-Code can be used. In this particular Op-Code, the mode 5s are sent as part of the D4 logic and do not need to be specified by separate utility file entries. The "data address information" in the header, is used for the first packet of data that is downloaded, the address will be incremented by the number of bytes that are downloaded in each data packet (i.e. if address 1 = 0x8000 and 0x80 bytes are downloaded in the data packet, then address 2 = 0x8000 + 0x80 = 0x8080). Warnings: In order to correctly write a previously calculated checksum to the controller (AC3 = 02), You will first need to run Op-Code D4 with AC3 equal to 0 or 1. These two routines will store a checksum value to the global checksum area. In order to correctly write the CAL ID (AC3 = 03) or ABS option byte (AC3 = 05), You will first need to run Opcode D4 with AC3 equal to 0. This will extract the CAL ID and its address from the Saturn calibration file header. This Op-Code requires two routine blocks to be loaded in the utility file. The first (AC1) will be the routine data, stored in traditional format. The second (AC1 + 1) will be a header block containing Saturn specific offset information. EXAMPLE: If you set AC1 to 7, section 7 will contain your routine and section 8 will contain a block of Saturn specific header data. The next section block available for other Op-Codes will be 9. Action Fields: AC0: AC1: AC2: AC3: ID of file to download Section number of routine to download. Device ID Exceptions. 00 = Send multiple mode 6 messages with each containing a different block of cal data. 01 = Send a single mode 6 which will write DEAD to the checksum of the controller 02 = Send a single mode 6 which will write the previously stored global checksum to the controller 03 = Send a single mode 6 which will write the previously stored CAL ID to the controller 04 = Send only the mode 6 file. Do not overlay any additional data. 05 = Send a single mode 6 which will write the traction byte to a Saturn ABS controller. 06 = Send a single mode 6 which will write the VIN. 07 = Send a single mode 6 which will write the odometer (electric vehicle).
This Op-Code use return type processing one (ignore response). Find the routine with section equal to AC0 + 1 (This is the header block associated with the routine stored at section AC0) Extract required information Find the routine with section equal to AC0 (This is the actual download and run routine) Load this data into the download request buffer
Page
50
(continued) Build Mode 6 Download Request as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 6+N+M 7+N+M Value AC2 6+N+M 06 XX XX XX Byte Description Device ID Message length (N is prolog length, M data bytes in message) Message mode High byte of load address Low byte of load address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= maximum as defined in pseudo code) 1 byte request checksum.
XX CS
If the Exception is One, Two, Three, Four, Five, Six, or Seven (AC3 > 0) Copy data bytes from appropriate locations Overlay the copied data bytes into the data portion of the routine Update size bytes appropriately Update global checksum if necessary Send a mode 5 message and receive reply Fail if error Send message to write the specified information Endif the exception is greater than zero processing If the Exception is Equal to Zero (AC3 = 0) Find the calibration file with ID equal to AC0 Load the file into memory Overlay adaptive data from VIT2 to appropriate location in calibration data (if required) Do while more data to download Copy M data bytes into message buffer at the appropriate location If Device ID is F2 Wait for F0 poll with the Tech 2 as Master else Wait for F0 poll with the Tech 2 as Slave Endif device id is F2 Send a mode 8 message Send a mode 5 message and check response If the Mode 5 Response is Not Valid Send the Mode 8 and Mode 5 message up to three more times If Response is Valid Continue with Mode 6. Else Fail with error. Endif response is valid Endif the mode 5 response is not valid Send the Mode 6 message to write the calibration data Ignore any response Increment message data address by number of data bytes downloaded in message Update and display percent downloaded End do while more data to download Update global checksum field for later processing. Endif the exception is equal to zero Typical Interpreter Line: Step 08 Op-Code D4 Action Fields 01 00 F4 00 00 09 Goto Fields FD 12 FF 4A 00 00 00 00
Page
51
D5 Op-Code: Download Calibration / Software File using Mode 12 (Electric Vehicle)

Supported By: UART Interpreter 0 Description: The D5 Op-Code is used to download a data file using mode 12 (0C) messages. It was developed specifically for reprogramming the BTCM controller of the EV1 electric vehicle. To perform a download, the device must be prepared to accept a download by receiving a success response from a 05 Op-Code. The "data address information" in the calibration file, which must use the Saturn calibration file format, is used for the first packet of data that is downloaded. The address will then be incremented by the number of bytes that are downloaded in each calibration data packet (i.e. if address 1 = 0x8000 and 0x80 bytes are downloaded in the data packet, then address 2 = 0x8000 + 0x80 = 0x8080). No prolog is used. See the pseudo code for more detailed information concerning Op-Code function. Action Fields: AC0: AC1: AC2: AC3: ID of file to download Device ID Not Used Not Used
Pseudo Code: XX D0 AC0 AC1 AC2 AC3 Find the file with ID equal to AC0 Load the file into memory Build Mode 12 Download Request as indicated in the table below, contents of the XX locations is detailed in the pseudo code following the table Request Byte 1 2 3 4 5 6 6+N+M 7+N+M Value AC2 6+M 06 XX XX XX Byte Description Device ID Message length (M data bytes in message) Message mode High byte of load address Low byte of load address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= maximum as defined in pseudo code) 1 byte request checksum G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
XX CS
Copy high byte of data address information from the calibration file header into the data buffer Copy low byte of data address information from the calibration file header into the data buffer Expect a 00 in position 3 for success Do while more data to download Copy M data bytes into message buffer following the front end Put message checksum at end of data buffer Send message and receive the response Increment message data address by number of data bytes downloaded in message Update and display percent downloaded End do while more data to download Send a Mode FF message; do not expect a response. Typical Interpreter Line: Step 08 Op-Code D5 Action Fields 01 F9 00 00 00 09 Goto Fields FD 12 FF 4A 00 00 00 00 Page 52
D6 Op-Code: Erase Flash Block using Mode 22 (Holden Telematics)

Supported By: UART Interpreter 0 Description: The D6 Op-Code builds and sends an ALDL mode 22 message. It is used to erase a specified block of flash memory of the device being reprogrammed. This Op-Code was developed specifically for the Holden Telematics controller but can be used for any controllers using mode 22 in the same manner. Action Fields: AC0: AC1: AC2: AC3: Device ID Block Number Not Used Not Used
Build Mode 22 Flash Erase Request as indicated in the table below. Contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 Value AC0 4+N 16 XX CS Byte Description Device ID Message length Message mode Block number 1 byte request checksum
Copy AC1 address into message byte 4 Send the message and expect a response If message response was SUCCESS If the response byte 3 is not $16 (expected mode) Set message response FAILURE Endif the response byte 3 is not $16 (expected mode) Endif message response was SUCCESS If message response was SUCCESS Set response code to response byte 5 Else Set response code to NO COMM Endif message response was SUCCESS Look for response code in Goto fields If response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif response code is found Typical Interpreter Line: Step 10 Op-Code D6 Action Fields E4 01 00 00 Goto Fields 15 0D FF 99 00 00
06 11
00 00
Page
53
D7 Op-Code: Download Software Module using Mode 23 (Holden Telematics)

Supported By: UART Interpreter 0 Description: The D7 Op-Code builds and sends ALDL mode 23 messages with three address bytes. It is used to send modules to the flash memory of the device being reprogrammed. This Op-Code was developed specifically for the Holden Telematics controller but can be used for any controllers using mode 23 in the same manner. Note: See Pseudo code for more information on maximum packet sizes. Action Fields: AC0: AC1: AC2: AC3: Device ID Calibration Number Not Used Not Used
Build Mode 23 Flash Program And Verify Request as indicated in the table below. Contents of the XX locations is detailed in pseudo code following the table
Request Byte 1 2 3 4 5 6 7 7+N 8+N
Value AC0 4+N 17 XX XX XX XX
Byte Description Device ID Message length Message mode High byte of download address Middle byte of download address Low byte of download address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= maximum as defined in pseudo code) 1 byte request checksum
XX CS
Find the file with ID equal to AC1 Load the file into memory If AC3 is $00 Get download address from utility file header Else Get download address from global address (must be set by Op-Code $F1) Endif AC3 is $00 Get number of bytes to download from file size Get packet length from utility file header Do while number of bytes to download not yet 0 If number of bytes to download is greater than packet length Limit packet length to number of bytes to download Endif number of bytes to download is greater than packet length Copy download address into message bytes 4.6 Copy next data block from file into message starting with byte 7, packet length specifies the number of bytes to copy Send the message and expect a response 1993-2011 General Motors Company, GM Customer Care & Aftersales. All Rights Reserved. Page 54
(continued) If message response was SUCCESS If the response byte 3 is $17 (expected mode) If response byte 4 is $06 (download completed) Increment the download address by the packet size Decrement the number of bytes to download by the packet length Else Break the loop Endif response byte 4 is $06 (download completed) Else Set message response FAILURE Break the loop Endif the response byte 3 is $17 (expected mode) Else Break the loop Endif message response was SUCCESS Enddo while number of bytes to download not yet 0 If message response was SUCCESS Set response code to response byte 4 Else Set response code to NO COMM Endif message response was SUCCESS Look for response code in Goto fields If response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif response code is found Typical Interpreter Line: Step 10 Op-Code D7 Action Fields E4 01 00 00 Goto Fields 15 0D FF 99 00 00
06 11
00 00
Page
55
D8 Op-Code: Execute Software Module using Mode 24 (Holden Telematics)

Supported By: UART Interpreter 0 Description: The D8 Op-Code builds and sends an ALDL mode 24 message with three address bytes. It is used to start the execution of a software module in the flash memory of the device being reprogrammed. This Op-Code was developed specifically for the Holden Telematics controller but can be used for any controllers using mode 24 in the same manner. Action Fields: AC0: AC1: AC2: AC3: Device ID Start address high byte Start address mid byte Start address low byte
Build Mode 24 Flash Memory Execute Request as indicated in the table below. Contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 Value AC3 04 18 XX XX XX CS Byte Description Device ID Message length Message mode High byte of start address Middle byte of start address Low byte of start address 1 byte request checksum
Copy start address from AC1.AC3 into message bytes 4.6 Send the message and expect a response If message response was SUCCESS If the response byte 3 is not $18 (expected mode) Set message response FAILURE Endif the response byte 3 is not $18 (expected mode) Endif message response was SUCCESS If message response was SUCCESS Set response code to response byte 4 Else Set response code to NO COMM Endif message response was SUCCESS Look for response code in Goto fields If response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif response code is found Typical Interpreter Line: Step 10 Op-Code D8 Action Fields E4 00 00 00 06 11 Goto Fields 15 0D FF 99 00 00 00 00
Page
56
F0 Op-Code: Wait for Poll from a Device

Supported By: UART Interpreter 0 Description: The F0 Op-Code waits for a poll from a device. Action Fields: AC0: AC1: AC2: AC3: G0: Device ID Number of 100 ms intervals to wait 00 - Not Used 00 - Not Used 00 - Don't care
Pseudo Code: XX F0 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Do While Wait Time is Not Greater than (AC1*100ms) Wait for a poll from device ID AC0 End do Goto step specified in goto field 1 (G1), this Op-Code ignores no communication faults Typical Interpreter Line: Step 10 Op-Code F0 Action Fields F4 05 00 00 Goto Fields FF 99 00 00 00 00
00 11
00 00
Page
57
Interpreter 1 - Class 2 Communications Programming Op-Codes
Page
58
Class 2 No Communications Processing

Supported By: Class 2 Interpreter 1 Description: Normal processing of a request message is to re-send the request up to three times if the transmission of a request fails. However, if the transmission is successful and no controllers respond to the request, then the request will fail with a no comm. Fault**. When writing instructions for a Utility File, the FD code can be used to determine the next step to execute after a no comm. fault occurs. The 'FD' processing can be used for any step in the utility file where a no comm. condition can occur**. ** Note: - There are some Class 2 Op-Codes that send out a request and do not look for a response (i.e. Ignore Response). - There are some Class 2 Op-Codes that send out a request and dont care if there are no responses (i.e. Ignore Error). - There are some Class 2 Op-Codes that do not support the no comm. (FD) processing. These special cases are defined within the individual Class 2 Op-Codes.
Pseudo Code: XX OP AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
If no comm. occurred If the Op-Code Ignores No Communication Faults (Ignore Error or Ignore Response) Continue reprogramming event based on specific Op-Code logic Else Check goto fields for an FD return code (G0, G2, G4, G6, or G8) If found (FD) Flag appropriate step to execute next and return Else Check goto fields for an FF return code (G0, G2, G4, G6, or G8) If found (FF) Flag appropriate step to execute next and return Else End programming with fatal error Endif Endif Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 11 Op-Code OP Action Fields B4 03 10 00 Goto Fields FD 2A FF 4A 00 00
65 12
00 00
Page
59
Class 2 Response Processing

Supported By: Class 2 Interpreter 1 Description: The Response Processing defines how the tool deciphers the response(s) returned from a control module after a successful request has been transmitted to the control module **. The response buffer fields, filled when a controller responds to a message, are identified as follows: Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte N+5 Byte N+6 - Priority and Message Type - Target Address (typically targeted to the tester device) - Source Address (typically sent from a control module) - Message ID (typically a positive/negative response ID) - Misc. Response Data (N = 4096 bytes max.) - High Byte of Block Transfer Message Checksum - Low Byte of Block Transfer Message Checksum
** Note: - There are some Class 2 Op-Codes that send out a request and do not look for a response (i.e. Ignore Response). - There are some Class 2 Op-Codes that send out a request and dont care if there are no responses (i.e. Ignore Error). - There are some Class 2 Op-Codes that do not support the no comm. (FD) processing. These special cases are defined within the individual Class 2 Op-Codes. Pseudo Code: Ignore Response Processing If the op-code specifies a response processing type of Ignore Response No response messages will be processed (read) from the vehicle communication link. Response processing will return immediately with Success after the request has been transmitted Endif Ignore Error Processing If the op-code specifies a response processing type of Ignore Error The response data (one or more messages) WILL be processed (read) from the vehicle communication link (based on FE Response Processing or Individual Device Response Processing). Regardless of whether the response is a positive, negative, or no response is received, response processing will return with Success Endif FE (all devices) Response Processing If the request message is targeted to all (FE) devices Process the response from the controller(s) on the vehicle communication link (only for controllers that respond to the FE request) If a negative (7F) response is processed from one of the responding controllers Return immediately with failed (negative response) and the data from the negative response Endif Wait for 2 seconds of no responses being processed (idle vehicle communication link) If after 2 seconds there have been NO responses processed (zero in total) Return with a no communication response Else Return with Success and the data from the last response processed Endif Endif
Page
60
Individual Device Response Processing If the request message is targeted to a specific device (ex. $10, $11, $18, $28, $40, ) Process the response from the controller on the vehicle communication link If a positive response was received (Response Message ID = Mode Number + $40) Return with Success and the positive response data Endif If a negative response was received (Response Message ID = 0x7F) If the last byte of the response is a $23 (Routine Not Complete) Wait up to one more second for an additional (positive/negative) response
(continued)
If no more responses are received (in the 1 second) Return with failed (negative response) and the data from the (0x7F . . . 0x23) response Endif Endif If the Response Message target address does not equal the Request Message source address Keep attempting to process responses from the controller If no more responses are received (in the remaining amount of time) Return with failed (negative response) and the data from the mis-matched target/source response Endif Endif Endif If no response was ever received from the individual device Return with a No Communication response Endif Special Mode $36 Response Processing If a positive response was received (Response Message ID = $76) If response code data byte is a $78 or a $6F (Response Data Byte #2 action not yet complete) Keep attempting to process responses from the controller until a true positive or negative is received Endif Endif Endif
Page
61
01 Op-Code: Setup Global Variables

Supported By: Class 2 Interpreter 1 Description: The 01 Op-Code is used to set the global variables used during the programming process. The Op-Code allows the user to alter the global settings any time during the programming event by issuing another 01 OpCode. AC0 is used to set the Global Source Address. The Global Source Address is initialized to F0. AC1 is used to toggle the option to send periodic 3F messages to all devices (target address = FE) during programming. This option should be turned ON when the tool is required to send a periodic 3F message to all devices to prevent all controllers on the link from resuming normal communications during a reprogramming event. If this option is ON, the 3F message will be transmitted at least once every 2.45 seconds. The default setting for this option is ON. If the default settings are correct, the 01 Op-Code is not required in the Interpreter instructions. Action Fields: AC0: AC1: AC2: AC3: Global Source Address (Tester ID) 00 - Do not send periodic 3F messages to all devices 01 - Send periodic 3F messages to all devices during programming 00 - Not Used 00 - Not Used
Pseudo Code: XX 01 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Set global source address to value in AC0 If AC1 = 00 Turn periodic 3F transmission to all devices (Target address = "FE") OFF Else Turn periodic 3F transmission to all devices (Target address = "FE") ON Endif AC1 = 00 Goto step specified by goto field one (G1) Typical Interpreter Line: Step 01 Op-Code 01 Action Fields F0 01 00 00 Goto Fields 00 00 0 00 00 00
00 02
00 00
Page
62
10 Op-Code: Initiate Diagnostic Operation

Supported By: Class 2 Interpreter 1 Description:
Note: This Op-Code is NOT functional within the software application (i.e. A request to initiate a
Diagnostic Operation Mode will never be sent out over the vehicle communication link.) The response processing will be based on GOTO field G1. The 10 Op-Code is used to inform devices on the serial data link that the tool is ready to start diagnostic procedures using the link and the devices on the link may need to alter their normal operation. (This Op-Code is seldom used in programming. It was used only by truck in the 1995 model year.) AC0 is used to set the Target Device ID. AC1 is the level of diagnostic operations to be performed. See XDE - 3001B page 93 for a list of level operation codes. Action Fields: AC0: AC1: AC2: AC3: Target Device ID 00 Default (See XDE-3001B for details) 00 - Not used 00 - Not Used
Build message 10 as indicated in the table below Request Byte 1 2 3 4 5 6 Pseudo Code: XX 10 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 N/A - Set the target device ID to value in AC0 N/A Set the diagnostic operation level (within the request) to AC1 N/A Send Diagnostic message to inform devices on the link N/A Goto Class 2 Response Processing This Op-Code is NOT supported. The response processing will be based on GOTO field G1. Typical Interpreter Line: Step 01 Op-Code 10 Action Fields 10 90 00 00 Goto Fields FF 99 00 00 00 00 Value 6C AC0 ## 10 AC1 CS Byte Description Format and type Target device ID Global source ID Initiate Diagnostic Operation Mode Level of diagnostic operation 1 byte message checksum (handled by the system)
50 02
00 00
Page
63
14 Op-Code: Clear Diagnostic Information

Supported By: Class 2 Interpreter 1 Description: The 14 Op-Code builds a standard mode 14 message that initializes all diagnostics and diagnostic information in a device. Diagnostic information is, but is not limited to, diagnostic trouble codes (DTC) and corresponding DTC status, freeze frame data or other on-board test results that may be stored as a result of diagnostic activity. This Op-Code will ignore the error of no response being received from the request. If this condition occurs, then Goto Step G1 will be executed. Action Fields: AC0: AC1: AC2: AC3: Target Device ID 00 Not Used 00 Not Used 00 Not Used
Pseudo Code: XX 14 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build Return to Normal Mode message as indicated in the table below Request Byte 1 2 3 4 5 Value 6C AC0 ## 14 CS Byte Description Format and type Target device ID Global source ID Clear Diagnostic Information Mode 1 byte message checksum (handled by the system)
Send Mode 14 message and receive the response Goto Class 2 Response processing If No response was received Goto step G1 Else Look for response byte 4 in goto fields If Response Byte 4 is found Goto appropriate step Else Goto step indicated by FF goto field Endif Endif Typical Interpreter Line: Step 1F Op-Code 14 Action Fields 10 00 00 00 Goto Fields 54 20 7F 1B FF 24 00 00 00 00
Page
64
20 Op-Code: Return to Normal Mode

Supported By: Class 2 Interpreter 1 Description: The 20 Op-Code builds a standard mode 20 message to return a device to Normal Mode operating conditions. This Op-Code will ignore the error of no response being received from the request. If this condition occurs, then Goto Step G1 will be executed. Action Fields: AC0: AC1: AC2: AC3: Target Device ID 00 - Not Used 00 - Not Used 00 - Not Used
Pseudo Code: XX 20 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build Return to Normal Mode message as indicated in the table below Request Byte 1 2 3 4 5 Value 6C AC0 ## 20 CS Byte Description Format and type Target device ID Global source ID Return to Normal Communication Mode 1 byte message checksum (handled by the system)
Send Mode 20 message and receive the response Goto Class 2 Response processing Set the link to Normal Speed 10400 baud Wait 1000 milliseconds If No response was received Goto step G1 Else Look for response byte 4 in goto fields If Response Byte 4 is found Goto appropriate step Else Goto step indicated by FF goto field Endif Endif Typical Interpreter Line: Step 1F Op-Code 20 Action Fields 10 00 00 00 Goto Fields 60 20 7F 1C FF 24 00 00 00 00
Page
65
27 Op-Code: Perform Security - Mode 27

Supported By: Class 2 Interpreter 1 Description: The 27 Op-Code is used to open a control module's memory for reprogramming. The procedure number, located in Action Field one (AC1), identifies which security algorithm to use for unlocking the control module for programming. A Mode $28 (Disable Normal Communications) is sent out to all devices ($FE) prior to performing the security request (Mode $27) unless AC3 equals 01. This request is sent out as a precautionary measure to ensure that normal communications on the link has been stopped. Action Fields: AC0: AC1: AC2: AC3: Target Device ID 00 Default Security - Ones Complement ?? Production Security 00 - Not Used 01 - Do not send out a Mode $28 (Disable Normal Communications) request to all devices prior to the Mode $27. 00,02-FF - Send out the Mode $28.
Pseudo Code: XX 27 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 If AC3 is not equal to 01 (send a Disable Normal Communications request) Set the Target Device ID to $FE (All devices) Send out a Mode $28 request (Disable Normal Communications) Set the Target Device ID to AC0 Part 1 Request Seed Build Security Access message 1 as indicated in the table below Request Byte 1 2 3 4 5 6 Value 6C AC0 ## 27 01 CS Byte Description Format and type Target device ID Global source ID Security access message mode Security access request number 1 byte message checksum (handled by the system)
Send Security Access message 1 to request seed and receive response If Message 1 Response Is Positive If Message 1 Response Contains a Seed If Both Bytes of the Seed (response bytes 6 & 7) Are Zeros (controller already unlocked) Set response code to 34 Done - Goto Process Response Code Else If Security Algorithm (AC1) Not Yet Used Use specified security algorithm (AC1) to determine device's key Goto Part 2 Send Key Else Use one's complement of seed to determine device's key Goto Part 2 Send Key EndIf EndIf Else Set response code to the last response byte (byte 6) EndIf Else
Page
66
If Message 1 Response Is Negative Set response code to negative response code (last response byte) Else If No Response to Message 1 is received Set response code to NO Response (FD) Done - Goto Process Response Code Else Return with the failed error Done - Goto Process Response Code EndIf EndIf Endif
(continued)
If Security Key Was Not Determined and the Response from Message 1 reflects a Time Delay Not Expired If Message 1 Was Not Yet Sent 2 Times Wait 10 seconds (with tester present messages) Re-execute the Part 1 Request Seed logic Else Return with the failed error Done - Goto Process Response Code Endif Else Return with the failed error Done - Goto Process Response Code Endif Part 2 Send Key Build Security Access message 2 as indicated in the table below (when a Seed has been received) Request Byte 1 2 3 4 5 7 8 9 Value 6C AC0 ## 27 02 XX XX CS Byte Description Format and type Target device ID Global source ID Security access message mode Security access request number High byte of key Low byte of key 1 byte message checksum (handled by the system)
Send Security Access message 2 key response and receive response If Message 2 Response Is Positive If Response Byte 6 Is 34 (Box is now Unlocked) Set response code to 34 Done - Goto Process Response Code Else If Response Byte 6 Is 35 (Invalid Key) If Running on DPS Tool And One's Complement Not Yet Used Reset message 1 counter and try the Ones Complement Re-execute the Part 1 Request Seed logic Else Return with the failed error (Response Byte 6) Done - Goto Process Response Code Endif Else Return with the failed error (Response Byte 6) Done - Goto Process Response Code Endif Endif Else If Message 2 Response Is Negative Set response code to negative response code (Response Byte 4 = 0x7F)
Page
67
Done - Goto Process Response Code Else If No Response to Message 2 is received Set response code to NO Response (FD) Done - Goto Process Response Code Else Return with the failed error Done - Goto Process Response Code EndIf Endif Endif Process Response Code If response code Is Found Goto appropriate step indicated in the goto field Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 01 Op-Code 27 Action Fields 10 22 00 00 Goto Fields 7F 1A FD 1F FF 1F
(continued)
34 02
00 00
Page
68
28 Op-Code: Disable Normal Communications - Mode 28

Supported By: Class 2 Interpreter 1 Description: The 28 Op-Code is used to disable communications on the data link. The mode 28 message is sent to the controller at normal speed. Normal communications will resume if the link is inactive for more than five seconds. Communications will remain inhibited while tester present messages are sent out on the link at least once every five seconds. Action Fields: AC0: AC1: Target Device ID Disable Level 00 - Disable normal Class 2 communications 01 - Disable normal UART communications 00 - Not Used 00 - Not Used
AC2: AC3:
Pseudo Code: XX 28 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build Disable Communications message as indicated in the table below Request Byte 1 2 3 4 5 6 Value 6C AC0 ## 28 AC1 CS Byte Description Format and type Target device ID Global source ID Disable communication message mode Disable Level 1 byte message checksum (handled by the system)
Send Mode 28 message and get the response(s) Goto Class 2 Response Processing If No response was received Look for FD (no comm.) in goto fields If FD is found Goto appropriate step Else Goto step indicated by FF goto field Endif Else Look for response byte 4 in goto fields If Response Byte 4 is found Goto appropriate step Else Goto step indicated by FF goto field Endif Endif Typical Interpreter Line: Step 01 Op-Code 28 Action Fields 10 00 00 00 Goto Fields 7F 04 FD 1B FF 1D
68 02
00 00
Page
69
29 Op-Code: Resume Normal Communications - Mode 29 (Obsolete Use Op-Code 20)

Supported By: Class 2 Interpreter 1 - For legacy ECUs only Description: The 29 Op-Code is used to resume normal communications on the data link. The mode 29 message is sent to the controller at normal speed. Normal communications will also resume if no activity exists on the link for more than five seconds. This Op-Code will ignore the error of no response being received from the request. If this condition occurs, then Goto Step G1 will be executed. Action Fields: AC0: AC1: AC2: AC3: Target Device ID 00 - Not Used 00 - Not Used 00 - Not Used
Pseudo Code: XX 29 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build Enable Communications message as indicated in the table below Request Byte 1 2 3 4 5 Value 6C AC0 ## 29 CS Byte Description Format and type Target Device ID Global source address Enable communications message mode 1 byte message checksum (handled by the system)
Set the link to Normal Speed 10400 baud Wait 750 milliseconds Send Mode 29 message and get the response(s) Goto Class 2 Response Processing If No response was received Goto step G1 Else Look for response byte 4 in goto fields If Response Byte 4 is found Goto appropriate step Else Goto step indicated by FF goto field Endif Endif Typical Interpreter Line: Step 08 Op-Code 29 Action Fields 10 00 00 00 Goto Fields 7F 14 FF 20 00 00
69 09
00 00
Page
70
31 Op-Code: Start a Diagnostic Routine by Test Number

Supported By: Class 2 Interpreter 1 Description: The 31 Op-Code is used to execute a diagnostic test. The diagnostic routine is executed in the control module by referencing the test number in AC1. Definition of the routine is defined by the control module specification. The module must be capable of exiting the test automatically to use this Op-Code. Action Fields: AC0: AC1: AC2: AC3: Target Device ID Test Number 00 - Not used 00 - Not Used
Pseudo Code: XX 31 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build Start Diagnostic Routine message as indicated in the table below Request Byte 1 2 3 4 5 6 Value 6C AC0 ## 31 AC1 CS Byte Description Format and type Target device ID Global source ID Start diagnostic routine message mode Test number 1 byte message checksum (handled by the system)
Send Mode 31 message and get response Goto Class 2 Response Processing If No response was received Look for FD (no comm.) in goto fields If FD is found Goto appropriate step Else Goto step indicated by FF goto field Endif Else Look for response byte 4 in goto fields If Response Byte 4 is found Goto appropriate step Else Goto step indicated by FF goto field Endif Endif
Typical Interpreter Line: Step 08 Op-Code 31 Action Fields 40 22 00 00 Goto Fields 73 09 FD 12 FF 99
71 09
00 00
Page
71
34 Op-Code: Request the Control Module for Block Transfer - Mode 34

Supported By: Class 2 Interpreter 1 Description: The 34 Op-Code will build a standard mode 34 message to send to a device. A mode 34 command will prepare the device to receive executable code via block transfer from the serial data link. Mode 34 messages are used in conjunction with mode 36 (Op-Codes B0, B3, and B4) to download information to devices. The mode 34 may not be required prior to sending a mode 36 - it is device dependent. Action Fields: AC0: AC1: AC2: Target Device ID Routine number to download Exceptions: 00 - Use address and length from the routine indicated by AC1 01 - Use address and length from the utility file header 02 - Send message without transfer type or length and address information. Ignores AC1 and AC3. Transfer type
AC3:
Pseudo Code: XX 34 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 If AC2 is Not Equal to 02 Set Transfer Type to value is AC3 Else Exclude Transfer Type from Message Endif If AC2=02 Build Download Request as indicated in the table below: Request Byte 1 2 3 4 5 Value 6C AC0 ## 34 CS Byte Description Format and type Target device ID Global source ID Request download message mode 1 byte message checksum (handled by the system)
Send Mode 34 message and receive response Goto Class 2 Response Processing Goto Mode 34 Response Processing Else Find the routine indicated by value AC1 Build Download Request as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 8 9 10 11 Value 6C AC0 ## 34 AC3 XX XX XX XX XX CS Byte Description Format and type Target device ID Global source ID Request download message mode Transfer type High byte of number of data bytes Low byte of number of data bytes High byte of starting address Middle byte of starting address Low byte of starting address 1 byte message checksum (handled by the system) Page 72
If AC2=00 (Use address and length from the routine indicated by AC1) (continued) Copy high byte of routine length from the routine into message (should not exceed length in header) Copy low byte of routine length from the routine into message (should not exceed length in header) Copy high byte of RAM address to download routine (from routine) into message Copy middle byte of RAM address to download routine (from routine) into message Copy low byte of RAM address to download routine (from routine) into message Else If AC2=01 (Use address and length from the utility file header) Copy high byte of data length from the Header into the message Copy low byte of data length from the Header into the message ** Note: The data length value in the header can be changed via the $F5 Override the Utility File ** Message Length Field Op-Code. Copy high byte of data address information from the Header into the message Copy middle byte of data address information from the Header into the message Copy low byte of data address information from the Header into the message Endif AC2=00 Send Mode 34 message and receive response Goto Class 2 Response Processing Goto Mode 34 Response Processing Endif Mode 34 Response Processing If a positive response was received If AC2 = 2 (ignore transfer type, address and length information) Set the response code to response byte 5 Else Set the response code to response byte 6 Endif Else If a negative response was received Set the response code to the last response byte in the negative response message Else Set the response code to FD (no comm.) Endif Endif If the response code is 00 Goto step G1 Else Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Endif Typical Interpreter Line (ignore transfer type, address and length information): Step 10 Op-Code 34 Action Fields 10 00 02 00 44 11 Goto Fields 12 0D FD 22 FF 99 00 00
Typical Interpreter Line (use address and length information from the routine) : Step 10 Op-Code 34 Action Fields 10 03 00 01 44 11 Goto Fields 12 0D FD 22 FF 99 00 00
Page
73
3B Op-Code: Write block of memory

Supported By: Class 2 Interpreter 1 Description: The 3B Op-Code is used to download data to EEPROM using mode 3B messages. The data that is downloaded is determined by the information contained in the Action Fields. Action Fields: AC0: Target Device ID AC1: Calibration ID or Block Number being downloaded 01 - Send VIN bytes 1 5 02 - Send VIN bytes 6 11 03 - Send VIN bytes 12 17 08 - Send end model part number (Send in USN format unless AC3=03, then send in BCD format) 22 - Send Repair Shop Code bytes 1 4 23 - Send Repair Shop Code bytes 5 10 24 - Send Programming Date 5F - Send Saturn PCM Transmission Oil Life data (TOL) 62 - Send Saturn PCM engine distance counter (EDC) 6D - Send Saturn PCM Engine Oil Life data (OIL) 6E - Reset PCM P0601 Diagnostic Trouble Code Latch Indicator (Not Supported) 80 - Send Saturn PCM Adaptive data (PA2) 81 - Send Saturn PCM Transmission Adaptive data (TFL) 82 - Send Saturn PCM Transmission Adaptive data [2000-2002 Z-Car (ITN), otherwise (PA2)] 83 - Send Saturn PCM Transmission Adaptive data [Delta (B83), otherwise (ITP)] 84 - Send Saturn Transmission adaptive data for PCM or SDM keying data for BCM [PCM (DSL), otherwise (SDK or SDM)] 85 - Send Saturn BCM option data (OP3) 86 - Send Saturn BCM engine & ABS indicator [try Delta (B86), if no config. data use (OP4)] 87 - Send Saturn BCM Fault Code Enable data (FCE) 88 - Send Saturn BCM option data [Use a combination of (OP1) and (T88)] 89 - Send Saturn BCM option data [Use a combination of (T89) and (OP2)] 8E - Send Saturn PCM DVT data (DVT) A0 - Reset manufacturers enable counter [Saturn Delta and Z-car 2000-2004] A1 - Send Saturn BCM odometer setting (ODO) A2 - Send Saturn BCM SVS TT Enable Information (SV1) A3 - Send Saturn BCM option data & ODO write inhibit (SV2) A4 - Send Saturn BCM VIN bytes 1-6 [Saturn Z-car 2000-2002] or BCM DTC Enable Information [All others (DC1)] A5 - Send Saturn BCM VIN bytes 7-12 [Saturn Z-car 2000-2002] or BCM DTC Enable Information [All others (DC2)] A6 - Send Saturn BCM VIN bytes 13-17 A8 - Send Saturn BCM VTD, ODO./VIN write inhibit & Content Theft [try (BA8), if no config. data use (VTD)] A9 - Send Saturn BCM ODO (ODO) AA - Send Saturn BCM ODO (ODO) AB - Send Saturn BCM ODO (ODO) C8 - Send Saturn BCM Transmitter TIC1 (TR1) C9 - Send Saturn BCM Transmitter TIC1 (TR2) CA - Send Saturn BCM Transmitter TIC2 (TR3) CB - Send Saturn BCM Transmitter TIC2 (TR4) CC - Send Saturn BCM Transmitter TIC3 (TR5) CD - Send Saturn BCM Transmitter TIC3 (TR6) CE - Send Saturn BCM Transmitter TIC4 (TR7) CF - Send Saturn BCM Transmitter TIC4 (TR8) AC2: ## - Routine number to build into message. (See exception 04) Or ## - ID for storage location for data to write (0x00 0x13) (See exception 08)
Page
74
AC3:
Exception control action field
00 - Used to write Configuration / VIN / RSCOSN / data to a block (AC1) 01 - Used to configure a Module using the 3B mode by using data from a calibration file (AC1). Negative responses will be ignored. 02 - Used to reset (clear) all learned values associated with the data block to initial values as defined by the controller. The Block Number to reset is indicated by AC1. 03 - Used to write end model part number in binary coded decimal format. Usable option only when AC1 is 08. 04 - Used to write a routine from the utility file to a memory block, where AC2 is the routine number and AC1 is the block number. 05 - Used to configure a Module using the 3B mode by using data from a calibration file (AC1) that includes header information within the file. The header information will be skipped 12 bytes. Negative responses will be ignored. 06 - Used to configure a Module using the 3B mode by using data from a calibration file (AC1). A negative response will be processed and will halt the configuration data writing. 07 - Used to configure a Module using the 3B mode by using data from a calibration file (AC1) that includes header information within the file. The header information will be skipped 12 bytes. A negative response will be processed and will halt the configuration data writing. 08 Used to write data from a 256-byte internal storage buffer (AC2) to the block number identified in AC1.
Pseudo Code: XX 3B AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Use Ignore Class 2 Response Processing If (AC3 = 01 or AC3 = 06) See example 2 of Pseudo Code Else If AC3 = 02 See example 3 of Pseudo Code Else If AC3 = 04 See example 4 of Pseudo Code Else If (AC3 = 05 or AC3 = 07) See example 5 of Psuedo Code Else If (AC3 = 00 or AC3 = 03) See example 1 of Pseudo Code ElseIf (AC3 = 08) See example 6 of Pseudo Code Endif Endif Endif Endif Endif
Example 1:
If AC3 = 00 or AC3 = 03, build Write Block of Memory message as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 6 + N 1 6+N Value 6C AC0 ## 3B AC1 XX Byte Description Format and type Target Device ID Global source address Write block of memory mode Block number Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (maximum of 6) 1 byte message checksum (handled by the system) Page 75
XX CS
(continued) If the AC1 is set to $A4, $A5, $A6, $A8, $A9, $AA, or $AB and CAL ECU configuration data is available. Set the response code to 0x7B Else Set block number to AC1. Copy the appropriate data (see the Action Field table value descriptions above) Send 3B message and get response. If a positive or negative response was received Set the response code to Response Byte 4 Else Set the response code to FF Endif Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (AC3 = 00) Step 21 Op-Code 3B Action Fields 10 01 00 00 7B 22 Goto Fields 7F 24 FF 99 00 00 00 00
Typical Interpreter Line: (AC3 = 03) Step 21 Op-Code 3B Action Fields 10 08 00 03 7B 22 Goto Fields 7F 24 FF 99 00 00 00 00
Example 2:
If AC3 = 01 or AC3 = 06, build Write Block of Memory message as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 6 + N 1 6+N Value 6C AC0 ## 3B XX XX Byte Description Format and type Target Device ID Global source address Write block of memory mode Block number Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (maximum of 6) 1 byte message checksum (handled by the system)
XX CS
Example of Calibration: 020784226552130000078501E200000000 (must be in binary format) Block count = 02 Block 1 Len. = 07 Block 1 = 84 22 65 52 13 00 00 Block 2 Len. = 07 Block 2 = 85 01 E2 00 00 00 00 Read calibration AC1 Set Block count based on byte 1 of calibration AC1 (each calibration consists of multiple blocks) Do While Block Count > 0 Copy Block # length bytes of calibration AC1 Block # into message (maximum of 6 data bytes plus one block ID, zero fill any unused bytes in the calibration file) Send Tester Present message to all devices (0xFE) Send 3B message
Page
76
(continued) If (a negative response is received and AC3 = 06) End the Do While loop (no more data processing) Else (ignore any negative response) Endif If (no response is received) End the Do While loop Endif Subtract 1 from Block count Setup to get the next Block information (Length and Data) End While If (no response is received) Set the response code to FF Else If AC3 = 01 and all positive or negative responses were received Set the response code to 7B Else Set the response code to Response Byte 4 Endif Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 21 Op-Code 3B Action Fields 40 01 00 01 7B 22 Goto Fields FF 99 00 00 00 00 00 00
Example 3:
If AC3 = 02, build Write Block of Memory message as indicated in the table below. Request Byte 1 2 3 4 5 6 Value 6C AC0 ## 3B AC1 CS Byte Description Format and type Target Device ID Global source address Write block of memory mode Block number 1 byte message checksum (handled by the system)
Send Mode 3B message with NO data bytes and receive response. If a positive or negative response was received Set the response code to Response Byte 4 Else Set the response code to FF Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif
Page
77
(continued) Typical Interpreter Line: Step 13 Op-Code 3B Action Fields 10 83 00 02 7B 14 Goto Fields 7F 5B FF 99 00 00 00 00
Example 4:
If AC3 = 04, build Write Block of Memory message as indicated in the table below. Request Byte 1 2 3 4 5 6 6 + N 1 6+N Value 6C AC0 ## 3B AC1 XX Byte Description Format and type Target Device ID Global source address Write block of memory mode Block number Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (maximum of 6) 1 byte message checksum (handled by the system)
XX CS
Set block number to AC1. Copy all data bytes of routine AC2 (up to 6 bytes) into message. Send Tester Present message to all devices (0xFE) Send 3B message and get response. If a positive or negative response was received Set the response code to Response Byte 4 Else Set the response code to FF Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 21 Op-Code 3B Action Fields 40 B3 01 04 Goto Fields 7F 2E FF 99 00 00
7B 22
00 00
Example 5:
If AC3 = 05 or AC3 = 07, build Write Block of Memory message as indicated in the table below (contents of the XX locations is detailed in pseudo code following the table) This example is identical to Example 2 except that this usage expects a 12 byte header on the calibration data file. In this case, the operation of the data will begin at byte 13.
Page
78
(continued) Request Byte 1 2 3 4 5 6 6 + N 1 6+N Value 6C AC0 ## 3B XX XX Byte Description Format and type Target Device ID Global source address Write block of memory mode Block number Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (maximum of 6) 1 byte message checksum (handled by the system)
XX CS
Example of Calibration: 8888000100F4240041410000020784226552130000078501E200000000 (must be in binary format) Module Checksum Module ID Part Number Design Level Suffix Pad Bytes Block count Block 1 Length Block 1 Block 2 Length Block 2 = 8888 = 0001 = 00 F4 24 00 (16000000) = 41 41 (AA) = 00 00 = 02 = 07 = 84 22 65 52 13 00 00 = 07 = 85 01 E2 00 00 00 00
Read calibration AC1 Set Block count based on byte 13 of calibration AC1 (each calibration consists of multiple blocks) (skip the 12 byte header information) Do While Block Count > 0 Copy Block # length bytes of calibration AC1 Block # into message (maximum of 6 data bytes plus one block ID, zero fill any unused bytes in the calibration file) Send Tester Present message to all devices (0xFE) Send 3B message and process the response If (a negative response is received and AC3 = 07) End the Do While loop (no more data processing) Else (ignore any negative response) Endif If (no response is received) End the Do While loop (done) Endif Subtract 1 from Block count Setup to get the next Block information (Length and Data) End While If (no response is received) Set the response code to FF Else If AC3 = 05 and all positive or negative responses were received Set the response code to 7B Else Set the response code to Response Byte 4 Endif Endif Look for response code in the goto fields
Page
79
If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 21 Op-Code 3B Action Fields 40 01 00 05 7B 22 Goto Fields FF 99 00 00 00 00 00 00
(continued)
Example 6:
If AC3 = 08, build Write Block of Memory message as indicated in the table below. Request Byte 1 2 3 4 5 6 6 + N 1 6+N Value 6C AC0 ## 3B AC1 XX Byte Description Format and type Target Device ID Global source address Write block of memory mode Block number Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (maximum of 6) 1 byte message checksum (handled by the system)
XX CS
Set block number to AC1. If the storage location number (AC2) is valid Copy the data from the 256-byte storage location indicated by AC2 into the message. Note1: For the Class 2 protocol, the storage location should first be populated with the $3C OpCode for this exception to work; however, if the storage location is pre-populated with OpCode $54 or some other method, then see Note2. th Note2: The amount of data (length) stored in the storage location is located in the 7 storage buffer byte (buffer[6]). The reading/writing of data (for Class 2) can never be more than 6 data bytes. An example of 3 data bytes (0x12, 0x23, 0x34) stored in an internal storage location would be: StorageLocation: 0x12, 0x23, 0x34, 0x00, 0x00, 0x00, 0x03, . Else End with an error. Endif Send Tester Present message to all devices (0xFE) Send 3B message and get response. If a positive or negative response was received Set the response code to Response Byte 4 Else Set the response code to FF Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 21 Op-Code 3B Action Fields 10 09 04 08 Goto Fields 7F 2E FF 99 00 00
7B 22
00 00 Page 80
3C Op-Code: Read and verify block of memory

Supported By: Class 2 Interpreter 1 Description: The 3C Op-Code is used to read data from EEPROM using mode 3C messages. The data that is read is determined by the information contained in the Action Fields. The requested data can then be compared against a stored value in VIT2, however at this time only the VIN blocks 01, 02 and 03 are supported for the comparison. The success of the function is based on either the comparison (if done), or the success of the data read request (if the comparison is not done). The response data is stored in one of the 256-byte internal buffers based on the value of AC3. Action Fields: AC0: AC1: Target Device ID Block Number being read 01 - Read VIN bytes 1 5 02 - Read VIN bytes 6 11 03 - Read VIN bytes 12 17 Exceptions: 01 - Display Immobilizer Pin from data bytes 1 - 4 ID for storage location of response bytes (0x00 0x13)
AC2: AC3:
Pseudo Code: XX 3C AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Build Read Block of Memory message as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 Value 6C AC0 ## 3C AC1 CS Byte Description Format and type Target address Global source address Read block of memory mode Block number 1 byte message checksum (handled by the system)
Send Mode 3C message and receive the response If Block Number is 01 Compare the Response Data bytes 1 through 6 against 0x00 plus VIT2 VIN bytes 1 through 5 Else If Block Number is 02 Compare the Response Data bytes 1 through 6 against VIT2 VIN bytes 6 through 11 Else If Block Number is 03 Compare the Response Data bytes 1 through 6 against VIT2 VIN bytes 12 through 17 Endif Endif If the Exception Is 01 (AC2=01) Display the VTD Pin value from response data bytes 1 - 4 (BCD) Endif If a Positive response is received and the storage location number (AC3) is valid Save the data of the response starting with the first Data Byte (after the Block Number in the response) to the 256-byte storage location indicated by AC3 th FYI: The amount of data (length) stored in the storage location is located in the 7 storage buffer byte (buffer[6]). The reading/writing of data (for Class 2) can never be more than 6 data bytes. An example of 3 data bytes (0x12, 0x23, 0x34) stored in an internal storage location would be: StorageLocation: 0x12, 0x23, 0x34, 0x00, 0x00, 0x00, 0x03, . Endif
Page
81
(continued) If a VIN block comparison was successful or a response was received from a non-VIN block (01, 02, 03) Set the response code to Response Byte 4 Else If no response was received Set the response code to no comm. (FD) Else Set the response code to 05 (Comparison Failed) Endif Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 21 Op-Code 3C Action Fields 10 01 00 04 7B 22 Goto Fields 7F 24 FD 30 FF 99 00 00
Page
82
3E Op-Code: Modify Block of Memory

Supported By: Class 2 Interpreter 1 Description: The 3E Op-Code is used to read a block of data from a controller using mode 3C, change the value of a bit in an identified byte and write the entire block back to the controller using mode 3B. The target, block number to read and write, the byte number to modify and the new bit value are determined by the values in the action fields. Action Fields: AC0: AC1: AC2: AC3: Target Device ID Block Number being read and written Data byte number in the response block being (1, 2, 3,) Bit number in the identified byte being modified Defined as: High Nibble = value to set the bit(s) (1 or 0) Low Nibble = bit number to set (0 through 7) Example: AC3 = $17 set bit 7 to value of 1 AC3 = $07 set bit 7 to value of 0
Pseudo Code: XX 3E AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build Read Data Block message Request Byte 1 2 3 4 5 6 Value 6C AC0 ## 3C AC1 CS Byte Description Format and Type Target Device ID Global Source ID Read Data Block Block Number to Read 1 byte message checksum (handled by the system)
Send Mode 3C message If there is a successful read response Determine the number of data bytes received from requested block Load a temporary buffer with the response data bytes Extract the new bit value from AC3 Extract the bit to modify from AC3 Reset the byte specified in AC2 with the new bit value Build Write Data Block message Request Value Byte Description Byte 1 6C Format and Type 2 AC0 Target Device ID 3 ## Global Source ID 4 3B Write Data Block 5 AC1 Block Number to Write 6 XX Data byte 1 . The pseudo code below explains how the data portion of this . request is filled 6+N1 XX Data byte N (maximum of 6) 6+N CS 1 byte message checksum (handled by the system) Send Mode 3B message
Page
83
If there is a response to the write request (positive or negative) Set the response code to Response Byte 4 Else Set the response code to failed (FF) Endif Else (failed read request) Set the response code to failed (FF) Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 04 Op-Code 3E Action Fields 10 08 02 15 Goto Fields 7F 99 FF 99 00 00
(continued)
7B 05
00 00
Page
84
40 Op-Code: Read/Write Data Buffer

Supported By: Class 2 Interpreter 1 Description: The 40 Op-Code is used to: 1. Read data from a controller using mode 3C or 2A, 2. Save a specified number of bytes from the read 3. Send a write data block (3B) or request device control (AE) message containing the saved bytes to the same or another controller. The target device, block number/Dpid to read/write (and data rate for mode 2A) are contained in the utility file routine section. The routine number, number of bytes to read, offset into the read response and the offset into the outgoing message are determined by the action fields. The routine containing the read message data must be directly followed by the routine containing the outgoing message data. Action Fields: AC0: Routine containing read message data outgoing msg data must be located in routine ACO+1 Read Routine (AC0) Example using 2A message: Target Address Length Device 00000000 0006 10 Read Mode 2A Block/Dpid Number 02 Data Rate 01 Number of Bytes to Pad 05 Pad Value FF
Real Data Format 000000000006102A020105FF Explanation: Target device is 10 and use mode 2A to read Dpid number 02 Read Routine (AC0) Example using 3C message: Target Address Length Device 00000000 0006 10 Read Mode 3C Block/Dpid Number 02 Data Rate 00 Number of Bytes to Pad 00 Pad Value 00
Real Data Format 000000000006103C02010000 Explanation: Target device is 10 and use mode 3C to read block number 02 NOTE: Mode 3C does not use data rate Write Routine (AC0+1) Example using 3B message: Target Address Length Device 00000000 0003 40 Write Mode 3B Block/Dpid Number 8E Number of Bytes to Pad 05 Pad Value 00
Real Data Format 000000000003103B8E0500 Explanation: Target device is 40 and use mode 3B to write data to block 8E AC1: AC2: AC3: Number of bytes to save Offset into the read message (3C or 2A) first saved byte = AC2. (AC2 = 1n) Offset into the outgoing message (3B or AE) saved data put into message starting at byte AC3. (AC3 = 1n)
Pseudo Code: XX 40 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Read Routine Data based on Routine # (AC0) (Target, Read Mode, Block/DPID, # to Pad, Pad Value)
Page
85
Load the data storage buffer with value indicated in byte 6 of read routine (Pad Value) initialize (continued) Build the read message based on read Routine Data (AC0), Byte 2 (Read Mode) If the Read Mode is $3C Build Read Data Block message ($3C) Request Value Byte Description Byte 1 6C Format and Type 2 Routine Target Device ID data byte 1 3 ## Global Source ID 4 3C Read Data Block 5 Routine Block Number to Read data byte 3 6 CS 1 byte message checksum (handled by the system) Send Mode 3C message Else Build Read Diagnostic Data Packet message ($2A) Request Value Byte Description Byte 1 6C Format and Type 2 Routine Target Device ID data byte 1 3 ## Global Source ID 4 2A Read Data Block 5 Routine Data Rate data byte 4 6 Routine DPID to Read data byte 3 7 7+n-1 Routine DPID Padded values (0-5 = Number of Bytes to Pad (n) ) data byte (Routine data byte 5) 6 7+n CS 1 byte message checksum (handled by the system) Send Mode 2A message Endif If there is a successful (positive) read response Read Routine Data based on Routine # (AC0+1) (Target, Write Mode, Block/DPID, Rate, # to Pad, Pad Value) Load the data storage buffer with value indicated in byte 5 of write routine (Pad Value) initialization Load the Read data values (from $3C / $2A) into the data storage buffer for writing based on the Read and Write Offset values (AC2, AC3) Build the write message based on write Routine Data (AC0+1), Byte 2 (Write Mode) If the Write Mode is $3B Build mode 3B write message using buffer of saved bytes and padding bytes Request Value Byte Description Byte 1 6C Format and Type 2 Routine Target Device ID data byte 1 3 ## Global Source ID 4 3B Write Data Block 5 Routine Block Number to Write data byte 3
Page
86
Data = read data and any padded data n = Bytes to write indicated by AC1 + Byte 4 of write routine 6+n CS 1 byte message checksum (handled by the system) Send Mode 3B write message If there is a response to the write request (positive or negative) Set the response code to Response Byte 4 Else Set the response code to failed (FF) Endif Else Build mode AE request device control message using buffer of saved and padding bytes Request Value Byte Description Byte 1 6C Format and Type 2 Routine Target Device ID data byte 1 3 ## Global Source ID 4 AE Write Data Block 5 Routine CPID Value data byte 3 6 6+n-1 <data> Data = read data and any padded data n = Bytes to write indicated by AC1 + Byte 4 of write routine 6+n CS 1 byte message checksum (handled by the system) Send Mode AE Device Control message <data> Set the response code to Response Byte 6 If there is a positive response to the device control request If the response code is E1 Indicate success Else Indicate failure Endif Endif Endif Endif If any of the Routine Data Reads failed Set the response code to failed (FF) Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Using $3C and $3B message combination Step Op-Code Action Fields 04 40 01 01 03 02 Using $3C and $AE message combination Step Op-Code Action Fields 04 40 01 01 03 02
6 6+n-1
7B 05
Goto Fields 7F 06 FF 06 00 00
00 00
E1 05
Goto Fields E3 06 FF 06 00 00
00 00
Page
87
52 Op-Code: Write Checksum to Block 82 / 8E

Supported By: Class 2 Interpreter 1 Description: The 52 Op-Code reads a set of data blocks 01, 02, 03, 08, and (82 or 8E) using mode 3C messages to calculate a total checksum. The checksum is then appended to data block (82 or 8E) (in byte position 5) and the data is written back to the controller using a mode 3B message. Action Fields: AC0: AC1: Target Device ID 8E Substitute block number ($8E) to read / write Default Block number to read / write is $82. 00-8D, 8F-FF Use default block number ($82). 00 Not Used 00 Not Used
AC2: AC3:
Pseudo Code: XX 52 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build Read Checksum message as indicated in the table below: Request Byte 1 2 3 4 5 6 Value 6C AC0 ## 3C --CS Byte Description Format and Type Target Device ID Global Source ID Read Data Block Block number (01, 02, 03, 08, (82 or 8E)) 1 byte message checksum (handled by the system)
Set Block Number to 01 Send a mode 3C Read message for VIN bytes 1-5 and receive response If a valid response was not received, Goto Response Processing (end processing) Calculate checksum on received data bytes (6 data bytes) Set Block Number to 02 Send a mode 3C message for VIN bytes 6-11 and receive response If a valid response was not received, Goto Response Processing (end processing) Increase checksum by received data bytes (6 data bytes) Set Block Number to 03 Send a mode 3C message for VIN bytes 12-17 and receive response If a valid response was not received, Goto Response Processing (end processing) Increase checksum by received data bytes (6 data bytes) Set Block Number to 08 Send a mode 3C message for Part Number bytes 1-4 (USN) and receive response If a valid response was not received, Goto Response Processing (end processing) Increase checksum by received data bytes (4 data bytes) If AC1 = 8E Set Block Number to 8E Else Set Block Number to 82 Endif Send a mode 3C message for DVT Option bytes 1-4 and receive response If a valid response was not received, Goto Response Processing (end processing) Increase checksum by received data bytes
Page
88
Add one (1) to the checksum value Build Write Checksum message as indicated in the table below: Request Byte 1 2 3 4 5 6 7 8 9 10 11 Value 6C AC0 ## 3B --RespData1 RespData2 RespData3 RespData4 Calculated CS CS
(continued)
Byte Description Format and Type Target Device ID Global Source ID Read Data Block Block number (82 or 8E) Response Data byte #1 from the Block Read (82 or 8E) Response Data byte #2 from the Block Read (82 or 8E) Response Data byte #3 from the Block Read (82 or 8E) Response Data byte #4 from the Block Read (82 or 8E) Calculated checksum value (blocks reads 01, 02, 03, ) 1 byte message checksum (handled by the system)
Set Block Number to 01 Send a mode 3B Write message Response Processing If a response was received (positive or negative) Set the response code to response message byte 4 Else Set the response code to no response (FD) (No Comm.) Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif
Typical Interpreter Line: Step 08 Op-Code 52 Action Fields 10 00 00 00 Goto Fields 7F 42 FD 42 FF 99
7B 11
00 00
Page
89
72 Op-Code: Set Programming Voltage

Supported By: Class 2 Interpreter 1 Description: The 72 Op-Code sets the programming voltage to 17V on the DLC connector pin #??. Action Fields: AC0: AC1: AC2: AC3: ## - DLC Pin number 00 Voltage ON (Enable) 01 Voltage OFF (Clear) 00 Not Used 00 Not Used
Pseudo Code: XX 72 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 If AC1 is 00 Apply voltage to the pin based on AC0 (Pin Number) * When using Tech 2 Saturn/Catera adapter, voltage is always applied to DLC PIN #6 Else If AC1 is 01 Remove voltage from DLC pin based on AC0 (Pin Number) * When using Tech 2 Saturn/Catera adapter, voltage is removed from DLC PIN #6 Else Goto step specified in Goto field 1 (G1) (Invalid Action type AC1) Endif Endif If the Enable or Clear executes successfully Wait for 2 seconds Goto step specified in Goto field 1 (G1). Else Goto step specified in Goto field 3 (G3). Endif Typical Interpreter Line: Step 08 Op-Code 72 Action Fields 06 01 00 00 Goto Fields 00 5B 00 00 00 00
00 11
00 00
Page
90
84 Op-Code: Set Communications Parameters (Add Delay)

Supported By: Class 2 Interpreter 1 Description: The 84 Op-Code is used to add a time delay between a response from a controller and the subsequent request from the tester tool (based on utility file processing). This Op-Code is specifically designed for controllers that dont adhere precisely to the Class 2 protocol. A good example is during a calibration download, a non-compliant controller will positively respond to a block download; however, the controller is truly not ready for the next block download. So when the next block is quickly sent to the controller, the controller is not able to process it. Adding a small time delay prior to the next download will allow the controller to get ready for the next block. The "time delay" will ONLY occur for the Class 2 Transfer Data Mode $36 messages (Op-Codes $B0, $B2, $B3 and $B4). This Op-Code may be used multiple times to turn on and turn off the time delay. NOTE: GM NAO assembly plants will currently not support this Op-Code for the Class 2 protocol. If this OpCode is encountered in the assembly plant utility file, the G1 Go To will be processed. Action Fields: AC0: AC1: AC2: AC3: 01 0F: Time delay (x100 ms) between response and next request 00, 10-FF: No Time Delay Reset any previously set time delay. 00 - Not Used 00 - Not Used 00 - Not Used
If AC0 is $00 or in the range $10-$FF Turn OFF any previously set delay timer If AC0 is in the range $01-$0F Turn ON the delay timer based on a delay time of AC0 * 100ms (Time delay between an ECU response and any subsequent TESTER request) Endif Goto step specified by goto field one (G1)
Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 01 Op-Code 84 Action Fields 03 00 00 00 Goto Fields 00 00 00 00 00 00
00 02
00 00
Page
91
A0 Op-Code: Request High Speed Communications - Mode A0

Supported By: Class 2 Interpreter 1 Description: The A0 Op-Code builds a standard mode A0 message to request high speed communications. This Op-Code will not actually begin high speed communications it will only request the control module to be ready for high speed communications. To begin high speed communications an A1 Op-Code should be used. This Op-Code will ignore the error of no response being received from the request. If this condition occurs, then Goto Step G1 will be executed. Action Fields: AC0: AC1: AC2: AC3: Target Device ID 00 - Not Used 00 - Not Used 00 - Look at response byte 5 for response value 01 - Look at response byte 4 for response value
Pseudo Code: XX A0 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build Request High Speed message as indicated in the table below Request Byte 1 2 3 4 5 Value 6C AC0 ## A0 CS Byte Description Format and type Target device ID Global source ID. Request download message mode 1 byte message checksum (handled by the system)
Send Tester Present message to all devices (0xFE) Send Mode A0 message and receive response Goto Class 2 Response processing If No response was received Goto step G1 Else If AC3 = 00 Set the response code to response message byte 5 If the response code (response message byte 5) is equal to 0xBB Set the response code to 0xAA Endif Else Set the response code to response message byte 4 Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 02 Op-Code A0 Action Fields 10 00 00 00 Goto Fields FF 99 00 00 00 00
AA 03
00 00
Page
92
A1 Op-Code: Begin High Speed Communications - Mode A1

Supported By: Class 2 Interpreter 1 Description: The A1 Op-Code builds a standard mode A1 message to begin high-speed communications. After sending the request for high-speed communications the tool will delay approximately one second to ensure high speed communications has started. This Op-Code will not check for a response being received from the request (none expected). Action Fields: AC0: AC1: AC2: AC3: Target Device ID 00 - Not Used 00 - Not Used 00 - Not Used
Pseudo Code: XX A1 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build Start High Speed message as indicated in the table below Request Byte 1 2 3 4 5 Value 6C AC0 ## A1 CS Byte Description Format and type Target address Global source address Request download message mode 1 byte message checksum (handled by the system)
Send Tester Present message to all devices (0xFE) Send Mode A1 message and do not attempt to process a response (none expected). Delay for (0.6) seconds Send Tester Present message to all devices (0xFE) If the message (Begin High Speed Communications) was successfully transmitted Goto step specified in goto field 1 (G1) Else Set the response code to no response (FD) (No Comm.) (i.e. transmit failed) Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Endif Typical Interpreter Line: Step 1F Op-Code A1 Action Fields 10 00 00 00 Goto Fields FD 2C FF 99 00 00
00 20
00 00
Page
93
A8 Op-Code: GM Propriety Test Mode

Supported By: Class 2 Interpreter 1 Description: The A8 Op-Code builds a standard mode A8 message and is a GM Propriety Test Mode not to be disclosed outside the Company. NOTE: This Op-Code is NOT functional within the software application. The response processing will be based on GOTO field G1.
Page
94
AE Op-Code: Request Device Control - Mode AE

Supported By: Class 2 Interpreter 1 Description: The AE Op-Code will build a standard mode AE message to send to a device. A mode AE command will allow a test device to control functions that the device has normal software control over. *NOTE: See General Motors Class 2 Physical Message Diagnostic Strategy Specification document. Action Fields: AC0: AC1: AC2: AC3: Target Device ID CPID number Routine Number to build into message Not Used
Pseudo Code: XX AE AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Find the routine indicated by value AC2 and read the data from the routine Build Download Request as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Value Byte Description Byte 1 6C Format and type 2 AC0 Target device ID 3 ## Global source ID 4 AE Request download message mode 5 AC1 CPID Number 6 XX 1st byte of routine (AC2) The pseudo code below explains how the data portion of this request is filled 6+N XX Data byte N (maximum of 6) 6+N+1 CS 1 byte message checksum (handled by the system) Copy length bytes of routine AC2 into message (should not exceed length of 6 and some controllers may require 6 - zero fill if necessary within the routine) Send Mode AE message and receive response Set the response code to the sixth byte of the response data If a positive response was received (EE) and the sixth byte is E1 Mode AE PASSED Else Mode AE FAILED Endif Send Tester Present message to all devices (0xFE) Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 10 Op-Code AE Action Fields 10 03 02 00 E1 11 Goto Fields E4 0D FF 99 00 00 00 00 Page 95
B0 Op-Code: Block Transfer to RAM and Execute - Mode 36

Supported BY: Class 2 Interpreter 1 Description: The B0 Op-Code is used to build a mode 36 message for downloading a routine to control module RAM. Depending on the product being programmed this Op-Code may need to be preceded by a mode 34 message (see Op-Code 34 ). Using the exceptions described, the utility controls when the code downloaded to RAM is executed. The B0 Op-Code uses the global source device ID for all messages. If a source device ID other than the current source device ID needs to be used, the Interpreter instructions should contain a 01 Op-Code prior to this Op-Code. Action Fields: AC0: AC1: AC2: AC3: Target Device ID Routine number to download Not used Exceptions 00-03. The RAM download address is determined from the routine section. 00 - Download routine and receive completion response but DO NOT execute 01 - Download routine and receive completion response then send separate execute message - The execute message will contain NO data bytes and also NO address information. 02 - Send execute message with zero length and with the address of the indicated routine 03 - Send routine with transmit type of execute Exceptions 80-83. The RAM download address is determined from the routine section. 80 - Download routine and receive completion response but DO NOT execute 81 - Download routine and receive completion response then send separate execute message - The execute message will contain NO data bytes and will have the address information. 82 - Send execute message with zero length and with the address of the indicated routine 83 - Send routine with transmit type of execute
*Note: A prolog and routine are both contained within the routine section of utility file; however, they are different. The prolog is a value that precedes each packet of information. With a routine, the data is downloaded to the controller only once. A prolog would remain constant during the downloading of a routine. (The Class 2 protocol uses routines. Use of prologs in Class 2 is not currently supported as it is not required.) Pseudo Code: XX B0 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Find the routine indicated by value AC1 Build Download message as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 8 9 10 11 11 + N Value 6D AC0 ## 36 XX XX XX XX XX XX XX Byte Description Format and type Target device ID Global source ID Request download message mode Transfer type High byte of number of data bytes Low byte of number of data bytes High byte of starting address Middle byte of starting address Low byte of starting address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N Page 96
(continued) 12 + N 13 + N High byte of checksum Low byte of checksum
If this Message is Strictly Download Without Execution on Completion (AC3 = 0x00, 0x01, 0x80, 0x81) Set transfer type to 00 for download only (Byte 5 of Class 2 message) Else Set transfer type to 80 for download and execute (Byte 5 of Class 2 message) Endif Set the address bytes (for the mode $36 message) based on the routine address information. If the address information is 0xFFFFFFFF No address information will be included in the mode $36 message (Bytes 8, 9, 10 will be removed from the message) Endif If this Message is Strictly Execute with No Data Being Sent (AC3 = 0x02, 0x82) Set the length bytes (for the mode $36 message) to zero Set the data bytes (for the mode $36 message) to NULL (no data) Else Set the length bytes (for the mode $36 message) based on the routine length information Set the data bytes (for the mode $36 message) based on the routine data Endif Calculate the checksum for the message buffer Copy the two byte checksum to the end of the message buffer Send Tester Present message to all devices (0xFE) Send the mode $36 message and expect a response If the Response to the Above Message is a Success (0x76 .. 0x65 or 0x76 .. 0x73 or 0x76 .. 0x86) If this is a Download Then Send a Separate Message (AC3 = 0x01, 0x81) Build Download message as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table (Length of 0x00, NO data bytes, transfer type is execute (0x80)) Request Byte 1 2 3 4 5 6 7 8 9 10 11 12 Value 6D AC0 XX 36 80 00 00 XX XX XX CS CS Byte Description Format and type Target device ID Global source ID Request download message mode Transfer type High byte of number of data bytes Low byte of number of data bytes High byte of starting address Middle byte of starting address Low byte of starting address High byte of checksum Low byte of checksum
If the Exception is 0x81 (AC3 = 01) Set the address bytes (for the mode $36 execute message) based on the routine address Else No address information will be included in the mode $36 message (Bytes 8, 9, 10 will be removed from the message) Endif Calculate checksum for message buffer Copy high byte of checksum into the end of the message buffer Copy low byte of checksum into the end of the message buffer Send the execute only message and expect a response Endif Endif
Page
97
If a positive response was received (0x76) Set the response code to the sixth byte of the response Else If a negative response (0x7F) was received Set the response code to the fourth byte of the response Else If no response was received Set the response code to 0xFD (No Comm. Response) Else Set the response code to the sixth byte of the response Endif Endif Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 10 Op-Code B0 Action Fields 10 01 00 81 Goto Fields 62 0D FD 20 7F 49
(continued)
65 11
FF 49
Page
98
B2 Op-Code: Block Transfer to RAM and Save Two Byte Response - Mode 36
Supported By: Class 2 Interpreter 1 Description: The B2 Op-Code is used to build a mode 36 message for downloading a routine to control module RAM. Depending on the product being programmed this Op-Code may need to be preceded by a mode 34 message (see Op-Code 34). Using the exceptions the utility controls when the code downloaded to RAM is executed. The B2 Op-Code is functionally equivalent to the B0 Op-Code except two bytes are saved from the response (checksum). The B2 Op-Code uses the global source device ID for all messages. If a source device ID other than the current source device ID needs to be used, the Interpreter instructions should contain a 01 Op-Code prior to this Op-Code. Note: This OpCode uses the 2-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage Action Fields: AC0: AC1: AC2: AC3: Target Device ID Routine number to download ID for storage location of two response bytes (0x00 0x13) Exceptions 00-03. The RAM download address is determined from the routine section. 00 - Download routine and receive completion response but DO NOT execute 01 - Download routine and receive completion response then send separate execute message - The execute message will contain NO data bytes and also NO address information. 02 - Send execute message with zero length and with the address of the indicated routine 03 - Send routine with transmit type of execute Exceptions 80-83. The RAM download address is determined from the routine section. 80 - Download routine and receive completion response but DO NOT execute 81 - Download routine and receive completion response then send separate execute message - The execute message will contain NO data bytes and will have the address information. 82 - Send execute message with zero length and with the address of the indicated routine 83 - Send routine with transmit type of execute
Pseudo Code: XX B2 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Process the Op-Code $B0 pseudo code logic. If the response to the $36 message(s) is a Success (0x76 .. 0x65 or 0x76 .. 0x73 or 0x76 .. 0x86) Save two bytes from the response to internal local storage ID indicated by AC2 (bytes 7 & 8 of response are saved) Endif Look for response code in the goto fields (see Op-Code $B0 pseudo code) If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 10 Op-Code B2 Action Fields 10 04 05 01 Goto Fields 62 0D FD 20 7F 49
65 11
FF 49
Page
99
B3 Op-Code: Block Transfer to Download VIN as a Calibration - Mode 36

Supported By: Class 2 Interpreter 1 Description: The B3 Op-Code is used to build a mode 36 message for downloading the VIN to a control module. The VIN is packaged in a block transfer message as if it were another calibration file. Depending on the product being programmed this Op-Code may need to be preceded by a mode 34 message (see Op-Code 34). The B3 Op-Code uses the global source address for all messages. If a source address other than the current source address needs to be used the Interpreter instructions should contain a 01 Op-Code prior to this OpCode. Action Fields: AC0: AC1: AC2: AC3: Target Device ID Block ID to include in block transfer for VIN 00 - Not Used 00 - Not Used (exceptions)
Pseudo Code: XX B3 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build Download message as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 8 9 10 11 11 + N 12 + N 13 + N Value 6D AC0 ## 36 00 00 20 XX XX XX XX Byte Description Format and type Target device ID Global source ID Request download message mode Transfer type High byte of number of data bytes Low byte of number of data bytes High byte of starting address Middle byte of starting address Low byte of starting address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N High byte of checksum Low byte of checksum
XX CS CS
The length (number of data bytes for the mode $36 message) is set to 32 decimal (0x0020). Set the address bytes (for the mode $36 message) based on the utility file address information. Calculate ones complement checksum for VIN bytes and calibration ID byte Copy the high byte of ones complement checksum into data byte 1 Copy the low byte of ones complement checksum into data byte 2 Copy zero into data byte 3 as the high byte of the VIN calibration ID Copy AC1 (Block ID) into data byte 4 as the low byte of the VIN calibration ID Copy the VIN data into message buffer starting at data byte 5
Page
100
Calculate the checksum for the entire (Mode $36) message buffer Copy the two byte checksum to the end of the message buffer Send Tester Present message to all devices (0xFE) Send the mode $36 message and expect a response
(continued)
If the response to the $36 message(s) is a Success (0x76 .. 0x65 or 0x76 .. 0x73 or 0x76 .. 0x86) Set the response code to the sixth byte of the response Else If a negative response (0x7F) was received Set the response code to the fourth byte of the response Else If no response was received Set the response code to 0xFD (No Comm. Response) Else Set the response code to the sixth byte of the response Endif Endif Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 08 Op-Code B3 Action Fields 10 02 00 00 Goto Fields FD 12 7F 4A FF 4A
65 09
00 00
Page
101
B4 Op-Code: Block Transfer to Download Calibration File - Mode 36

Supported By: Class 2 Interpreter 1 Description: The B4 Op-Code is used to build a mode 36 message for downloading a calibration file (or software) to a control module. Depending on the product being programmed this Op-Code may need to be preceded by a mode 34 message (see Op-Code 34 ). The exception value (AC3) will allow the B4 Op-Code to support slightly different processing without having to create unique Op-Codes. Currently exception 0 should be used to download files to a 95 VCM-XA and exception 1 to download a car platform control module. (See pseudo code for exception descriptions.) The B4 Op-Code uses the global source address for all messages. If a source address other than the current source address needs to be used the Interpreter instructions should contain a 01 Op-Code prior to this OpCode. If the GlobalHeaderLength value (OpCode $F3) is not zero then the downloading of the module will be separated into two parts with the GlobalHeaderLength number of bytes will be downloaded first, followed by the remaining calibration data. The default GlobalHeaderLength value is zero. Caution: The message data length value in the Utility File header can be over-written via the $F5 Override the Utility File Message Length Field Op-Code. (See the $F5 Op-Code for specifics.) Action Fields: AC0: AC1: AC2: AC3: Target Device ID Calibration ID for Calibration to Download Value of the routine number (taken from routine section of utility file) Exceptions: 00 - This option downloads each packet with a transmit type of download only. The calibration download data packet size is obtained from the utility file header. The RAM download address is obtained from the utility file header. This option uses the same download address for each data packet downloaded. Uses 3-byte addressing. If the last piece of data to download is less than the packet size, then the missing data is padded with 0x00 data. For examples of how this exception works see reprogramming specifications for the 1995 VCM-XA or the 1996 PCM-32U. 01 - This option downloads each packet with a transmit type of download & execute. The Mode $36 message contains routine data from the routine (AC2) that precedes each calibration packet data from the calibration file (AC1). The calibration download data packet size is obtained from the utility file header. The RAM download address is determined from the routine section (prolog). The download packet address is obtained from the utility file header and is incremented by the packet size after each download. Uses 2-byte download packet addressing. If the last piece of data to download is less than the packet size, then the packet length will adjusted to the actual number of remaining bytes to send (no padding with 0x00 data). For examples of how this exception works see reprogramming specifications for the 1996 PCM-66U. 02 - Follows the same logic as exception 01 with the exception of: Uses 3-byte download packet addressing. 03 - Follows the same logic as exception 00. 04 - Follows the same logic as exception 00 or 03 with the exception of: The download address will be incremented by the packet size after each download. If the last piece of data to download is less than the packet size, then the packet length will adjusted to the actual number of remaining bytes to send (no padding with 0x00 data).
*Note: A prolog and routine are both contained within the routine section of utility file; however, they are different. The prolog is a value that precedes each packet of information, which could be a routine that is downloaded. With a routine, the data is downloaded to the controller only once. A prolog would remain constant during the downloading of a routine.
Page
102
Pseudo Code: XX B4 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
(continued)
Find the calibration with ID of AC1 Set the packet length to number of data bytes in a message value in the Utility File header Note: ** The message data length value in the Utility File header can be over-written via the $F5 ** Override the Utility File Message Length Field Op-Code. Build Download message as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 8 9 10 11 11 + N 12 + N 13 + N Value 6D AC0 ## 36 XX XX XX XX XX XX XX Byte Description Format and type Target device ID Global source device ID Request download message mode Transfer type High byte of number of data bytes Low byte of number of data bytes High byte of starting address Middle byte of starting address Low byte of starting address Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N High byte of checksum Low byte of checksum
XX CS CS
If the Exception is Zero, Three or Four (AC3=00, AC3=03 or AC3=04) Set the transfer type to 0x00 (Download Only) Set the download message number of data bytes (2 bytes) based on the packet length Set the download message address bytes (3 byte addressing) based on the utility file address Note: The data bytes based on the calibration data (dynamic) Else (AC3=01 or AC3=02) Set the transfer type to 0x80 (Download and Execute) Find the routine section indicated by value in AC2 Set the download message number of data bytes (2 bytes) based on the packet length + the routine length + length size* + address size** * The length size for the calibration packet data (2 bytes) ** The address size for the calibration packet data is (2 bytes if AC3=02 or 3 bytes if AC3=01) Set the download message address bytes (2 or 3 bytes***) based on the routine address ** The number of address bytes is 2 if AC3=02. The number of address bytes is 3 if AC3=01. Note: The data bytes are based on the routine data (static) and the calibration data (dynamic) Endif Do while more calibration data to download If the GlobalHeaderLength is not 0 (download the calibration file into 2 parts header first) Set the Packet & Data length values based on the GlobalHeaderLength Decrement the GlobalHeaderLength by the number of header bytes to download Endif
Page
103
If this is the last packet of a file to download (continued) If (AC3=01, AC3=02 or AC3=04) Change the packet size and download message length values based on the amount of data remaining Copy the remaining data into the message buffer Else Copy the remaining data into the message buffer and PAD with 0x00 Endif Else Copy the next block of data into the message buffer Endif Calculate the checksum for the entire (Mode $36) message buffer Copy the two byte checksum to the end of the message buffer Send Tester Present message to all devices (0xFE) Send the mode $36 message and expect a response If an error occurred End the calibration download Endif If the Exception is One (AC3=01) Calculate next calibration download address and copy into address position of message (2 bytes) Else If the Exception is Two (AC3=02) Calculate next calibration download address and copy into address position of message (3 bytes) Else If the Exception is Four (AC3=04) Calculate the next Mode $36 message address (increment the address based on the packet size) Endif If an error occurred End the calibration download Endif END Do-While processing If the response to the last $36 message(s) is a Success (0x76 .. 0x65 or 0x76 .. 0x73 or 0x76 .. 0x86) Set the response code to the sixth byte of the response Else If a negative response (0x7F) was received Set the response code to the fourth byte of the response Else If no response was received Set the response code to 0xFD (No Comm. Response) Else Set the response code to the sixth byte of the response Endif Endif Endif Look for response code in the goto fields If the response code is found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: Step 19 Op-Code B4 Action Fields 10 04 00 00 Goto Fields 80 0D FD 20 7F 28
86 26
FF 28
Page
104
Interpreter 2 KWP2000 Communications Programming Op-Codes
Page
105
KWP2000 No Communications Processing

Supported By: KWP2000 Interpreter 2 Description: Normal processing of no communications conditions is to re-send the request up to three times then fail with a no comm. fault if a response isn't received. When writing instructions for a Utility File the FD code can be used to determine the next step to execute after a no comm. fault occurs. The 'FD' processing can be used for any step in the utility file where a no comm. condition can occur. Pseudo Code: XX OP AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
If no comm. occurred Check goto fields for an FD return code (G0, G2, G4, G6, or G8) If found Flag appropriate step to execute next and return Else Check goto fields for an FF return code (G0, G2, G4, G6, or G8) If found Flag appropriate step to execute next and return Else End programming with fatal error Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 28 Op-Code OP Action Fields B4 03 10 00 Goto Fields FD 12 FF 4A 00 00
65 2A
00 00
Page
106
KWP2000 Response Processing

Supported By: KWP2000 Interpreter 2 Description: If a ECU doesn't respond (timeout) then No Communication Processing applies. If a negative response is received, then the tool searches for the response code (byte 3) of the received negative response in the goto fields and if found flags the appropriate step to execute next. In all other cases, the tool searches for the positive response service ID in the goto fields. When an Op-Code refers to the response buffer the bytes are identified as follows: Positive Response: Response Byte 1 n Value XX XX Byte Description Positive Response Service ID Byte n (where n <= 255)
Negative Response: Response Byte 1 2 3 Value 7F XX XX Byte Description Negative Response Service ID Request Service ID Response Code
Pseudo Code: XX OP AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Get response for the request If a timeout occurred Goto No Communication Processing Endif If a negative response service ID is returned (negative response service ID $7F) If the negative response code = expected positive response service ID plus $40) Set 7f-special process flag **(see details below) Endif Return negative response Else Return positive response Endif
** Special Case 7F processing:

If the service request has a negative response code that is the same as an expected positive response message response service ID plus $40: The 7f-special-process flag will be set. The Interpreter shall look for the second occurrence of the response code in the goto fields to determine the next Interpreter step. As indicated in the example below the second occurrence of the response code can occur anywhere in the remaining goto fields (note: For clarity, it is recommended that the duplicate response code goto fields be on the first line and not separated as on a continuation line using the F8 continuation OpCode).
Page
107
(continued) If the response code is not found in the goto fields then the $FF goto will be used to determine the next Interpreter step. If the service request has a negative response code that is NOT the same as an expected positive response message response service ID plus $40: The Interpreter shall look for the FIRST occurrence of the response code in the goto fields to determine the next Interpreter step. If the response code is not found in the goto fields then the $FF goto will be used to determine the next Interpreter step.
Developers Note: This processing puts the requirement for the Interpreter into the hands of the developers who know what response codes are possible for a particular service request. When a developer is writing the Interpreter instructions the need for duplicate goto fields will be obvious and should not present any problems. Negative response processing Utility File Example and Pseudo Code Following is the message structure and utility line for pseudo code example below.
PositiveResponse
ServiceID $77
RequestMessage
ServiceID $37
NegativeResponse
ResponseID $7F Step 12 Op-Code 37 AC0 00 AC1 00 AC2 00 AC3 00
RequestID $37 G0-G1 77-1B G2-G3 41-17
ResponseCode $77 G4-G5 72-17 G6-G7 77-18 G8-G9 FF-15
If a PositiveResponse is received (ResponseServiceID is RequestMessageServiceID + $40). Use the first occurrence of the PositiveResponseServiceID ($77) to determine next step. (For this example the next step is Step 1B. ) Else a NegativeResponse was received (ResponseServiceID is $7F). If the NegativeResponseResponseCode equals the RequestMessageServiceID + $40. Use the second occurrence of ResponseCode ($77), or the $FF Goto field if only one occurrence of ResponseCode ($77) is found, to determine next step. (For this example the next step is Step 18.) Else. Use the ResponseCode to determine the next step. (For Response Code $41 in this example, the next step is Step 17.) Endif. Endif.
Page
108
01 Op-Code: Setup KWP2000 Programming (Target and Source Bytes)

Supported By: KWP2000 Interpreter 2 Description: The 01 Op-Code is used to set the global variables that are used during the programming process. The OpCode allows the user to alter the global settings any time during the programming event by issuing another 01 Op-Code. AC0 is used to set a global application variable that is used in all message for the Target Byte. The default Target Byte is $11. AC1 is used to set a global application variable that is used in all message for the Source Byte. The default Source Byte is $F1. Action Fields: AC0: AC1: AC2: AC3: Global Target Byte Global Source Byte $00 - Not used Exceptions: $00 - Not used
If AC0 is not equal to zero Set global target byte to value in AC0 Endif If AC1 is not equal to zero Set global source byte to value in AC1 Endif Goto step specified by goto field one (G1) Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 01 Op-Code 01 Action Fields 12 F0 00 00 Goto Fields 00 00 00 00 00 00
00 02
00 00
Page
109
03 Op-Code: Set Number of Repetitions

Supported By: KWP2000 Interpreter 2 Description: The 03 Op-Code is used to set the number of message repetitions in case of no response. If e.g. a value of 2 is used there are 2 repetitions making a sum of 3 request going out before a No Communication situation is reported. If this Op-Code is not used the number of repetitions defaults to 2. Action Fields: AC0: AC1: AC2: AC3: Number of repetitions $00 - Not used $00 - Not used $00 - Not used
Goto step specified by goto field one (G1) Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 06 Op-Code 03 Action Fields 00 00 00 Goto Fields 00 00 00 00 00 00
01
00 07
00 00
Page
110
10 Op-Code: SR 10 to Start Diagnostic Session

Supported By: KWP2000 Interpreter 2 Description: The 10 Op-Code is used to start a programming diagnostic session. Action Fields: AC0: AC1: Diagnostic mode Baud Rate Identifier $00 - Not used $01 9600 Baud $02 19200 Baud $03 38400 Baud $04 57600 Baud $05 115200 Baud $00 - Not used Exceptions: $00 - Not used
AC2: AC3:
Use KWP2000 Normal Response processing Build Start Diagnostic Session Request as indicated in the table below If (AC1 == 0) Request Byte 1 2 3 4 5 6 7 Value 80 ## ## 02 10 AC0 CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Start routine by local ID request service ID Diagnostic mode 1 byte message checksum
If (AC1 >= $01) & (AC1 <=$05) Request Byte 1 2 3 4 5 6 7 8 Value 80 ## ## 02 10 AC0 AC1 CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Start routine by local ID request service ID Diagnostic mode Baud rate Identifier 1 byte message checksum
Calculate checksum and copy into service request (byte 7) Send Start Diagnostic Session Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Start Diagnostic Session positive response is received Switch to baud rate specified by AC1
Page
111
(continued) Look for Start Diagnostic Session positive response service ID ($50) in goto fields Else Look for Start Diagnostic Session negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 10 Action Fields 00 00 00 00 Goto Fields FF 2D 00 00 00 00
50 11
00 00
Page
112
11 Op-Code: SR 11 ECU Reset

Supported By: KWP2000 Interpreter 2 Description: The 11 Op-Code is used to issue an ECU Reset Service Request. Action Fields: AC0: AC1: AC2: AC3: Reset mode $00 - Not used $00 - Not used Exceptions: $00 - Not used
Use KWP2000 Normal Response processing Build ECU Reset Service Request as indicated in the table below Request Byte 1 2 3 4 5 6 7 Value 80 ## ## 02 11 AC0 CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) ECU Reset service ID Reset mode 1 byte message checksum
Calculate checksum and copy into service request (byte 7) Send ECU Reset Service Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If ECU Reset Service positive response is received Look for ECU Reset Service positive response service ID ($50) in goto fields Else Look for ECU Reset Service negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 11 Action Fields 01 00 00 00 Goto Fields FF 2D 00 00 00 00
51 11
00 00
Page
113
14 Op-Code: SR 14 Clear Diagnostic Trouble Codes

Supported By: KWP2000 Interpreter 2 Description: The 14 Op-Code is used to issue a Clear DTCs Service Request. The group of diagnostic information selects which DTCs shall be cleared. The below values are defined in the document "SAE Recommended Practice J2012" section "Diagnostic Trouble Codes" Group of diagnostic information $0000 $0001 - $3999 $4000 $4001 - $7999 $8000 $8001 - $B999 $C000 $C001 - $C999 $FF00 Action Fields: AC0: AC1: AC2: AC3: Group of diagnostic information (high byte) Group of diagnostic information (low byte) $00 - Not used Exceptions: $00 Not used Description All powertrain DTCs Specific powertrain DTCs All chassis DTCs Specific chassis DTCs All body DTCs Specific Body DTCs All undefined DTCs Specific undefined DTCs All DTCs
Use KWP2000 Normal Response processing Build Clear DTCs Service Request as indicated in the table below Request Byte 1 2 3 4 5 6 7 7 Value 80 ## ## 03 14 AC0 AC1 CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Clear DTCs service ID Group of diagnostic information (high byte) Group of diagnostic information (low byte) 1 byte message checksum
Calculate checksum and copy into service request (byte 7) Send Clear DTCs Service Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If ECU Reset Service positive response is received Look for ECU Reset Service positive response service ID ($50) in goto fields Else Look for ECU Reset Service negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 2E Op-Code 14 Action Fields FF 00 00 00 Goto Fields 54 2F FF 33 00 00 00 00 00 00
Page
114
20 Op-Code: SR 20 to Stop Diagnostic Session

Supported By: KWP2000 Interpreter 2 Description: The 20 Op-Code is used to stop a programming diagnostic session. Action Fields: AC0: AC1: AC2: AC3: $00 - Not used $00 - Not used $00 - Not used Exceptions: $00 - Not used
Use KWP2000 Normal Response processing Build Stop Diagnostic Session Request as indicated in the table below Request Byte 1 2 3 4 5 6 Value 80 ## ## 01 20 CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Start routine by local ID request service ID 1 byte message checksum
Calculate checksum and copy into service request (byte 6) Send Stop Diagnostic Session Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Stop Diagnostic Session positive response is received Switch to default baud rate (10400Bd) Look for Stop Diagnostic Session positive response service ID ($60) in goto fields Else Look for Stop Diagnostic Session negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 20 Action Fields 00 00 00 00 Goto Fields FF 3D 00 00 00 00
60 11
00 00
Page
115
23 Op-Code: SR 23 to Read Memory by Address and Save Bytes

Supported By: KWP2000 Interpreter 2 Description: The Op-Code 23 will build a standard service request 23 to send to an ECU. This Op-Code is used to read a specified number of data bytes from a specified memory address and save them. The address and size information for the service request either comes from a routine in the Utility File or from the global address and length information set by Op-Code F1 and F2, response. If the value in Action field 0 (AC0) is $00 the global address and length information is used, otherwise the routine information is used. The value in Action Field 2 (AC2) is the ID of the storage location for a 2-byte buffer or a 256-byte buffer. The valid IDs for both types are 0x00 thru 0x13. The value in Action Field 1 (AC1) specifies whether a 2-byte or a 256-byte buffer shall be used. For details on how to use these features see the Action Fields and the Pseudo Code. Note: This OpCode uses either the 2-byte or the 256-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage Action Fields: AC0: $00 Get memory address from global address information set by Op-Code $F1 and memory size from global length information set by Op-Code $F2 $XX Routine number from Utility File to get memory address and memory size from $00 Use 2-byte buffer $01 Use 256-byte buffer ID of storage location (either 2-byte or 256-byte buffer) (0x00 0x13) Exceptions: $00 Not used
AC1: AC2: AC3:
Use KWP2000 Normal Response processing Build Start Routine by Address Request as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 8 9 10 Value 80 ## ## 5 23 XX XX XX XX CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Read Memory by Address request service ID High byte of address Middle byte of address Low byte of address Memory size 1 byte request checksum
If AC0 is equal to $00 Copy the global address into request starting at byte 6 Copy the global length (low byte) into request starting at byte 9 Else Find the routine indicated by the value in AC0 Copy the routine address into request starting at byte 6 Copy the routine length (low byte) into request starting at byte 9 Endif Calculate checksum and copy into service request byte 10 Send Read Memory By Address Request and receive response
Page
116
(continued) Goto KWP2000 Response Processing If Read Memory By Address positive response is received If AC1 is equal to $00 If no data bytes received Set high byte of storage location identified by AC2 to 0 Set low byte of storage location identified by AC2 to 0 Else if 1 data byte received Copy data byte to high byte of storage location identified by AC2 Set low byte of storage location identified by AC2 to 0 Else Copy 1.data byte to high byte of storage location identified by AC2 Copy 2.data byte to low byte of storage location identified by AC2 Else Clear 256-byte data buffer identified by AC2 Copy over as many data bytes as received into data buffer identified by AC2 (max. 256) Look for Read Memory By Address Request positive response service ID ($63) in goto fields Else Look for Read Memory By Address Request negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 23 Action Fields 03 00 03 00 Goto Fields 10 0D FF 99 00 00
63 11
00 00
Page
117
27 Op-Code: SR 27 for Security Access Request

Supported By: KWP2000 Interpreter 2 Description: The 27 Op-Code is used to open an ECU's memory for reprogramming. The value in Action Field zero (AC0), identifies which security algorithm to use for unlocking the ECU for programming. The security algorithm defines the functions that are performed on the seed to determine the ECU key. A response code of 37 indicates that the security access time out has not expired. When a $37 is received the Interpreter delays approximately 2 seconds then retries the security request. The Interpreter repeats the looping process for 5 tries or approximately 10 seconds. If security fails for "Invalid Key - $35" the Interpreter will retry the entire security process (starting with request 1) using the ones complement security algorithm. This provides a means to program development ECUs using a production Utility File. Action Fields: AC0 AC1 AC2 $00 - Default Security Algorithm (One's Complement) $01 to $FE are Production Security Algorithms $00 Don't send key if seed is 0 (according to specification) $01 Send key even if seed is 0 $00 GM Security Algorithm, Security Key Calculation in Server Application (exchanged via VIT 2) $01 Not implemented: GM Security Algorithm, Security Key Calculation in VCS $02 Not implemented: Non GM Security Algorithm, Security Key Calculation in Server Application (exchanged via VIT 2) $03 Non GM Security Algorithm, Security Key Calculation in VCS Exceptions: $00 - Security level 1 (level $01 and $02 get seed/send key) $01 - Security level 3 ( DVT level $03 and $04 DVT get seed/send key) $XX Security level (2*XX + 1) Example : $7D = security level $FB ($FB and $FC get seed/send key)
AC3
Use KWP2000 Normal Response processing Build Security Access Request 1 as indicated in the table below Request Byte 1 2 3 4 5 6 7 Value 80 ## ## 02 27 ## CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Security access request service ID AC3 (1) Access mode - if AC3 = 0, this byte would be 1, if AC3 = 1, this byte would be 3, a. s. o.. 1 byte message checksum
Calculate checksum and copy into service request (byte 7) Send Security Access Request AC3 (1) for request seed and receive response (up to 10 Bytes) Goto KWP2000 Response Processing
Page
118
(continued) If Security Access positive response AC3 (1) is received If both bytes of the seed (Security Access positive response bytes 3 & 4) are zeros and AC1 isn't 1 Set Security Access positive response service ID to success ($34) Indicate Security Access positive response received do not second Security Access Request AC3 (2) Else Use security algorithm corresponding to AC0 to determine ECU's key Build Security Access request AC3(2) as indicated in the table below Request Byte 1 2 3 4 5 6 7 8 9 Value 80 ## ## 04 27 ## XX XX CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Security access request service ID AC3 (2) Access mode - if AC3 = 0, this byte would be 2, if AC3 = 1 this byte would be 4, a. s. o. High byte of key Low byte of key 1 byte message checksum
Calculate checksum and copy into service request (byte 9) Send Security Access Request AC3 (2) for send key and receive response (up to 10 Bytes) Goto KWP2000 Response Processing Endif If Security Access positive response AC3 (2) is received Look for Security Access positive response (AC3) service ID ($34) in goto fields Else If Security Access negative response "Invalid Key - $35" is received Repeat entire security process using ones complement security algorithm If security still fails for "Invalid Key - $37" and ones complement was used Look for Security Access negative response AC3 (2) response code ($35) in goto fields Endif Else Look for Security Access negative response AC3 (2) response code in goto fields Endif Endif Else If Security Access negative response "Time Delay not Expired - $37" is received If ten second timer has not expired Delay 2 seconds Retry entire security process Else Look for Security Access negative response AC3 (1) response code ($37) in goto fields Endif Else Look for Security Access negative response AC3 (1) response code in goto fields Endif Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all action and goto fields are hex numbers) Step 02 Op-Code 27 Action Fields 00 00 00 Goto Fields 37 13 FF 22 00 00
01
34 03
00 00 Page 119
30 Op-Code: SR 30 to Input/Output Control by Local Identifier

Supported By: KWP2000 Interpreter 2 Description: The 30 Op-Code will build a standard service request $30 to send to an ECU. A Service Request $30 is used for input/output control by local identifier. This Op-Code also supports the option to pass in Control Options from a Data Routine. For details on how to use this feature see the Action Fields and the Pseudo Code. The routine that contains the Control Options should be formatted with a zero load address and a valid length (see description of Data Routines). The data portion of the routine should only contain the Control Options to include in the request with no additional data. Action Fields: AC0: AC1: AC2: AC3: XX 30 Input/Output Local Identifier Routine number from Utility File to use as Control Options in the Service Request 30 (Shall be $00 if not used) $00 - Not used Exceptions: $00 - Not Used AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Pseudo Code: Use KWP2000 Normal Response processing Build Input/Output Control by Local ID Request as indicated in the table below Request Byte 1 2 3 4 5 6 7+N Value 80 ## ## 2+N 30 AC0 Control Options to Pass CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Start routine by local ID request service ID Routine local ID for routine to begin executing Data from routine indicated by value in AC1. Number of bytes (N) is 1 to 253. For no Control Options AC1 = 0, and N = 0.
1 byte message checksum
If AC1 is not $00 Find routine indicated by value in AC1 to include in request as Control Options Copy entire Data Routine into request starting at byte 7 Endif Calculate checksum and copy into service request (byte 7 + N) Send Input/Output Control by Local ID Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Input/Output Control by Local ID positive response is received Look for Input/Output Control by Local ID positive response service ID ($70) in goto fields Else Look for Input/Output Control by Local ID negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 30 Action Fields 41 03 00 00 70 11 Goto Fields 10 0D FF 99 00 00 00 00
Page
120
31 Op-Code: SR 31 to Start Routine by Local Identifier

Supported By: KWP2000 Interpreter 2 Description: The 31 Op-Code will build a standard service request $31 to send to an ECU. A Service Request $31 will start a routine identified by a local identifier. This Op-Code also supports the option to pass in Routine Entry Options from a Data Routine. For details on how to use this feature see the Action Fields and the Pseudo Code. The routine that contains the Routine Entry Options should be formatted with a zero load address and a valid length (see description of Data Routines). The data portion of the routine should only contain the Routine Entry Options to include in the request with no additional data. If the routine execution results in the ECU responding with two bytes of additional data then Op-Code 71 should be used instead of Op-Code 31. Action Fields: AC0: AC1: AC2: AC3: Local Identifier for routine number to start executing Routine number from Utility File to use as Routine Entry Options in the Service Request 31 (Shall be $00 if not used) $00 - Not used Exceptions: $00 - Not Used
Pseudo Code: XX 31 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Use KWP2000 Normal Response processing Build Start Routine by Local ID Request as indicated in the table below Request Byte 1 2 3 4 5 6 7+N Value 80 ## ## 2+N 31 AC0 Routine Entry Options to Pass CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Start routine by local ID request service ID Routine local ID for routine to begin executing Data from routine indicated by value in AC1. Number of bytes (N) is 1 to 253. For no Routine Entry Options AC1 = 0, and N = 0.
If AC1 is not $00 Find routine indicated by value in AC1 to include in request as Routine Entry Options Copy entire Data Routine into request starting at byte 7 Endif Calculate checksum and copy into service request (byte 7 + N) Send Start Routine by Local ID Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Start Routine by Local ID positive response is received Look for Start Routine by Local ID positive response service ID ($71) in goto fields Else Look for Start Routine by Local ID negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step Op-Code Action Fields Goto Fields 10 31 04 00 00 00 71 11 10 0D FF 99 00 00
00 00 Page 121
32 Op-Code: SR 32 to Stop Routine by Local Identifier

Supported By: KWP2000 Interpreter 2 Description: The 32 Op-Code will build a standard service request $32 to send to an ECU. This Op-Code is used to stop a Device Specific Control routine, from the Utility File, which was started by an Op-Code 31. Action Fields: AC0: AC1: AC2: AC3: Local Identifier for routine number to stop executing $00 - Not used $00 - Not used Exceptions: $00 - Not Used
Use KWP2000 Normal Response processing Build Stop Routine by Local ID Request as indicated in the table below Request Byte 1 2 3 4 5 6 7 Value 80 ## ## 2 32 AC0 CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Stop routine by local ID request service ID Routine local ID for routine to stop executing 1 byte message checksum
Calculate checksum and copy into service request (byte 7) Send Stop Routine by Local ID Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Stop Routine by Local ID positive response is received Look for Stop Routine by Local ID positive response service ID ($72) in goto fields Else Look for Stop Routine by Local ID negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 11 Op-Code 32 Action Fields 03 00 00 00 Goto Fields 10 0D FF 99 00 00
72 12
00 00
Page
122
33 Op-Code: SR 33 to Request Routine Results by Local Identifier

Supported By: KWP2000 Interpreter 2 Description: The 33 Op-Code will build a standard service request $33 to send to an ECU. A Service Request $33 will request the results (e.g. exit status information) generated by a routine which is identified by a local identifier. A positive response code $73 indicates the routine has successfully completed execution. Action Fields: AC0: Local Identifier for routine number of which results are requested AC1: $00 - Not used AC2: $00 - Not used AC3: Exceptions: $00 - Not Used Pseudo Code: XX 33 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Use KWP2000 Normal Response processing Build Request Routine Results by Local ID Request as indicated in the table below Request Byte 1 2 3 4 5 6 7 Value 80 ## ## 2 33 AC0 CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Request routine results by local ID request service ID Routine local ID for routine from which results are requested 1 byte message checksum
Calculate checksum and copy into service request (byte 7) Send Request Routine Results by Local ID Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Request Routine Results by Local ID positive response is received Look for Request Routine Results by Local ID positive response service ID ($73) in goto fields Else Look for Request Routine Results by Local ID negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 12 Op-Code 33 Action Fields 06 00 00 00 Goto Fields 23 0E 64 99 FF 97
73 13
00 00
Page
123
34 Op-Code: SR 34 for Download Request

Supported By: KWP2000 Interpreter 2 Description: The 34 Op-Code will build a standard Service Request 34 to send to an ECU. A request 34 will prepare the ECU to receive data from the serial data link. Request 34s are used in conjunction with service request mode 36s (Op-Codes 90, 91, and 93) to download information to ECU's. Action Fields: AC0: AC1: AC2: AC3: $00 - Not used $00 - Not used Data Format Identifier, only used with AC3 equal to $01 Exceptions: $00 - Standard Service Request 34 message format $01 - Include memory address, Data Format ID, and memory size in service request
Use KWP2000 Normal Response processing Build Request Download Request as indicated below Request Byte 1 2 3 4 5 If AC3 is $01 Request Byte 6 7 8 9 10 11 12 Value XX XX XX AC2 XX XX XX Byte Description Memory address - high byte Memory address - middle byte Memory address - low byte Data Format Identifier Uncompressed memory size - high byte Uncompressed memory size - middle byte Uncompressed memory size - low byte Value 80 ## ## 01 34 Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Request download request service ID
Set the high byte of the memory address to the high byte of the global address set in a F1 Op-Code Set the middle byte of the memory address to the middle byte of the global address set in a F1 Op-Code Set the low byte of the memory address to the low byte of the global address set in a F1 Op-Code Set the Data Format Identifier to the value in AC2 Set the high byte of the memory size to the high byte of the global size set in a F2 Op-Code Set the middle byte of the memory size to the middle byte of the global size set in a F2 Op-Code Set the low byte of the memory size to the low byte of the global size set in a F2 Op-Code Endif Request Byte 6 or 13 Value CS Byte Description 1 byte request checksum
Page
124
(continued) Calculate checksum and copy into the service request (byte 6 or 13) Send Request Download Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Request Download positive response is received Look for Request Download positive response Service ID ($74) in goto fields Else Look for Request Download negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 34 Action Fields 00 00 00 00 Goto Fields 10 0D FF 99 00 00
74 11
00 00
Page
125
37 Op-Code: SR 37 for Request Transfer Exit

Supported By: KWP2000 Interpreter 2 Description: The 37 Op-Code will build a standard Service Request 37 to send to an ECU. A request 37 will Request Transfer Exit. A Request 37 may be required at the end of a reprogramming session after all of the Transfer Data requests are completed. Action Fields: AC0: AC1: AC2: AC3: $00 - Not used $00 - Not used $00 - Not used Exceptions: $00 - Not used
Use KWP2000 Normal Response processing Build Request Transfer Exit Request as indicated in the table below Request Byte 1 2 3 4 5 6 Value 80 ## ## 01 37 CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Request Transfer Exit request service ID 1 byte request checksum
Calculate checksum and copy into the service request (byte 6) Send Request Transfer Exit and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Request Transfer Exit positive response is received Look for Request Transfer Exit positive response service ID ($77) in goto fields Else Look for Request Transfer Exit negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 37 Action Fields 02 04 00 01 Goto Fields FF 3D 00 00 00 00
77 11
00 00
Page
126
38 Op-Code: SR 38 to Start Utility File Routine by Address

Supported By: KWP2000 Interpreter 2 Description: The 38 Op-Code will build a standard service request 38 to send to an ECU. This Op-Code is used to start a Device Specific Control Routine, from the Utility File, that was downloaded to RAM by an Op-Code 90. The address information for the service request is read from the routine in the Utility File. This Op-Code also supports the option to pass in Routine Entry Options from a Data Routine. For details on how to use this feature see the Action Fields and the Pseudo Code. The routine that contains the Routine Entry Options should be formatted with a zero load address and a valid length (see description of Data Routines). The data portion of the routine should only contain the Routine Entry Options to include in the request with no additional data. If the routine execution results in the ECU responding with two bytes of additional data then Op-Code 78 should be used instead of Op-Code 38. Action Fields: AC0: AC1: AC2: AC3: Routine number from Utility File to get execution address from Routine number from Utility File to use as Routine Entry Options in the Service Request 38 (Shall be $00 if not used) $00 - Not used Exceptions: $00 - Use address from routine number AC0 $01 - Use global address information from an Op-Code 'F1'
Use KWP2000 Normal Response processing Build Start Routine by Address Request as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 8 9+N Value 80 ## ## 4+N 38 XX XX XX Routine Entry Options to Pass CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Start Routine by Address request service ID High byte of address Middle byte of address Low byte of address Data from routine indicated by value in AC1. Number of bytes (N) is 1 to 251. For no routine entry options AC1 = 0, and N = 0.
1 byte request checksum
If AC0 is not equal to $00 Find the routine indicated by the value in AC0 Endif If AC3 is $00 Copy the routine address into request starting at byte 6 (or byte 7 for two byte addressing) Else Copy the global address into request starting at byte 6 (or byte 7 for two byte addressing) Endif
Page
127
(continued) If AC1 is NOT $00 Find routine indicated by value in AC1 to include in request as Routine Entry Options Copy entire Data Routine into request starting at byte 9 Endif Calculate checksum and copy into service request byte ( 9 + N ) Send Start Routine by Address Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Start Routine by Address positive response is received Look for Start Routine by Address positive response service ID ($78) in goto fields Else Look for Start Routine by Address negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 38 Action Fields 20 00 00 00 Goto Fields 10 0D FF 99 00 00
78 11
00 00
Page
128
39 Op-Code: SR 39 to Stop Utility File Routine by Address

Supported By: KWP2000 Interpreter 2 Description: The 39 Op-Code will build a standard service request 39 to send to an ECU. This Op-Code is used to stop a Device Specific Control Routine, from the Utility File, which was started by an Op-Code 38. The address information for the service request is read from the routine in the Utility File. Action Fields: AC0: AC1: AC2: AC3: Routine number from Utility File to get execution address from $00 - Not used $00 - Not used Exceptions: $00 - Use address from routine number AC0 $01 - Use global address information from an Op-Code 'F1'
Use KWP2000 Normal Response processing Build Stop Routine by Address Request as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 8 9 Value 80 ## ## 4 39 XX XX XX CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Start Routine by Address request service ID High byte of address Middle byte of address Low byte of address 1 byte request checksum
If AC0 is not equal to $00 Find the routine indicated by the value in AC0 Endif If AC3 is $00 Copy the routine address into request starting at byte 6 (or byte 7 for two byte addressing) Else Copy the global address into request starting at byte 6 (or byte 7 for two byte addressing) Endif Calculate checksum and copy into service request byte 9 Send Start Routine by Address Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Start Routine by Address positive response is received Look for Start Routine by Address positive response service ID ($79) in goto fields Else Look for Start Routine by Address negative response, response code in goto fields Endif
Page
129
(continued) If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 39 Action Fields 02 00 00 00 Goto Fields 10 0D FF 99 00 00
79 11
00 00
Page
130
3A Op-Code: SR 3A to Request Routine Results by Address

Supported By: KWP2000 Interpreter 2 Description: The 3A Op-Code will build a standard service request 3A to send to an ECU. A Service Request 3A will request the results (e.g. exit status information) generated by a routine which is identified by a memory address. A positive response code 7A indicates the routine has successfully completed execution. Action Fields: AC0: AC1: AC2: AC3: Routine number from Utility File to get execution address from $00 - Not used $00 - Not used Exceptions: $00 - Use address from routine number AC0 $01 - Use global address information from an Op-Code 'F1'
Pseudo Code: XX 3A AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Use KWP2000 Normal Response processing Build Request Routine Results by Address Request as indicated in the table below Request Byte 1 2 3 4 5 6 7 8 9 Value 80 ## ## 4 3A XX XX XX CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Request routine results by address request service ID High byte of address Middle byte of address Low byte of address 1 byte request checksum
Calculate checksum and copy into service request (byte 9) Send Request Routine Results by Local ID Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Request Routine Results by Local ID positive response is received Look for Request Routine Results by Local ID positive response service ID ($7A) in goto fields Else Look for Request Routine Results by Local ID negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 12 Op-Code 3A Action Fields 06 00 00 00 Goto Fields 23 0E 64 99 FF 97
7A 13
00 00
Page
131
3B Op-Code: SR 3B to Write Data by Local Identifier

Supported By: KWP2000 Interpreter 2 Description: The 3B Op-Code will build a standard service request 3B to send to an ECU. This Op-Code is used to write data by Local Identifier. The data to download is determined by the information contained in the Action Fields. This Op-Code also supports the option to pass in Record Values from a Data Routine or Module and from the ECU Configuration Data. For details on how to use this feature see the Action Fields and the Pseudo Code. The routine that contains the Record Values should be formatted with a zero load address and a valid length (see description of Data Routines). The data portion of the routine should only contain the Record Values to include in the request with no additional data. Action Fields: AC0: Local identifier of data being downloaded Reserved Local Ids*: $E0 - $EF Special services action codes (length = 1 byte) $90 - Send VIN in request (length = 17 bytes) $98 - Serial number in request (length = 10 bytes) $99 - Send programming date in request (length = 4 bytes BCD or 6 bytes ASCII) * if AC1 is not $00 all values are allowed Routine number from Utility File or module number to use as Record Values in the Service Request 3B or ECU Configuration ID (Shall be $00 if not used) $00 Use routine for record values $01 Use ECU configuration data for record values $02 Use Module for record values $06 Convert programming date into ASCII ** ** if AC0 is $99, AC1 and AC3 are $00 Exceptions: $00 - Use value in AC0 as Local ID of request. $01 - Local ID is in routine or module does not include AC0 value in request.
AC1: AC2:
AC3:
Use KWP2000 Normal Response processing Build Write Data by Local ID Request as indicated in the table below Request Byte 1 2 3 4 5 6 6+N Value 80 ## ## 2+N 3B XX Record Values 1 to N CS Byte Description Format byte for physical addressing Global target ID Global source byte Length of request from byte 5 up to checksum (not included) Write data by local ID request service ID Local identifier of data to download The pseudo code below explains how the Record Value portion of this request is filled. The maximum number of bytes is 253. N = VIN or part number length + routine length. 1 byte request checksum
If AC1 is not $00 If AC2 is $00 Find routine indicated by value in AC1 to include in request as Record Values if AC3 is $00 Use AC0 as local ID Copy entire Data Routine into request starting at first record value byte ElseIf AC3 is $01 Use first byte of routine as local ID
Page
132
(continued) Copy remaining Routine Data into request starting at first record value byte Else ERR_FATAL Elseif AC2 is $01 if AC3 is $00 Use AC0 as local ID Copy ECU configuration Data into request starting at first record value byte Else ERR_FATAL Endif Elseif AC2 is $02 if AC3 is $00 Use AC0 as local ID Copy entire Module Data into request starting at first record value byte ElseIf AC3 is $01 Use first byte of Module as local ID Copy remaining Module Data into request starting at first record value byte Else ERR_FATAL Endif Else ERR_FATAL Else if AC3 is $00 Use AC0 as local ID If AC0 is 90 Copy the VIN into the request starting at byte 7 Elseif AC0 is 98 Copy the serial number into the request starting at byte 7 Elseif AC0 is 99 If AC2 is 6 Convert programming date into a 6 character ASCII string with format YYMMDD Copy the 6 character ASCII string into the request starting at byte 7 Else Copy the programming date into the request starting at byte 7 Endif Elseif AC0 < $E0 or AC0 > $EF ERR_FATAL Endif Else ERR_FATAL Endif Calculate checksum and copy into the service request (byte 6 + N) Send Write Data by Local ID Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Write Data by Local ID positive response is received Look for Write Data by Local ID positive response service ID ($7B) in goto fields Else Look for Write Data by Local ID negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 21 Op-Code 3B Action Fields 90 00 00 00 7B 22 Goto Fields FF 99 00 00 00 00 00 00
Page
133
3D Op-Code: SR 3D to Write Memory by Address

Supported By: KWP2000 Interpreter 2 Description: The 3D Op-Code will build a standard service request 3D to send to an ECU. This Op-Code is used to Write Data by Address to an ECU. The data to download is determined by the information contained in the Action Fields. Either the global address information or the routine address is used for the address in the Service Request. The data may either be the VIN, the Manufacturer Hardware Number or reside in a Data Routine. An exception allows the downloading of data with multiple services. For details on how to use this feature see the Action Fields and the Pseudo Code. The data portion of the routine should only contain the Record Values to include in the request with no additional data. Action Fields: AC0: Reserved IDs to indicate data to write to ECU (shall be $00 to use only routine data) 80 - Include the VIN in Service Request (17 data bytes) 84 - Include the Manufacturer Hardware Number in Service Request (20 data bytes) Routine number from Utility File to use as Record Values in the Service Request 3D (Shall be $00 if not used) $00 - Not used Exceptions: $00 Download routine in one service (needs to be small enough) $01 Download routine using multiple services, use routine address as download address and global header length as packet size
AC1: AC2: AC3:
Use KWP2000 Normal Response processing Build Write Data by Memory Address Service Request as indicated in the table below Request Byte 1 2 3 4 5 6 7 8 9 9+N Value 80 ## ## 5+N 3D XX XX XX N Record Values 1 to N CS Byte Description Format byte for physical addressing Global target ID Global source byte Length of request from byte 5 up to checksum (not included) Write Memory By Address request service ID Memory address - High byte Memory address - Middle byte Memory address - Low byte Memory size The pseudo code below explains how the Record Value portion of this request is filled. The maximum number of bytes is 250. N = VIN or part number length + routine length. 1 byte request checksum
If AC0 is $80 Copy the VIN into the service request starting at byte 10 Else If AC0 is $84 Copy the Manufacturer Hardware Number into the service starting at byte 10 Endif Endif
Page
134
(continued) If AC3 is $01 If AC1 is not $00 Find routine indicated by value in AC1 to include in request as Record Values Copy the routine address into request starting at byte 6 (or byte 7 for two byte addressing) Endif If AC0 is $00 Do while more routine bytes downloaded If this is the last packet of the routine Copy the remaining routine into the data area of buffer Else Copy as many routine data bytes into the Write Memory By Address Service Request (starting at byte 10) as the utility file message length states (max. 250) Endif Copy number of data bytes into byte 9 Calculate checksum and copy into the Write Memory By Address Service Request Send Write Data by Memory Address Service Request and receive response If an error occurred End the routine download Endif End do while more routine bytes downloaded Else Copy number of data bytes into byte 9 Calculate checksum and copy into the Write Memory By Address Service Request Send Write Data by Memory Address Service Request and receive response Endif Else Copy the global address into request starting at byte 6 (or byte 7 for two byte addressing) If AC1 is not $00 Find routine indicated by value in AC1 to include in request as Record Values Copy entire Data Routine into request starting at next record value byte Endif Copy utility file message length into byte 9 Calculate checksum and copy into the service request (byte 9 + N) Send Write Data by Memory Address Service Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Write Data by Memory Address positive response is received Look for Write Data by Memory Address positive response service ID ($7D) in goto fields Else Look for Write Data by Memory Address negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 21 Op-Code 3D Action Fields 90 00 2B 00 Goto Fields FF 99 00 00 00 00
7D 22
00 00
Page
135
71 Op-Code: SR 31 to Start Routine by Local Identifier and Save 2 Bytes

Supported By: KWP2000 Interpreter 2 Description: The 71 Op-Code will build a standard service request $31 to send to an ECU. A request $31 will start a routine identified by a local identifier. The 71 Op-Code is identical to the 31 Op-Code, but in addition the 71 Op-Code expects 2 bytes of data to be included in the positive response from the ECU. The value in Action Field 2 (AC2) is the ID of the storage location for the two bytes. The valid IDs are: 0x00 thru 0x13. This OpCode also supports the option to pass in Routine Entry Options from a Data Routine. For details on how to use this feature see the Action Fields and the Pseudo Code. The routine that contains the Routine Entry Options should be formatted with a zero load address and a valid length (see description of Data Routines). The data portion of the routine should only contain the Routine Entry Options to include in the request with no additional data. Note: This OpCode uses the 2-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage Action Fields: AC0: AC1: AC2: AC3: Local Identifier for routine number to start executing Routine number from Utility File to use as Routine Entry Options in the Service Request 31 (Shall be $00 if not used) ID of storage location to store 2 byte response (0x00 0x13) Exceptions: $00 - Not used
Use KWP2000 Normal Response processing Build Start Routine by Local ID Request as indicated in the table below Request Byte 1 2 3 4 5 6 7+N Value 80 ## ## 2+N 31 AC0 Routine Entry Options to Pass CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Start routine by local ID request service ID Routine local ID for routine to begin executing Data from routine indicated by value in AC1. Number of bytes (N) is 1 to 253. For no Routine Entry Options AC1 = 0, and N = 0.
If AC1 is not $00 Find routine indicated by value in AC1 to include in request as Routine Entry Options Copy entire Data Routine into request starting at byte 7 Endif Calculate checksum and copy into service request (byte 7 + N) Send Start Routine by Local ID Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing
Page
136
(continued) If Start Routine by Local ID positive response is received Copy first byte of positive response data to high byte of storage location identified by AC2 Copy second byte of positive response data to low byte of storage location identified by AC2 Look for Start Routine by Local ID positive response service ID ($71) in goto fields Else Look for Start Routine by Local ID negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 71 Action Fields 04 00 01 00 Goto Fields 10 0D FF 99 00 00
71 11
00 00
Page
137
78 Op-Code: SR 38 to Start Utility File Routine by Address and Save 2 Bytes

Supported By: KWP2000 Interpreter 2 Description: The 78 Op-Code will build a standard service request 38 to send to an ECU. This Op-Code is used to start a Device Specific Control Routine, from the Utility File, that was downloaded to RAM by an Op-Code 90. The address information for the service request is read from the routine in the Utility File. The 78 Op-Code is identical to the 38 Op-Code, but in addition the 78 Op-Code expects 2 bytes of data to be included in the positive response from the ECU. The value in Action Field 2 (AC2) is the ID of the storage location for the two bytes. The valid IDs are: 0x00 thru 0x13. This Op-Code also supports the option to pass in Routine Entry Options from a Data Routine. For details on how to use this feature see the Action Fields and the Pseudo Code. The routine that contains the Routine Entry Options should be formatted with a zero load address and a valid length (see description of Data Routines). The data portion of the routine should only contain the Routine Entry Options to include in the request with no additional data. Note: This OpCode uses the 2-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage Action Fields: AC0: AC1: AC2: AC3: Routine number from Utility File to get execution address from Routine number from Utility File to use as Routine Entry Options in the Service Request 38 (Shall be $00 if not used) ID of storage location to 2 byte response (0x00 0x13) Exceptions: $00 - Use address from routine number AC0 $01 - Use global address information from an Op-Code 'F1'
Use KWP2000 Normal Response processing Build Start Routine by Address Request as indicated in the table below, contents of the XX locations is detailed in pseudo code following the table Request Byte 1 2 3 4 5 6 7 8 9+N Value 80 ## ## 4+N 38 XX XX XX Routine Entry Options to Pass CS Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Start Routine by Address request service ID High byte of address Middle byte of address Low byte of address Data from routine indicated by value in AC1. Number of bytes (N) is 1 to 251. For no Routine Entry Options AC1 = 0, and N = 0.
1 byte request checksum
If AC0 is not equal to $00 Find the routine indicated by the value in AC0 Endif
Page
138
(continued) If AC3 is $00 Copy the routine address into request starting at byte 6 (or byte 7 for two byte addressing) Else Copy the global address into request starting at byte 6 (or byte 7 for two byte addressing) Endif If AC1 is NOT $00 Find routine indicated by value in AC1 to include in request as Routine Entry Options Copy entire Data Routine into request starting at byte 9 Endif Calculate checksum and copy into service request byte ( 9 + N ) Send Start Routine by Address Request and receive response (up to 10 Bytes) Goto KWP2000 Response Processing If Start Routine by Address positive response is received Copy appropriate response byte to high byte of storage location identified by AC2 Copy appropriate response byte to low byte of storage location identified by AC2 Look for Start Routine by Address positive response service ID ($78) in goto fields Else Look for Start Routine by Address negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 78 Action Fields 20 00 03 00 Goto Fields 10 0D FF 99 00 00
78 11
00 00
Page
139
81 Op-Code: SR 81 to Start Communications

Supported By: KWP2000 Interpreter 2 Description: The 81 Op-Code is used to start communications with an ECU. Communications will remain established while activity exists on the link. If the link is inactive for five seconds the ECU will revert back to a waiting for communications state. There are no negative responses allowed for the Start Communication request. Action Fields: AC0: AC1: AC2: AC3: $00 - Not used $00 - Not used $00 - Not used Exceptions: $00 - Not used
Use KWP2000 Normal Response processing Wait for W5min idle time Send wake up pattern to the ECU Build Start Communication Request as indicated in the table below Request Byte 1 2 3 4 5 Value 81 ## ## 81 CS Byte Description Format byte for physical addressing and length Global target byte Global source byte Start communication request service ID 1 byte service request checksum
Calculate checksum and copy into the service request (byte 5) Send Start Communication Request and get the response (up to 10 Bytes) Goto KWP2000 Response Processing Set addressing mode and use of length information based on two returned key bytes Look for Start Communication positive response service ID ($C1) in goto fields If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 01 Op-Code 81 Action Fields 00 00 00 00 Goto Fields FF 99 00 00 00 00
C1 02
00 00
Page
140
82 Op-Code: SR 82 to Stop Communications

Supported By: KWP2000 Interpreter 2 Description: The 82 Op-Code is used to stop communications with an ECU. There is no negative response allowed for the Stop Communication request. Action Fields: AC0: AC1: AC2: AC3: $00 - Not used $00 - Not used $00 - Not used Exceptions: $00 - Not used
Use KWP2000 Normal Response processing Build Stop Communication Request as indicated in the table below Request Byte 1 2 3 4 5 Value 81 ## ## 82 CS Byte Description Format byte for physical addressing Global target byte Global source byte Stop communication request service ID 1 byte service request checksum
Calculate checksum and copy into the service request (byte 5) Send Stop Communication Request and get the response (up to 10 Bytes) Goto KWP2000 Response Processing Look for Stop Communication positive response service ID ($C2) in goto fields If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 01 Op-Code 82 Action Fields 00 00 00 00 Goto Fields FF 09 00 00 00 00
C2 02
00 00
Page
141
83 Op-Code: SR 83 to Access Communications Parameters

Supported By: KWP2000 Interpreter 2 Description: The 83 Op-Code is used to access the communications parameters. This Op-Code is issued after a security request (Op-Code 27) has passed. This Op-Code is performed in two steps first, the optimum timing parameters for use during a reprogramming event are read from the ECU. Second, the optimum timing parameters are put into a service request 83 and sent to the ECU. Action Fields: AC0: AC1: AC2: AC3: $00 - Not used $00 - Not used $00 - Not used Exceptions: $00 - Not used
Use KWP2000 Normal Response processing Build Access Communications Parameters Request 1 as indicated in the table below. Provided this request is done after security has passed the ECU will return the reprogramming timing parameters. Request Byte 1 2 3 4 5 6 Value 82 ## ## 83 00 CS Byte Description Format byte for physical addressing plus length Global target byte Global source byte Access communication parameters request service ID Timing parameter identifier 1 byte service request checksum
Calculate checksum and copy into the service request (byte 6) Send Access Communications Parameters Request 1 and get the response (up to 10 Bytes) Goto KWP2000 Response Processing If Access Communications Parameter Request 1 positive response is received Build Access Communications Parameters Request 2 as indicated in the table below Request Byte 1 2 3 4 5 6 7 8 9 10 11 Value 87 ## ## 83 03 XX XX XX XX XX CS Byte Description Format byte for physical addressing plus length Global target byte Global source byte Access communication parameters request service ID Timing parameter identifier P2 minimum P2 maximum P3 minimum P3 maximum P4 minimum 1 byte service request checksum
Copy P2 minimum from Access Communications Parameters Request 1 to Request 2 position 6 Copy P2 maximum from Access Communications Parameters Request 1 to Request 2 position 7 Copy P3 minimum from Access Communications Parameters Request 1 to Request 2 position 8 Copy P3 maximum from Access Communications Parameters Request 1 to Request 2 position 9
Page
142
(continued) Copy P4 minimum from Access Communications Parameters Request 1 to Request 2 position 10 Calculate checksum and copy into the service request (byte 11) Send Access Communications Parameter Request 2 and get the response (up to 10 Bytes) Goto KWP2000 Response Processing Else Set accessing parameter list error Endif If Access Communication positive response 2 is received Set tester timing values as indicated in response 1 Look for Access Communication positive response 2 service ID ($C3) in goto fields Else Set error accessing parameter list Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 01 Op-Code 83 Action Fields 00 00 00 00 Goto Fields FF 39 00 00 00 00
C3 02
00 00
Page
143
84 Op-Code: SR 83 to Set Communications Parameters

Supported By: KWP2000 Interpreter 2 Description: The 84 Op-Code is used to set the communications parameters. This Op-Code is issued after a security request (Op-Code 27) has passed. This Op-Code is performed in one single step. The optimum timing parameters for use during a reprogramming event defined by action fields 0..3 are put into a service request 83 and sent to the ECU. If action fields 0..3 are all 0, use a defined set of timing parameters (see pseudo code). Action Fields: AC0: AC1: AC2: AC3: P2 maximum P3 minimum P3 maximum P4 minimum - AC0 <= $F0: resolution 25 ms - AC0 > $F0: resolution 6.4 sec * (AC0 - $F0). - resolution 0.5 ms - resolution 250 ms - resolution 0.5 ms
Use KWP2000 Normal Response processing Build Access Communications Parameters Request as indicated in the table below Request Byte 1 2 3 4 5 6 7 8 9 10 11 Value 87 ## ## 83 03 00 AC0 AC1 AC2 AC3 CS Byte Description Format byte for physical addressing plus length Global target byte Global source byte Access communication parameters request service ID Timing parameter identifier P2 minimum P2 maximum P3 minimum P3 maximum P4 minimum 1 byte service request checksum
If AC0, AC1, AC2 and AC3 are all $00 Set P2 maximum to 1 (25 ms) Set P3 minimum to 40 (20 ms) Set P3 maximum to 1 (250 ms) Set P4 minimum to 0 (0 ms) Endif Calculate checksum and copy into the service request (byte 11) Send Access Communications Parameter Request and get the response (up to 10 Bytes) Goto KWP2000 Response Processing If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 01 Op-Code 84 Action Fields 01 0A 78 00 Goto Fields FF 39 00 00 00 00
C3 02
00 00
Page
144
90 Op-Code: SR 36 to Transfer a Routine to ECU

Supported By: KWP2000 Interpreter 2 Description: The 90 Op-Code is used to build a service request 36 for downloading a reprogramming control routine to an ECU. The number of data bytes to include in each request is retrieved from the Utility File header. Depending on the ECU being programmed this Op-Code may need to be preceded by a service request 34 (see Op-Code 34 ). The 90 Op-Code uses the global target and source byte for all requests. If a target and source byte other than the global target and source byte needs to be used, the Interpreter instructions should contain a 01 Op-Code prior to this Op-Code. Action Fields: AC0: AC1: AC2: AC3: Routine number to download $00 - Not used $00 - Not used Exceptions: $00 - Use address from the routine in the Transfer Data Request (4 bytes) $01 - Do not include any address information in the Transfer Data Request $40 - Send a RequestDownload (use global memory address) before and a RequestTransferExit after each Transfer Data Request. Use address from the routine in the Transfer Data Service Request (4 bytes) $41 - Send a RequestDownload (use global memory address) before and a RequestTransferExit after each Transfer Data Request. Do not include any address information in the Transfer Data Service Request
4 byte naming convention = High, MidHigh, MidLow, Low Pseudo Code: XX 90 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Find the routine indicated by value AC0 Use KWP2000 Normal Response processing Build Transfer Data Request as indicated below Request Byte 1 2 3 4 5 Value 80 ## ## 4+N 36 Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Transfer Data Request Service ID
If AC3 is $00 or $40 For 2 bytes for address information: Request Value Byte Description Byte 6 XX Memory address - High byte 7 XX Memory address - Low byte 8 XX Data byte 1 The pseudo code below explains how the data portion of this request is filled 7+N XX Data byte N (N <= 252) 8+N CS 1 byte request checksum Set High byte of memory address to MidLow byte of routine address Set Low byte of memory address to Low byte of routine address
Page
145
(continued) For 3 bytes for address information: Request Byte 6 7 8 9 8+N 9+N Value XX XX XX XX Byte Description Memory address - High byte Memory address - Middle byte Memory address - Low byte Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= 251) 1 byte request checksum
XX CS
Set High byte of memory address to MidHigh byte of routine address Set Middle byte of memory address to MidLow byte of routine address Set Low byte of memory address to Low byte of routine address Else Do not include any address information in the Service Request Request Byte 6 5+N 6+N Endif Do while more routine to download If this is the last packet of the routine Change request length (byte 4) to size of last packet Copy the remaining routine into the data area of buffer Else Copy the next packet of routine into the data area of buffer starting at byte 6 or 10 Endif Calculate checksum and copy into the Transfer Data Service Request If AC3 is $40 or $41 Build Transfer Data Request as indicated below Request Byte 1 2 3 4 5 6 7 8 9 10 11 12 Note: Value 80 ## ## 12 34 XX XX XX 00 XX XX XX Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Request Download Request Service ID Global address - High byte Global address - Middle byte Global address - Low byte Data Format Identifier Uncompressed memory size - high byte Uncompressed memory size - middle byte Uncompressed memory size - low byte Value XX Byte Description Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= 254) 1 byte request checksum
XX CS
Increment Global address If remaining data is less, use number of remaining bytes for Uncompressed memory size
Calculate checksum and copy into the Request Download service request Send the Request Download request and expect a response If an error occurred End the routine download Endif
Page
146
Endif Send the Transfer Data Request and expect a response (up to 10 bytes) If AC3 is $00 or $40 Calculate the next download address Copy the next download address in the Service Request Endif If an error occurred End the routine download Endif If AC3 is $40 or $41 Build Request Transfer Exit Request as indicated below Request Byte 1 2 3 4 5 Value 80 ## ## 05 37 Byte Description
(continued)
Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Request Transfer Exit Request Service ID
Calculate checksum and copy into the Request Transfer Exit service request Send the Request Transfer Exit request and expect a response If an error occurred End the routine download Else Increment address used in Request Download service by the number of bytes transferred If remaining data is less than uncompressed memory size Use number of remaining bytes in Request Download service Endif Endif Endif End do while more routine to download If Transfer Data positive response is received Look for Transfer Data positive response service ID ($76) in goto fields Else Look for Transfer Data negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 10 Op-Code 90 Action Fields 01 00 03 00 Goto Fields FD 0D FF 20 00 00
76 11
00 00
Page
147
93 Op-Code: SR 36 to Transfer a Calibration File to ECU

Supported By: KWP2000 Interpreter 2 Description: The 93 Op-Code is used to build a service request 36 for downloading a calibration file (or software) to an ECU. Depending on the product being programmed this Op-Code may need to be preceded by a service request 34 (see Op-Code 34 ). The 93 Op-Code supports the use of either the header address or the global address for the Service Requests. To set the global address an 'F1' Op-Code should be included in the Interpreter Instructions prior to the '93' Op-Code. The 93 Op-Code supports either two or three byte addressing. The number of data bytes to include in each request is retrieved from the Utility File header. The 93 Op-Code uses the global target and source byte for all requests. If a target and source byte other than the global target and source byte needs to be used the Interpreter instructions should contain a 01 Op-Code prior to this Op-Code. Action Fields: AC0: AC1: AC2: AC3: Module ID for file to download $00 - Not used $00 - Not used Exceptions: $00 - Use utility file header address and keep address constant for entire calibration transfer (4 bytes) $01 - Use global address and keep address constant for entire calibration transfer (4 bytes) $02 - Do not include any address information in the Service Request $03 - Do not include any address information in the Service Request. Include data packet checksum byte and data packet length byte in front of the data packet bytes. Data packet checksum is a simple 8 bit sum series of all data packet bytes. The data packet length byte represents the number of data packet bytes. $80 - Use utility file header address and increment packet address by number of bytes transferred (4 bytes) $81 - Use global address and increment packet address by number of bytes transferred (4 bytes) $40 - Send a RequestDownload request before and a RequestTransferExit request after each TransferData request, use utility file header address in TransferData and keep address constant for entire calibration transfer (4 bytes) $41 - Send a RequestDownload request before and a RequestTransferExit request after each TransferData request, use global address in TransferData and keep address constant for entire calibration transfer (4 bytes) $42 Send a RequestDownload request before and a RequestTransferExit request after each TransferData request, do not include any address information in the TransferData Service Request $43 - Send a RequestDownload request before and a RequestTransferExit request after each TransferData request do not include any address information in the TransferData Service Request. Include data packet checksum byte and data packet length byte in front of the data packet bytes. Data packet checksum is a simple 8 bit sum series of all data packet bytes. The data packet length byte represents the number of data packet bytes. $C0 - Send a RequestDownload request before and a RequestTransferExit request after each TransferData request, use utility file header address in TransferData and increment packet address by number of bytes transferred (4 bytes) $C1 - Send a RequestDownload request before and a RequestTransferExit request after each TransferData request, use global address in TransferData and increment packet address by number of bytes transferred (4 bytes)
4 byte naming convention = High, MidHigh, MidLow, Low
Page
148
(continued) Pseudo Code: XX 93 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Use KWP2000 Normal Response processing Build Transfer Data Request as indicated below Request Byte 1 2 3 Value 80 ## ## Byte Description Format byte for physical addressing Global target byte Global source byte
If AC3 is $02 or $42 Do not include any address information in the Service Request Request Byte 4 5 6 5+N 6+N Value 1+N 36 XX Byte Description Length of request from byte 5 up to checksum (not included) Transfer Data request service ID Data byte 1 The pseudo code below explains how the data portion of this request is filled Data byte N (N <= 254) 1 byte request checksum
XX CS
Else If the low nibble of exception value AC3 is $0 (AC3 is $00, $40, $80 or $C0) Set data address to address from the utility file Header Else If AC3 is $03 or $43 Set pointer of High byte of data address information as data packet checksum byte Set pointer Low byte of data address information as data packet message length Else Set data address to Global Address Endif Endif For 2 bytes for address information or for exception $03 or $43: Request Value Byte Description Byte 4 1+N Length of request from byte 5 up to checksum (not included) 5 36 Transfer Data request service ID 6 XX Data address information - High byte / data packet checksum byte 7 XX Data address information - Low byte / data packet message length 8 XX Data byte 1 The pseudo code below explains how the data portion of this request is filled 7+N XX Data byte N (N <= 252) 8+N CS 1 byte request checksum Set High byte of memory address to MidLow byte of address information Set Low byte of memory address to Low byte of address information
Page
149
(continued) For 3 bytes for address information:: Request Value Byte Description Byte 4 1+N Length of request from byte 5 up to checksum (not included) 5 36 Transfer Data request service ID 6 XX Data address information - High byte 7 XX Data address information - Middle Byte 8 XX Data address information - Low byte 9 XX Data byte 1 The pseudo code below explains how the data portion of this request is filled 8+N XX Data byte N (N <= 251) 9+N CS 1 byte request checksum Set High byte of memory address to MidHigh byte of address information Set Middle byte of memory address to MidLow byte address information Set Low byte of memory address to Low byte of address information Endif Find the calibration file with ID of AC0 Do while more calibration file to transfer If this is the last packet of a file to transfer Change data packet length to size of last packet Copy the remaining data into the data area of buffer If AC3 is $03 or $43 Calculate checksum and move as data packet checksum byte Move packet length as data packet message length Endif Else Copy the next packet of data into the data area of buffer Endif If AC3 is $03 or $43 Calculate checksum and move as data packet checksum byte Move packet length as data packet message length Endif If exception value AC3 is greater than or equal to $80 Increment packet address by number of bytes transferred Endif Calculate checksum and copy into the Transfer Data Request If AC3 is $40, $41, $42, $43, $C0 or $C1 Build Transfer Data Request as indicated below Request Byte 1 2 3 4 5 6 7 8 9 10 11 12 Value 80 ## ## 12 34 XX XX XX 00 XX XX XX Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Request Download Request Service ID Global address - High byte Global address - Middle byte Global address - Low byte Data Format Identifier Uncompressed memory size - high byte Uncompressed memory size - middle byte Uncompressed memory size - low byte Page 150
Note: Increment Global address (continued) If remaining data is less, use number of remaining bytes for Uncompressed memory size Calculate checksum and copy into the Request Download service request Send the Request Download request and expect a response If an error occurred End the routine download Endif Endif Send the Transfer Data Request and expect a response (up to 10 bytes) If AC3 is $40, $41, $42, $43, $C0 or $C1 Build Request Transfer Exit Request as indicated below Request Byte 1 2 3 4 5 Value 80 ## ## 05 37 Byte Description Format byte for physical addressing Global target byte Global source byte Length of request from byte 5 up to checksum (not included) Request Transfer Exit Request Service ID
Calculate checksum and copy into the Request Transfer Exit service request Send the Request Transfer Exit request and expect a response If an error occurred End the routine download Else Increment address used in Request Download service by the number of bytes transferred If remaining data is less than uncompressed memory size Use number of remaining bytes in Request Download service Endif Endif Endif If an error occurred End the calibration download Endif End do while more calibration to transfer If Transfer Data positive response is received Look for Transfer Data positive response service ID ($76) in goto fields Else Look for Transfer Data negative response, response code in goto fields Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers. * An FD should be a goto field for a 93 Op-Code.) Step 19 Op-Code 93 Action Fields 02 04 00 00 Goto Fields 10 0D FD 20 FF 28
76 26
00 00
Page
151
Interpreter 3 - GMLAN Communications Programming Op-Codes
Page
152
GMLAN No Communications Processing

Supported By: GMLAN Interpreter 3 Description: For physical communication (one ECU) a no communication fault occurs when a request was sent to a single ECU and this ECU didn't respond (time out). When writing instructions for a Utility File the FD code can be used to determine the next step to execute after a no comm. fault occurred. The 'FD' processing can be used for any step in the utility file where a no comm. condition can occur. Pseudo Code: XX OP AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
If no comm. occurred Set return code to FD Goto response code handling Endif Typical Interpreter Line: Step 28 Op-Code B0 Action Fields 10 01 00 00 Goto Fields FD 12 FF 4A 00 00
76 29
00 00
Page
153
GMLAN Response Processing

Supported By: GMLAN Interpreter 3 Description: If a ECU doesn't respond (timeout) then No Communication Processing applies. If a negative response is received, then the tool searches for the response code (byte 3) of the received negative response in the goto fields. In all other cases, the tool searches for the positive response service ID in the goto fields. When an Op-Code refers to the response buffer the bytes are identified as follows: Positive Response: Response Byte 1 n Value XX XX Byte Description Positive Response Service ID Byte n (where n <= 4095)
Negative Response: Response Byte 1 2 3 4 5 Pseudo Code: XX OP AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Value 7F XX XX XX XX Byte Description Negative Response Service ID Request Service ID Response Code Ignored by interpreter Ignored by interpreter
Get response for the request If a timeout occurred Goto No Communication Processing Else If a negative response service ID is returned (negative response service ID $7F) If the negative response code = expected positive response service ID plus $40) Set 7f-special process flag **(see details below) Endif Set return code to negative response code Else Set return code to positive response service ID Endif Goto response code handling Endif
** Special Case 7F processing:

If the service request has a negative response code that is the same as an expected positive response message response service ID plus $40: The 7f-special-process flag will be set. The Interpreter shall look for the second occurrence of the response code in the goto fields to determine the next Interpreter step.
Page
154
(continued) As indicated in the example below the second occurrence of the response code can occur anywhere in the remaining goto fields (note: For clarity, it is recommended that the duplicate response code goto fields be on the first line and not separated as on a continuation line using the F8 continuation OpCode). If the response code is not found in the goto fields then the $FF goto will be used to determine the next Interpreter step. If the service request has a negative response code that is NOT the same as an expected positive response message response service ID plus $40: The Interpreter shall look for the FIRST occurrence of the response code in the goto fields to determine the next Interpreter step. If the response code is not found in the goto fields then the $FF goto will be used to determine the next Interpreter step. Developers Note: This processing puts the requirement for the Interpreter into the hands of the developers who know what response codes are possible for a particular service request. When a developer is writing the Interpreter instructions the need for duplicate goto fields will be obvious and should not present any problems.
Negative response processing Utility File Example and Pseudo Code Following is the message structure and utility line for pseudo code example below.
PositiveResponse
ServiceID $77
RequestMessage
ServiceID $37
NegativeResponse
ResponseID $7F
RequestID $37
ResponseCode $77
Step 12
Op-Code 37
AC0 00
AC1 00
AC2 00
AC3 00
G0-G1 77-1B
G2-G3 41-17
G4-G5 72-17
G6-G7 77-18
G8-G9 FF-15
If a PositiveResponse is received (ResponseServiceID is RequestMessageServiceID + $40). Use the first occurrence of the PositiveResponseServiceID ($77) to determine next step. (For this example the next step is Step 1B. ) Else a NegativeResponse was received (ResponseServiceID is $7F). If the NegativeResponseResponseCode equals the RequestMessageServiceID + $40. Use the second occurrence of ResponseCode ($77), or the $FF Goto field if only one occurrence of ResponseCode ($77) is found, to determine next step. (For this example the next step is Step 18.) Else. Use the ResponseCode to determine the next step. (For Response Code $41 in this example, the next step is Step 17.) Endif. Endif.
Page
155
01 Op-Code: Setup Global Variables

Supported By: GMLAN Interpreter 3 Description: The 01 Op-Code is used to set the global variables that are used during the programming process. The OpCode allows the user to alter the global settings any time during the programming event by issuing another 01 Op-Code. AC0 is used to set the Target Address. AC1 is used to set the Source Address (Tester ID). Setting the Target Address to FE will cause a fatal error. If a Target Address cannot be translated into a physical CAN ID, any transmit request will return a TIMEOUT. Action Fields: AC0: AC1: AC2: AC3: Target Address Source Address 00 - Not Used 00 - Not Used
If AC0 is true If AC0 is FE End programming with a fatal error Else Set Target Address to value in AC0 Endif Endif If AC1 is true Set Source Address to value in AC1 Endif Goto step specified by goto field one (G1) Typical Interpreter Line: Step 01 Op-Code 01 Action Fields 11 F1 00 00 Goto Fields 00 00 00 00 00 00
00 02
00 00
Page
156
10 Op-Code: Mode 10 Initiate Diagnostic Operation

Supported By: GMLAN Interpreter 3 Description: The 10 Op-Code builds a standard mode 10 message. This service allows e.g. the tester to disable the setting of Diagnostic Trouble Codes (DTCs). This service is not required before requesting other services. For the activation of each level of operation one request message is required. A mode 20 or a Tester Present timeout deactivates a previous initiated diagnostic operation level. Periodic 3E (Tester Present) service is required to keep activated levels active.
Action Fields: AC0: Diagnostic Operation Level 02 Disable all DTCs 03 enableDTCsDuringDeviceControl 00 - Not Used 00 - Not Used 00 - Not Used
AC1: AC2: AC3:
Build message as indicated in the table below Request Byte 1 2 Value 10 AC0 Byte Description Initiate Diagnostic Operation Request Service ID Diagnostic Operation Level
Send message Goto GMLAN Response Processing Typical Interpreter Line: Step 01 Op-Code 10 Action Fields 02 00 00 00 Goto Fields FF 22 00 00 00 00
50 02
00 00
Page
157
14 Op-Code: Mode 04 Clear DTC's

Supported By: GMLAN Interpreter 3 Description: The 14 Op-Code builds a standard mode 04 message. It is used to clear stored DTC's. This service might be used after programming to clear stored DTCs.
Action Fields: AC0: AC1: AC2: AC3: 00 - Not Used 00 - Not Used 00 - Not Used 00 - Not Used
Build message as indicated in the table below Request Byte 1 Value 04 Byte Description Clear Diagnostic Information
Send message Goto GMLAN Response Processing Typical Interpreter Line: Step 01 Op-Code 14 Action Fields 00 00 00 00 Goto Fields FF 22 00 00 00 00
44 02
00 00
Page
158
1A Op-Code: Mode 1A Read Data by Identifier

Supported By: GMLAN Interpreter 3 Description: The 1A Op-Code builds a standard mode 1A message to read the content of pre-defined ECU data referenced by a Data Identifier (DID), which contains static information such as ECU identification data. The response data is stored in one of the 2-byte or 256-byte internal buffers based on the value of AC3. Note: This OpCode uses either the 2-byte or the 256-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage Action Fields: AC0: AC1: AC2: AC3: Data Identifier ID for storage location of response bytes (0x00 0x13) 00 - Not Used Exceptions: 00 Use the 256-byte Data Buffer 01 Use the 2-byte Data Buffer Pseudo Code: XX 1A AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Build message as indicated in the table below Request Byte 1 2 Send message If positive response then If AC3 is false Use Data Buffer (256-byte buffer) Else Use Byte Buffer (2-byte buffer) Endif Save the data of the response starting with the first Data Byte (after the echo of the Data Identifier) to storage location indicated by AC1 (2 or 256 bytes max, fill with zero) Endif Goto GMLAN Response Processing Typical Interpreter Line: Step 06 Op-Code 1A Action Fields C1 01 00 00 Goto Fields FF 22 00 00 00 00 Value 1A AC0 Byte Description Read Data by Identifier Request Service ID Data Identifier
5A 07
00 00
Page
159
20 Op-Code: Mode 20 Return To Normal Mode

Supported By: GMLAN Interpreter 3 Description: The 20 Op-Code builds a standard mode 20 message to force the ECU to return to normal communication, i.e. to end the current diagnostic session. Once returned to normal communication, the ECU sends normal mode messages to and expects normal mode messages from other ECUs. *** This Op-Code is for development only and the use of this Op-Code should be restricted. *** Caution: Op-Code 20 is ONLY allowed (and will be processed) in Part 2 of a GMLAN utility file. If an attempt is made to execute the 20 Op-Code in the Part 1 of a GMLAN utility file, then utility file processing will immediately abort with an error (and the Mode 20 request will not be sent). Hint: More information about part 2 of the utility file can be found in section Step $11 Part 2 Write the VIN of Appendix D GMLAN Utility File Guidelines.
Build message as indicated in the table below Request Byte 1 Value 20 Byte Description Read Data by Identifier Request Service ID
If we are currently processing Part 2 of the utility file Send message Else Abort the utility file processing (fatal error) Endif Goto GMLAN Response Processing Typical Interpreter Line: Step 06 Op-Code 20 Action Fields 00 00 00 00 Goto Fields FD 12 FF 22 00 00
60 07
00 00
Page
160
22 Op-Code: Mode 22 Read Data by Parameter Identifier (PID)

Supported By: GMLAN Interpreter 3 Description: The 22 Op-Code builds a standard mode 22 message to read the contents of pre-defined ECU data that is referenced by a Parameter Identifier (PID). Only a single PID can be read via this Op-Code. The response data is stored in one of the 2-byte or 256-byte internal buffers based on the value of AC3. Note: This OpCode uses the 2-byte or the 256-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage
Action Fields: AC0: AC1: AC2: AC3: PID high byte PID low byte ID for storage location of response bytes (0x00 0x13) Exceptions: 00 Use the 256-byte Data Buffer 01 Use the 2-byte Data Buffer Pseudo Code: XX 22 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Build message as indicated in the table below Request Byte 1 2 3 Send message If positive response then If AC3 is equal to 0x01 Use Byte Buffer (2-byte buffer) Else Use Data Buffer (256-byte buffer) Endif Save the data of the response starting with the first Data Byte (after the echo of the PID) to storage location indicated by AC2 (2 or 256 bytes max, fill with zero) Endif Goto GMLAN Response Processing Typical Interpreter Line: Step 06 Op-Code 22 Action Fields C1 01 05 00 Goto Fields FF 22 00 00 00 00 Value 22 AC0 AC1 Byte Description Read Data by Parameter Identifier Request Service ID Parameter Identifier high byte Parameter Identifier low byte
62 07
00 00
Page
161
25 Op-Code: Mode AE Security Code

Supported By: GMLAN Interpreter 3 Description: The 25 Op-Code will build a special Mode $AE message. This service allows a test device to enter a security code, reset a security code or program a security code as designed for GM Global A vehicles. For the Service Programming System (SPS), the value of the security code(s) will be obtained from the service database based on the VIN. For the Development Programming System (DPS), the value of the security code(s) will be manually entered by the user. Periodic 3E (Tester Present) service is required to keep the level active. Action Fields: AC0: AC1: CPID number Device Control: 80 Enter (e.g. unlock ECU) 40 Program security code (e.g. write security code) 20 Reset security code (e.g. write security code default value) 01 Security Code 1 (Security Code 1 refers to the security code assigned to the vehicle) 02 Security Code 2 (Security Code 2 is used to unlock an ECU that has a different security code than the vehicle) **Vehicle Assembly Plant ignores this action code** 01 Security Code Format ASCII (default) **Vehicle Assembly Plant ignores this action code**
AC2:
AC3:
Pseudo Code: XX AE AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Build message as indicated in the table below Request Byte 1 2 3 4 5 6 7 Value AE AC0 AC1 SC SC SC SC Byte Description Request Device Control CPID Number Security Access Device Control Trigger Security Code (MSB) SPS = VIT2 / DPS = manual entry Security Code SPS = VIT2 / DPS = manual entry Security Code SPS = VIT2 / DPS = manual entry Security Code (LSB) SPS = VIT2 / DPS = manual entry
If AC1 equals 20, 40 or 80 If AC2 equals 01 Set the SecurityCode to the Security Code 1 ElseIf AC2 equals 02 Set the SecurityCode to the Security Code 2 Endif Copy SecurityCode (ASCII) into message bytes 4 7 Else End with error Endif Send message Goto GMLAN Response Processing Typical Interpreter Line: Step 10 Op-Code 25 Action Fields 01 80 01 01 Goto Fields E3 0D FD 20 FF 2B
EE 11
00 00 Page 162
27 Op-Code: Mode 27 Security Access

Supported By: GMLAN Interpreter 3 Description: The 27 Op-Code is used to open an ECU's memory for reprogramming. The value in AC0 identifies which security algorithm to use for unlocking the ECU for programming. The security algorithm defines the functions that are performed on the seed to determine the ECU key. If security fails for "Invalid Key - 35" the Interpreter will retry the entire security process (starting with request 1) using the ones complement security algorithm. This provides a means to program development ECU's using a production Utility File. Periodic 3E (Tester Present) service is required to keep the level active. Note: To allow for more than 256 unique GM Security Alogorithms, a second Security Table (GMLAN-1) has been created (see the high nibble of AC2). All previously existing GM Security Algorithms will be referenced to the first Security Table (GMLAN-0). So now for new GM Security Algorithms, the user needs to know the algorithm number as well as the corresponding GMLAN Security Table number (either 0 or 1).
Action Fields: AC0: Security Algorithm 00 - Ones Complement (Default Security Algorithm) 01 - to FE Production Algorithm (Production Security Algorithms) 00 - Security level 1 (level $01 and $02 get seed/send key) 01 - Security level 3 ( DVT level $03 and $04 DVT get seed/send key) XX Security level (2*XX + 1) Example : $7D = security level $FB ($FB and $FC get seed/send key) 00 GM Security Algorithm, Security Key Calculation References the original GMLAN Algorithms Security Table GMLAN-0 01 Not implemented: GM Security Algorithm, Security Key Calculation in other source 02 Not implemented: Non GM Security Algorithm, Security Key Calculation in other source 03 Non GM Security Algorithm, Security Key Calculation 10 GM Security Algorithm, Security Key Calculation References the new GMLAN Algorithms Security Table GMLAN-1 Exceptions: 00 Don't send key if seed is 0 (according to specification) 01 Send key even if seed is 0
AC1:
AC2:
AC3:
Build Security Access Request 1 as indicated in the table below Request Byte 1 2 Value 27 XX Byte Description Security Access Request Service ID AC1 (1) Access mode if AC1 = 0, this byte would be 1, if AC1 = 1 this byte would be 3, etc.
Send Security Access Request 1 for request seed and receive response
Page
163
(continued) If Security Access positive response 1 is received If both bytes of the seed (Security Access positive response bytes 3 & 4) are zeros and exception isn't 1 Indicate Security Access positive response received do not second Security Access Request 2 Else Use security algorithm corresponding to AC0 to determine ECU's key (For GMLAN Security Algorithms, the High Nibble of AC2 will also be evaluated to determine which GMLAN Security Table to reference --- Table 0 (GMLAN-0) or Table 1 (GMLAN-1).) Build Security Access request 2 as indicated in the table below Request Byte 1 2 3 4 Value 27 XX XX XX Byte Description Security Access Request Service ID AC1 (2) Access mode if AC1 = 0, this byte would be 2, if AC1 = 1 this byte would be 4, etc. High byte of key Low byte of key
Send Security Access Request 2 for send key and receive response Endif If Security Access positive response 2 is received Look for Security Access positive response 2 service ID (67) in goto fields Else If Security Access negative response "Invalid Key - 35" is received and ones complement was not used Repeat entire security process using ones complement security algorithm Else Look for Security Access negative response 2 response code in goto fields Endif Endif Else If Security Access negative response "Time Delay not Expired - $37" is received If ten second timer has not expired Delay 2 seconds Retry entire security process Else Look for Security Access negative response AC3 (1) response code ($37) in goto fields Endif Else Look for Security Access negative response AC3 (1) response code in goto fields Endif Endif If found Goto appropriate step Else Goto step indicated by FF goto field Endif Typical Interpreter Line: (all action and goto fields are hex numbers) Step 02 Op-Code 27 Action Fields 00 00 00 Goto Fields 37 13 FF 22 00 00
01
67 03
00 00
Page
164
34 Op-Code: Mode 34 Request Download

Supported By: GMLAN Interpreter 3 Description: The 34 Op-Code will build a standard mode 34 message. This mode is used in order to prepare a node to receive a download of a block of data. The node must be unlocked, mode 28 (Disable Normal Communication) must be active and mode A5 (Programming Mode) must be passed prior to sending a mode 34 request. Periodic 3E (Tester Present) service is required to keep the level active. Action Fields: AC0: Data Format Identifier 00 - Unencrypted, uncompressed 01 - to FF High nibble Compression Method, low nibble Encrypting Method Routine / Calibration Number 00 - Not Used Exceptions: (Information is nibble coded) 0X - Use length from the routine indicated by AC1 (2 bytes) 1X - Use length from the utility file header (2 bytes) 2X - Use Global Length (see F2 Op-Code) (4 bytes) 3X - Use length based on the size of the calibration file indicated by AC1 (4 bytes) X0 - Use TypeOfAddressing bytes for length information X2 - Use 2 bytes for length information X3 - Use 3 bytes for length information X4 - Use 4 bytes for length information Pseudo Code: XX 34 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Build message as indicated in the table below For 2 bytes for length information: Request Value Byte Description Byte 1 34 Request Download Request Service ID 2 AC0 Data Format Identifier 3 XX Uncompressed Memory Size (High byte) 4 XX Uncompressed Memory Size (Low byte) For 3 bytes for length information: Request Value Byte Description Byte 1 34 Request Download Request Service ID 2 AC0 Data Format Identifier 3 XX Uncompressed Memory Size (High byte) 4 XX Uncompressed Memory Size (Middle byte) 5 XX Uncompressed Memory Size (Low byte) For 4 bytes for length information: Request Value Byte Description Byte 1 34 Request Download Request Service ID 2 AC0 Data Format Identifier 3 XX Uncompressed Memory Size (High byte) 4 XX Uncompressed Memory Size (MidHigh byte) 5 XX Uncompressed Memory Size (MidLow byte) 6 XX Uncompressed Memory Size (Low byte)
AC1: AC2: AC3:
Page
165
(continued) If the high nibble of AC3 is 0 (0X) Find the routine indicated by value AC1 Set MemorySize to routine length ElseIf the high nibble of AC3 is 1 (1X) Set MemorySize to length from the utility file Header ElseIf the high nibble of AC3 is 2 (2X) Set MemorySize to Global Length (default 2X) ElseIf the high nibble of AC3 is 3 (3X) Find the calibration file indicated by value AC1 Set MemorySize to the size of the calibration file Else End with error (invalid high nibble of AC3) Endif If AC3 & 0F is true Set LengthSize to AC3 & 0F Else Set LengthSize to TypeOfAddressing Endif if LengthSize is 2 Copy High byte of MemorySize into message byte 3 Copy Low byte of MemorySize into message byte 4 Elseif LengthSize is 3 Copy High byte of MemorySize into message byte 3 Copy Middle byte of MemorySize into message byte 4 Copy Low byte of MemorySize into message byte 5 Elseif LengthSize is 4 Copy High byte of MemorySize into message byte 3 Copy MidHigh byte of MemorySize into message byte 4 Copy MidLow byte of MemorySize into message byte 5 Copy Low byte of MemorySize into message byte 6 Endif Send message Goto GMLAN Response Processing Typical Interpreter Line: Step 10 Op-Code 34 Action Fields 10 00 00 20 Goto Fields FF 22 00 00 00 00
74 11
00 00
Page
166
3B Op-Code: Mode 3B Write Data by Identifier

Supported By: GMLAN Interpreter 3 Description: The 3B Op-Code will build a standard mode 3B message. This service is used to provide the ability to change (write/program) the content of pre-defined ECU data referenced by a Data Identifier (DID), which contains static data like ECU identification data or other information, which does not require real-time updates. If multiple DIDs are written via a calibration file the GlobalHeaderLength is used to skip header information. Action Fields: AC0: Data Identifier (DID number) 90 VehicleIdentificationNumber 98 RepairShopCodeOrTesterSerial 99 ProgrammingDate CB End Model Part Number XX - ECU Configuration Data Routine Number / ID for saved bytes (0x00 0x13) / Internal Data Specificer (if AC3 is 0x03) - Calibration ID (if AC3 is 22) - Number of bytes (if AC3 is 30) - Cylinder # (if AC3 is 0x03 and AC1 is 0x46. A cylinder # of 0 represents data for all cylinders) - Key Fob number (if AC3 is 0x03 and AC1 is 0x48. A value of 0 means data for all key fobs). Exceptions: 00 Use internal data from the VIT based on the AC0 Data Identifier (see above) Use AC0 as the Data Identifier (DID number) to write to. 03 Use internal data from the VIT based on the AC1 Internal Data Specifier Use AC0 as the Data Identifier (DID number) to write to. This exception is ONLY supported by the Assembly Plants. If used in the service environment, a fatal error will occur. Valid Internal Data Specifiers with this exception are $45 (TPM Placard data), $46 (Diesel Injector IMA/IQA data), $47 (TCCM B-Cal value), $48 (Key Fob data), and $49 (Engine Serial Number). Reference generic op-codes $53 (Compare Data) and $54 (Change Data) for additional descriptions of these internal data specifiers. 10 Use data from the routine indicated by AC1 Use AC0 as the Data Identifier (DID number) to write to. 11 Use data from the routine indicated by AC1 Use the first byte of the routine data as the Data Identifier (DID number) to write to. 22 Use data from the calibration file indicated by AC2 (multiple DIDs are possible) The Data Identifier(s) is defined within the calibration file. (see DID calibration file format) 3x Use stored information where AC1 is ID for saved bytes, only 0x00 - 0x13 IDs are supported. Buffer size 256 bytes (x dont care what the low nibble value is) Use AC0 as the Data Identifier (DID number) to write to. 4x Use VIN digits 10-17 retrieved from internal data. (x dont care what the low nibble value is) Use AC0 as the Data Identifier (DID number) to write to.
AC1: AC2:
AC3:
Example of DID Calibration file: 88880002220000F424004141020784226552130000078501E200000000 (must be in binary format) Module Checksum Module ID Header Format ID SWMI Alpha Code Block count Block 1 Length Block 1 Block 2 Length Block 2 = 8888 = 0002 = 2200 = 00 F4 24 00 (16000000) = 41 41 (AA) = 02 = 07 = 84 22 65 52 13 00 00 = 07 = 85 01 E2 00 00 00 00 Page 167
(continued) Pseudo Code: XX 3B AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Build message as indicated in the table below Request Byte 1 2 3 Value 3B XX XX XX Byte Description Write Data by Identifier Data Identifier Data Byte 1 Data Byte ...
If AC2 is not zero and AC3 is 22 Open calibration AC2 Skip GlobalHeaderLength bytes Read BlockCount While BlockCount > 0 Read BlockLength Copy BlockLength bytes of calibration AC2 into message (first byte is Data Identifier) Send message If not a positive response is received Break while Endif Subtract 1 from BlockCount Loop Endif If high nibble of AC3 is 0 Set Data Identifier to AC0 If the low nibble of AC3 is 0 Copy internal VIT data based on AC0 into the message Send message Else (the low nibble of AC3 is 3 (ONLY supported for the Plant Manufacturing environment) Copy internal VIT data based on AC1 (Internal Data Specifier) into the message Send message Endif Endif If high nibble of AC3 is 1 Find the routine indicated by value AC1 If the low nibble of AC3 is 1 Set Data Identifier to first routine data byte Copy remaining routine data bytes into the message Send message Else (the low nibble of AC3 is 0) Set Data Identifier to AC0 Copy routine data into message Send message Endif Endif If high nibble of AC3 is 3 Set Data Identifier to AC0 Copy AC2 number of bytes from stored information where AC1 is the ID for saved bytes into the message (max 256 bytes) Send message Endif
Page
168
(continued) If high nibble of AC3 is 4 Set Data Identifier to AC0 Place the last 8 digits of the VIN (internal data) into the message (Note: If the last 8 digits are 0x00 data, then simulate a positive response without sending the message) Endif If a valid AC3 was processed GoTo GMLAN Response Processing Else End with fatal error Endif
Typical Interpreter Line: Step 21 Op-Code 3B Action Fields 90 00 00 00 Goto Fields FF 32 00 00 00 00
7B 22
00 00
Page
169
84 Op-Code: Set Communications Parameters

Supported By: GMLAN Interpreter 3 Description: The 84 Op-Code is used to set the communications parameters. Currently, the only parameter, which can be set, is the STmin. This is the minimum interframe time for the tester normally dictated by a controller within its flow control frame. Op-code 84 allows to override the value in the controllers flow control. NOTE: GM NAO assembly plants will currently not support this Op-Code for the GMLAN protocol. If this OpCode is encountered in the assembly plant utility file, the G1 Go To will be processed. Action Fields: AC0: 00 - use STmin value in flow control 01 - use STmin value in AC2 AC1: Affected subnet: 01 - SWCAN, 02 - MSCAN, 04 HSCAN, 08 ESCAN (can be logically OR-ed) AC2: STmin value, resolution 1 ms AC3: 00 - Not Used Pseudo Code: XX 84 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
If AC0 == 0 Use STmin from controllers flow control frame (default behavior) for the subnets specified in AC1 Else If AC0 == 1 Use STmin specified by AC2 for the subnets specified in AC1 Else Stop immediately Endif If setting STmin succeeded Goto step specified in goto field 1 (G1). Else Goto step specified in goto field 3 (G3). Endif Typical Interpreter Line: (all Action and Goto fields are hex numbers) Step 01 Op-Code 84 Action Fields 01 07 02 00 Goto Fields FF 22 00 00 00 00
00 02
00 00
Page
170
A2 Op-Code: Mode A2 Report Programmed State and Save Response

Supported By: GMLAN Interpreter 3 Description: The A2 Op-Code will build a standard mode A2 message. This service is used to determine the current programmed state of the ECU. Mode 28 (Disable Normal Communication) must be active prior to sending a mode A2 request. Periodic 3E (Tester Present) service is required to keep the level active. Note: This OpCode uses the 2-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage Action Fields: AC0: AC1: AC2: AC3: ID for storage location of response bytes (0x00 0x13) Buffer size is 2-bytes 00 - Not Used 00 - Not Used 00 - Not Used
Pseudo Code: XX A2 AC0 AC1 AC2 AC3
G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Build message as indicated in the table below Request Byte 1 Send message If positive response then Save byte2 from the response to storage location indicated by AC0 (use zero as high byte) Endif Goto GMLAN Response Processing Value A2 Byte Description ReportProgrammedState
Typical Interpreter Line: Step 06 Op-Code A2 Action Fields 01 00 00 00 Goto Fields FF 22 00 00 00 00
E2 07
00 00
Page
171
AA Op-Code: Mode AA Read Data by Packet Identifier

Supported By: GMLAN Interpreter 3 Description: The AA Op-Code builds a standard mode AA message to read the content of pre-defined ECU data referenced by a Dynamic Parameter Identifier (DPID). Only 1 DPID can be requested using sub-function $01 (single shot). The response is a UUDT frame not containing length information. The received data is stored in an internal buffer (one of 256- byte internal buffers) or in the VIT2. NOTEs: 1. Some diagnostic interfaces may not support this function as mixed mode support is a SAE J2534-2 optional feature. 2. This OpCode should not be used in part 1 of a GMLAN utility file on an ECU which may not be able to support the $AA service until fully programmed. Examples of this condition may be programming out of boot mode and attempting to program certain SPS Type B and Type C ECUs. 3. This OpCode uses the 256-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage
Action Fields: AC0: AC1: DPID (Dynamic Parameter Identifier) ID for storage location of response bytes 0x00..0x13 256-byte Data Buffers (0..19 decimal) 90 VIN in VIT2 91 Vehicle manufacturer hardware number (VMECUHN) in VIT2 98 Repair shop code or serial number (RSCOSN) in VIT2 99 Programming date (PD) in VIT2 CB End model number (EMN) in VIT2 CC System supplier hardware number (SSECUHN) in VIT2 Number of bytes to store Exceptions: Bit 7: 0 Copy directly 1 Convert into decimal number ASCII string Bit 0..6 Start location of bytes to copy (0 refers to packet identifier)
AC2: AC3:
Pseudo Code: XX AA AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Build message as indicated in the table below Request Byte 1 2 2 Send message Value AA 01 AC0 Byte Description Read Data by Identifier Request Service ID Mode (single shot) Dynamic Packet Identifier
Page
172
(continued) If response then If AC2 specifies more bytes to copy than available from start position (AC3 $ $7F) to end Set number of bytes to copy to number of available bytes Else Set number of bytes to copy to AC2 Endif If AC3 & $80 If AC2 <= 4 Treat data as a 1..4 byte number, convert into a string as decimal to temporary buffer Set number of bytes to copy to string length of string in temporary buffer Else Copy specified number of bytes into temporary buffer Endif If AC1 is in range $00..$13 Copy temporary buffer to one of the 256-byte Data Buffers (AC1 = index) Else if AC1 is $90 Copy temporary buffer to VIN in VIT2 Else if AC1 is $91 Copy temporary buffer to Vehicle Manufacturer ECU Hardware Number in VIT2 Else if AC1 is $98 Copy temporary buffer to Repair Shop Code Or Serial Number in VIT2 Else if AC1 is $99 Copy temporary buffer to Programming Date in VIT2 Else if AC1 is $CB Copy temporary buffer to End Model Number in VIT2 Else if AC1 is $CC Copy temporary buffer to System Supplier ECU Hardware Number in VIT2 EndIf Endif Goto GMLAN Response Processing Since the response is a UUDT frame, the SID position is occupied by the DPID. Hence, the fields G0, G2, etc. shall contain the DPID (see AC1) and NOT the expected response SID $EA to catch the positive case. Typical Interpreter Line: Step 06 Op-Code AA Action Fields 09 99 03 03 Goto Fields FF 22 00 00 00 00
09 07
00 00
Page
173
AE Op-Code: Mode AE Request Device Control

Supported By: GMLAN Interpreter 3 Description: The AE Op-Code will build a standard mode AE message. This service e.g. allows a test device to override normal output control functions in order to verify proper operation of a component or system, or to reset/clear variables used within normal control algorithms. Periodic 3E (Tester Present) service is required to keep the level active. Action Fields: AC0: AC1: AC2: AC3: CPID Number Routine Number 00 - Not Used 00 - Not Used
Pseudo Code: XX AE AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Build message as indicated in the table below Request Byte 1 2 2+N Value AE AC0 Byte Description Request Device Control CPID Number Control Bytes Control Byte N (N from 0 to 5)
XX
Find the routine indicated by value AC1 Copy routine data into message (number of control bytes from 0 to 5 bytes max) Send message Goto GMLAN Response Processing
Typical Interpreter Line: Step 10 Op-Code AE Action Fields FE 02 00 00 Goto Fields E3 0D FF 20 00 00
EE 11
00 00
Page
174
B0 Op-Code: Mode 36 Block Transfer to RAM

Supported By: GMLAN Interpreter 3 Description: The B0 Op-Code will build a standard mode 36 message. This Op-Code is used to transfer data to a control module. A single data transfer message is limited to a maximum of 4095 data bytes (including the SID, Identifier Option and 2, 3 or 4 Address Bytes -> 4091, 4090 or 4089 data bytes). The node must be unlocked, mode 28 (Disable Normal Communication) must be active, mode A5 (Programming Mode) must be passed and mode 34 must be positive answered prior to sending a mode 36 request. Periodic 3E (Tester Present) service is required to keep the level active. The maximal number of bytes to send with each message is retrieved from the Utility File header. If the GlobalHeaderLength is not zero then the download of the module will be separated in two parts. The GlobalHeaderLength number of bytes will be downloaded first.
Action Fields: AC0: Calibration ID 00 - Not Used 01 - FF Calibration ID Routine Number Exceptions: (Information is nibble coded) 0X Download 1X - Download and Execute 2X - Execute Only (do not include data into message) X0 - Increment address X1 - Keep address constant Exceptions: (Information is nibble coded) 0X - Use address from the routine indicated by AC1 (4 bytes) 1X - Use address from the utility file header (4 bytes) 2X - Use Global Address (see F1 Op-Code) (4 bytes) X0 - Use TypeOfAddressing bytes for address information X2 - Use 2 bytes for address information X3 - Use 3 bytes for address information X4 - Use 4 bytes for address information 4 byte naming convention = High, MidHigh, MidLow, Low
AC1: AC2:
AC3:
Pseudo Code: XX B0 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Build message as indicated in the table below
Page
175
(continued) For 2 bytes for address information: Request Value Byte Description Byte 1 36 Transfer Data 2 XX Level of Operation 00 Download 80 - Download and Execute 3 XX Starting Address (High byte) 4 XX Starting Address (Low byte) 5 XX Data Byte 1 Data Byte ... For 3 bytes for address information: Request Value Byte Description Byte 1 36 Transfer Data 2 XX Level of Operation 00 Download 80 - Download and Execute 3 XX Starting Address (High byte) 4 XX Starting Address (Mid byte) 5 XX Starting Address (Low byte) 6 XX Data Byte 1 Data Byte ... For 4 bytes for address information: Request Value Byte Description Byte 1 36 Transfer Data 2 XX Level of Operation 00 Download 80 - Download and Execute 3 XX Starting Address (High byte) 4 XX Starting Address (MidHigh byte) 5 XX Starting Address (MidLow byte) 6 XX Starting Address (Low byte) 7 XX Data Byte 1 Data Byte ... If AC2 & 30 is true Set Level of Operation to 80 (Level of Operation = Download and Execute) Else Set Level of Operation to 00 (Level of Operation = Download) Endif If AC3 & 30 is false Find the routine indicated by value AC1 Set StartingAddress to routine address Else If AC3 & 10 is true Set StartingAddress to address from the utility file Header Else Set StartingAddress to Global Address Endif Endif If AC3 & 0F is true Set LengthSize to AC3 & 0F Else Set LengthSize to TypeOfAddressing Endif
Page
176
If AC2 & 20 is false (Not Execute Only) (continued) if AC0 (Calibration ID) is false Use data from the routine indicated by value AC1 Else Use data from the calibration file indicated by value AC0 Endif Do while more data to download if LengthSize is 2 Copy High byte of StartingAddress into message byte 3 Copy Low byte of StartingAddress into message byte 4 Elseif LengthSize is 3 Copy High byte of StartingAddress into message byte 3 Copy Middle byte of StartingAddress into message byte 4 Copy Low byte of StartingAddress into message byte 5 Elseif LengthSize is 4 Copy High byte of StartingAddress into message byte 3 Copy MidHigh byte of StartingAddress into message byte 4 Copy MidLow byte of StartingAddress into message byte 5 Copy Low byte of StartingAddress into message byte 6 Endif If this is the last packet to download or the GlobalHeaderLength is not 0 and splits the module Copy the remaining data into the message Else Copy the next block of data into the message Endif If AC2 & 0F is false Calculate next download address end if Send message If negative response received Break do while more data to download Endif End do while more data to download Else (Execute Only) if LengthSize is 2 Copy High byte of StartingAddress into message byte 3 Copy Low byte of StartingAddress into message byte 4 Elseif LengthSize is 3 Copy High byte of StartingAddress into message byte 3 Copy Middle byte of StartingAddress into message byte 4 Copy Low byte of StartingAddress into message byte 5 Elseif LengthSize is 4 Copy High byte of StartingAddress into message byte 3 Copy MidHigh byte of StartingAddress into message byte 4 Copy MidLow byte of StartingAddress into message byte 5 Copy Low byte of StartingAddress into message byte 6 Endif Send message Endif Goto GMLAN Response Processing Typical Interpreter Line: Step 10 Op-Code B0 Action Fields 10 00 01 10 Goto Fields 85 0D FD 20 FF 49
76 11
00 00
Page
177
Communications Independent Programming Op-Codes
Page
178
50 Op-Code: Compare Bytes

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The 50 Op-Code compares 2 bytes of stored information to 2 bytes of information in the interpretive line. The stored information is not generated by the 50 Op-Code. Action Field 0 will provide the location ID of the 2 stored bytes. Note: The first (G0) and the third (G2) bytes of the Goto Fields are always set to 0x00 because they are not used (don't cares). Note: This OpCode uses only the 2-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage Action Fields: AC0: AC1: AC2: AC3: ID for saved bytes, only 0x00 0x13 IDs are supported. (2-byte storage buffer) First byte of compare (high byte) Second byte of compare (low byte) 00 - Not Used
Pseudo Code: XX 50 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 If the 2 Bytes Stored in storage location ID (AC0) matches the 2 bytes in AC1 and AC2 Goto step specified in G1 Else Goto step specified in G3 Endif Typical Interpreter Line: Step 06 Op-Code 50 Action Fields 03 89 B9 00 Goto Fields 00 29 00 00 00 00
00 07
00 00
Page
179
51 Op-Code: Compare Checksum

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The 51 Op-Code compares a stored checksum to a checksum calculated from a calibration module. The module checksum is calculated by the Op-Code. The stored checksums may reside in 1 of 20 possible storage locations specified by AC0. Three different checksum algorithms are supported: 16 bit sum of all bytes, CRC-32 or CRC-32 complement. CRC-32 requires a 32-bit checksum. Hence, a 16-bit sum comparison will be done against 2-byte storage location while the CRC-32 checks will be done against the first 4 bytes of a 256-byte storage location. Care must be taken to use the proper Op-Code to store the controllers checksum. Note: The first (G0) and the third (G2) bytes of the Goto Fields are always set to 0x00 because they are not used (don't cares).
Note: This OpCode uses either the 2-byte or the 256-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage Action Fields: AC0: AC1: AC2: AC3: ID for saved bytes, only 0x00 0x13 IDs are supported. Calibration module ID of calculated checksum Checksum Type (00, 01, 02 see below) 00 - Not Used
Pseudo Code: XX 51 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 If AC2 is 0 (16-bit checksum) Sum up all data bytes of the module specified by AC1 as a 16-bit value Else Calculate the CRC-32 of the module specified by AC1 as a 32-bit value Endif If AC2 is 00 Compare calculated checksum with 2-byte storage location specified by AC0 Else If AC2 is 01 Complement checksum and compare with first 4 bytes of the 256-byte storage location specified by AC0 Else If AC2 is 02 Compare checksum with first 4 bytes of the 256-byte storage location specified by AC0 Else Set the compare to failed Endif If the compare succeeded Goto step specified in G1 Else Goto step specified in G3 Endif Typical Interpreter Line: Step 06 Op-Code 51 Action Fields 03 01 00 00 Goto Fields 00 29 00 00 00 00
00 07
00 00 Page 180
53 Op-Code: Compare Data

Supported By: Class 2 Interpreter 1 GMLAN Interpreter 3 Description: The 53 Op-Code compares a maximum of 256-bytes of stored information (based on AC0) against other information that can be internal data (VIT2), routine data or other stored data. Note: The first (G0) and the third (G2) bytes of the Goto Fields are always set to 0x00 because they are not used (don't cares). DPS Note: When Internal VIT2 Data is used for the comparison AND the conversion type of 01 is chosen (ASCII to 4 byte USN), the software/calibration file names (part numbers) within the DPS archive must be numeric in order to perform a valid data comparison. Note: This OpCode uses only the 256-byte storage buffers. For buffer usage information, see the section: Programming Buffers Recommended Usage Action Fields: AC0: ID for saved bytes, only 0x00 0x13 IDs are supported. Buffer size: 256 bytes AC1: Second ID (See Exceptions) AC2: Conversion 00 - Not Used 01 - ASCII to 4 byte USN AC3: Exceptions: 00 - Use internal data (VIT2) where AC1 identifies the information 01 - Use data from the routine indicated by AC1 02 - Use stored information where AC1 is ID for saved bytes, only 0x00 0x13 IDs are supported. Buffer size: 256 bytes Internal Data Identifiers 0x01 Part Number Module ID 1 0x02 Part Number Module ID 2 0x03 Part Number Module ID 3
Formats: ASCII, BCD = Binary Coded Decimal, USN = Unsigned Numeric, BIN = Binary or bit encoded.
... ...
0x13 0x14 0x81 0x82 0x83 0xE2 0xE3 Part Number Module ID 19 Part Number Module ID 20 - OR Part Number Module ID 1 Part Number Module ID 2 Part Number Module ID 3 Part Number Module ID 98 Part Number Module ID 99
... ...
0x41 0x42 0x43 0x44
VIN Manufacturer HW Number (End Model ECU Software Number) Supplier HW Number (Base Model ECU Hardware Number) Tire Type (e.g. P275/55R20) Note: This internal data is only supported in GM Vehicle Assembly Plants. Comparison of this data in a Service environment is treated as an invalid exception and results in termination of utility file execution with error.
Page
181
0x45
0x46
0x47
0x48
0x49
TPM tire placard data Note: This internal data is only supported in GM Vehicle Assembly Plants. Comparison of this internal data in a Service environment is treated as an invalid exception and results in termination of utility file execution with error. Diesel Injector Mass Adjustment (IMA) or Injector Quantity Adjustment (IQA) data. Note: This internal data is only supported in GM Vehicle Assembly Plants. Comparison of this internal data in a Service environment is treated as an invalid exception and results in termination of utility file execution with error. Transfer Case Control Module B-Cal (spring rate) data. Note: This internal data is only supported in GM Vehicle Assembly Plants. Comparison of this internal data in a Service environment is treated as an invalid exception and results in termination of utility file execution with error. Key Fob data. This internal data specifier is used to program key fob data into a controller on the vehicle. Note: This internal data is only supported in GM Vehicle Assembly Plants. Comparison of this internal data in a Service environment is treated as an invalid exception and results in termination of utility file execution with error. Engine Serial Number. . Note: This internal data is only supported in GM Vehicle Assembly Plants. Comparison of this internal data in a Service environment is treated as an invalid exception and results in termination of utility file execution with error.
Pseudo Code: XX 53 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Set Data2 to stored information indicated by AC0 If AC3 is 00 Set Data1 to internal data (VIT2) where AC1 identifies the information Else If AC3 is 01 Set Data1 to routine data indicated by AC1 Else If AC3 is 02 Set Data1 to stored information indicated by AC1 Endif If AC2 is not 00 Convert Data1 using the conversion format indicated by AC2 Endif If all bytes in Data1 (max. 256 bytes) matches the bytes in Data2 Goto step specified in G1 Else Goto step specified in G3 Endif Typical Interpreter Line: Step 06 Op-Code 53 Action Fields 00 02 00 00 00 07 Goto Fields 00 29 00 00 00 00 00 00
Page
182
54 Op-Code: Change Data

Supported By: Class 2 Interpreter 1 GMLAN Interpreter 3 Description: The 54 Op-Code manipulates one or more bytes within one of the 256-byte storage buffers (AC0) or can be used to load data from a routine into one of the 256-byte buffers for subsequent manipulation. It can also be used to copy the data from one internal storage buffer to another. Note: The first (G0) byte of the Goto Field is always set to 0x00 because it is not used (don't care). See appendix G for further information on this Op-Code. Action Fields: AC0: ID for saved bytes, only 0x00 0x13 IDs are supported. Buffer size: 256 bytes AC1: Second ID - Byte position if AC2 < 04 ($00-$FF zero based indexing) - Number of bytes to shift if AC2 is 04 or 05 ($00-$FF) - Routine # if AC2 is 06 ($01-$FF) - Internal data specifier if AC2 is 07 ($41,$44,$45,$46,$47,$48,49) AC2: Operation 00 - EQUAL 01 - AND 02 - OR 03 - XOR 04 - SHL shift left, fill with zero (byte shift left) 05 - SHR shift right, fill with zero (byte shift right) 06 - Load data from routine specified by AC1 into buffer specified by AC0 (maximum of 256 bytes will be loaded from the routine) 07 Load internal data as specified in AC1 into buffer specified by AC0 (maximum of 256 bytes). If less than 256 bytes the remaining bytes in 256 byte buffer shall be set to $00). Only data entries $41 (VIN), $44 (Tire Type), $45 (TPM tire placard data), $46 (Diesel Injector Adjustment data), $47 (Transfer Case B-Cal value), $48 (Key Fob data) and $49 (Engine Serial Number) are currently considered valid entries for this op-code. Specifying other data is treated as an invalid exception and results in termination with error of the utility file. Currently, this Operation is ONLY supported by the vehicle assembly plant programming. Use of this exception in service is invalid and results in termination with error of the utility file. 08 Copy data contents from the buffer specified in AC1 to the buffer specified in AC0 AC3: Exceptions: XX - Bit Mask used if AC2 < 04 XX Cylinder number if AC2 = 07 and AC1 = $46. A cylinder value of 0 will load IMA data for all cylinders into the buffer. A non zero value will cause the data for that cylinder to be copied into the buffer. This is valid for vehicle assembly plant programming only. Key Fob number if AC2 = 07 and AC1 is $48. A non zero value will cause the data for that particular fob (e.g fob 1 or fob 2) to be copied into the buffer. A value of 0 will copy fob data for all fobs into the buffer. . This is valid for vehicle assembly plant programming only. Pseudo Code: XX 54 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
Identify Storage Buffer specified by AC0
Page
183
(continued) If AC2 is $08 (Copy the data from one buffer to another) Copy the complete set of data from storage buffer ID (AC1) into storage buffer (AC0) Else If AC2 is $06 (Load routine data into Data Buffer specified by AC0) Read routine data based on Routine # (AC1) Store the routine data into storage buffer (max. 256 bytes) Else If AC2 is $07 (vehicle assembly plant programming only) (Load appropriate internal data into Data Buffer specified by AC0) Else Change storage buffer data using operation indicated by AC2 (use AC1 and AC3 information appropriately) Endif Goto step specified in G1 Typical Interpreter Line: Step 06 Op-Code 54 Action Fields 00 01 00 01 Goto Fields 00 00 00 00 00 00
00 07
00 00
Page
184
55 Op-Code: Evaluate RPO (for use in vehicle assembly plants only)

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The 55 Op-Code compares an ASCII RPO string stored in the routine section of the utility file against the option content of the vehicle. If the comparison evaluates to true (option content matches the option string) then the next step executed will be the one in G1. If the comparison fails then the next step executed is the one in G3. Since Service does not have access to RPO data in the field, dealership tools will always jump to the instruction in G5. Note: The first (G0), third (G2), and 5 (G4) bytes of the Goto Fields are always set to 0x00 because they are not used (don't cares).
th
Action Fields: AC0: AC1: Use RPO data from the routine indicated in this byte Format Byte: 00 = RPO strings formatted using the General Assembly Test System (GATS) option processing format (see appendix H for examples). 01-FF reserved for future use. 00 - Not Used 00 - Not Used
AC2: AC3:
Pseudo Code: XX 55 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 In Vehicle Assembly plants the following logic is executed: Obtain RPO string from routine indicated by AC0 Compare RPO string against vehicle build data If compare succeeded Goto step specified in G1 Else Goto step specified in G3 In Service the following logic is executed: Goto step specified in G5 Typical Interpreter Line: Step 06 Op-Code 55 Action Fields 01 00 00 00 Goto Fields 00 29 00 35 00 00
00 07
00 00
Page
185
56 Op-Code: Interpreter Identifier

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The 56 Op-Code is used to branch to a specific action which may be required only in Service (GM CCA GADE), Vehicle Assembly Plant (AVG), or the FCP (Connected Vehicle). Note: The first (G0), the third (G2) and the fifth (G4) bytes of the Goto Fields are always set to 0x00 because they are not used (don't cares). Action Fields: AC0: AC1: AC2: AC3: 00 - Not Used 00 - Not Used 00 - Not Used 00 - Not Used
Pseudo Code: XX 56 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 If the Service Interpreter is being run (DPS and SPS) Goto step specified in G1 Else if the Manufacturing Interpreter is being run (Vehicle Assembly Plant Tool) Goto step specified in G3 Else if the FCP Interpreter is being run (Connected Vehicle FCP) Goto step specified in G5 Endif Typical Interpreter Line: Step 06 Op-Code 56 Action Fields 00 00 00 00 Goto Fields 00 09 00 11 00 00
00 07
00 00
Page
186
EE Op-Code: End with ERROR

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The EE Op-Code is used to signal the tool programming software that an error has occurred. The Interpreter will end processing and return to the main software. The main software will then process any error codes that were set from previously executed and failed OpCodes. Action Fields: AC0: AC1: AC2: AC3: 00 - Not Used 00 - Not Used 00 - Not Used 00 - Not Used
Pseudo Code: End reprogramming and return to the main software for error processing. Typical Interpreter Line: Step 98 Op-Code EE Action Fields 00 00 00 00 Goto Fields 00 00 00 00 00 00
00 00
00 00
Page
187
F1 Op-Code: Set Global Memory Address

Supported By: UART Interpreter 0 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The F1 Op-Code is used to set a global memory address for use in applicable Service Requests. The global memory address can be used when Op-Codes require address information and the normal address is not correct. To use the global address information in an Op-Code, an F1 must be included in the Interpreter instructions prior to the Op-Code that is going to use the global address information. The global address information can be changed as many times as necessary during a programming event. Note: The first (G0) byte of the Goto Field is always set to 0x00 because it is not used (don't care). Action Fields: AC0: AC1: AC2: AC3: MidHigh byte of address MidLow byte of address Low byte of address High byte of address (allows for a 4 byte address value)
Pseudo Code: XX F1 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9
MidHigh byte of global address equals AC0 MidLow byte of global address equals AC1 Low byte of global address equals AC2 High byte of global address equals AC3 Goto step specified in G1 Typical Interpreter Line: Step 08 Op-Code F1 Action Fields 2F FF F0 00 Goto Fields 00 00 00 00 00 00
00 09
00 00
Page
188
F2 Op-Code: Set Global Memory Length

Supported By: KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The F2 Op-Code is used to set a global memory length for use in applicable Service Requests. The global memory length can be used when Op-Codes require length information and the normal length is not correct. To use the global memory length information in an Op-Code, an F2 must be included in the Interpreter instructions prior to the Op-Code that is going to use the global memory length information. The global memory length information can be changed as many times as necessary during a programming event. Note: The first (G0) byte of the Goto Field is always set to 0x00 because it is not used (don't care). Action Fields: AC0: AC1: AC2: AC3: MidHigh byte of length MidLow byte of length Low byte of length High byte of length (allows for a 4 byte memory length value)
MidHigh byte of global length equals AC0 MidLow byte of global length equals AC1 Low byte of global length equals AC2 High byte of global length equals AC3 Goto step specified in G1 Typical Interpreter Line: Step 08 Op-Code F2 Action Fields A0 00 00 Goto Fields 00 00 00 00 00 00
01
00 09
00 00
Page
189
F3 Op-Code: Set Global Header Length

Supported By: Class 2 Interpreter 1 GMLAN Interpreter 3 Description: The F3 Op-Code is used to set a global header length for use in applicable Service Requests. The global header length can be used when Op-Codes require header length information and the normal header length is not correct (defaults to zero). To use the global header length information in an Op-Code an F3 must be included in the Interpreter Instructions prior to the Op-Code that is going to use the global header length information. The global header length information can be changed as many times as necessary during a programming event. Note: The first (G0) byte of the Goto Field is always set to 0x00 because it is not used (don't care). Action Fields: AC0: AC1: AC2: AC3: MidHigh byte of header length MidLow byte of header length Low byte of header length High byte of header length (allows for a 4 byte header length value)
MidHigh byte of global header length equals AC0 MidLow byte of global header length equals AC1 Low byte of global header length equals AC2 High byte of global header length equals AC3 Goto step specified in G1 Typical Interpreter Line: Step 08 Op-Code F3 Action Fields 00 14 00 Goto Fields 00 00 00 00 00 00
00
00 09
00 00
Page
190
F4 Op-Code: Ignore Responses for Milliseconds

Supported By: KWP2000 Interpreter 2 Description: The F4 Op-Code is used to ignore responses being received within a specified time frame. This feature is required to avoid request/response inconsistencies caused by controllers responding with more than one positive or negative response (other than negative $78). Note: The first (G0) byte of the Goto Field is always set to 0x00 because it is not used (don't care). Action Fields: AC0: AC1: AC2: AC3: High byte of time frame (milliseconds) Low byte of time frame (milliseconds) $00 - Not used $00 Not used
Calculate time frame by (AC0 * 256) + AC1 Do until time frame expired Receive response and disregard End Do processing Goto step specified in G1 Typical Interpreter Line: Step 19 Op-Code F4 Action Fields 01 2C 00 00 Goto Fields 00 00 00 00 00 00
00 20
00 00
Page
191
F5 Op-Code: Override the Utility File Message Length Value

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The F5 Op-Code is used to override the utility file header value that contains the number of data bytes in a message (header positions $16 - $17). This will allow utility files to be constructed so that varying calibrations can be downloaded with different data message lengths. In addition, this Op-Code can be used to revert back to the original number of data bytes in a message, defined within the original utility file header. The new message length value is permanent, for the single execution of the utility file, until a subsequent F5 Op-Code is executed. (I.e. The new message length value will be used for all subsequent download OpCodes where that Op-Code specifies the use of the utility file message length.) Caution: For utility files that contain retry logic where processing is returned back to a previous calibration download step, then the corresponding message length value may also need to be reset back to its correct value.
Note: The first (G0) byte of the Goto Field is always set to 0x00 because it is not used (don't care). Action Fields: AC0: AC1: AC2: AC3: High byte of data message length Low byte of data message length 00 Not Used 00 Not Used
If the Length is Zero (AC0=00 and AC1=00) Set the Utility File Data Message Length to the original utility file value Else Set the Utility File Data Message Length to the value defined by AC0 and AC1 ((AC0 * 256) + AC1) Endif Goto step specified in G1 Typical Interpreter Lines: Switch to new Data Message Length (0x0480) Step Op-Code Action Fields 08 F5 04 80 00 00
00 09
Goto Fields 00 00 00 00 00 00
00 00
Revert back to the default Data Message Length (defined within the utility file) Step Op-Code Action Fields Goto Fields 0A F5 00 00 00 00 00 0B 00 00 00 00 00 00
00 00
Page
192
F7 Op-Code: No Operation Op-Code

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The F7 Op-Code is for NO operation. These lines in the Utility File are used as filler. In the case that the line is the destination of a Goto Field it will continue with the next step. Note: All Action Fields and Goto Fields are 0x00 (don't care).
Pseudo Code: XX F7 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Goto next step number (Example: If the current utility file step is 09, then the next step executed will be 0A.) Typical Interpreter Line: Step 09 Op-Code F7 Action Fields 00 00 00 00 Goto Fields 00 00 00 00 00 00
00 00
00 00
Page
193
F8 Op-Code: Goto Field continuation

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The F8 Op-Code is used for continuation of the Goto Fields from the previous step. If an 'F8' Op-Code is the destination of a goto field an Interpreter error will occur. Action Fields: AC0: AC1: AC2: AC3: 00 - Not Used 00 - Not Used 00 - Not Used 00 - Not Used
Pseudo Code: XX F8 AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 If this Op-Code is used as a continuation of the goto fields the Interpreter will check to see if the F8 Op-Code is present before checking the goto fields. If the F8 is not present an Interpreter error will occur. If a previous utility file step attempts to GOTO a step with Op-Code $F8, then an Interpreter error will occur. Typical Interpreter Line: Step 08 09 Op-Code C0 F8 Action Fields 01 39 F4 02 00 00 00 00 Goto Fields 05 0D 04 0E FD 20 15 12 01 0F FF 99 00 00 00 00
06 11 AA 12
Page
194
FB Op-Code: Set and Decrement Counter

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The FB Op-Code is used to set and decrement loop counters. Action field 0 (AC0) is used to identify the counter and action field 1 (AC1) is for the loop limit. There is a maximum of 20 loop counters that can be active at one time. Note: The first (G0) and the third (G2) bytes of the Goto Fields are always set to 0x00 because they are not used (don't cares). Action Fields: AC0: AC1: AC2: AC3: Counter ID: (Valid counter ID's are: 0x00 0x13) Loop limit 00 - Not Used 00 - Not Used
Pseudo Code: XX FB AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 If the Counter Value is $FF (counter reset) Load the counter ID and set the loop limit Endif Decrement the Counter Value If the Loop Counter Is Greater Than Zero Goto step specified in G1 Else Goto step specified in G3, counter has expired Endif Typical Interpreter Line: Step 98 Op-Code FB Action Fields 01 03 00 00 Goto Fields 00 0D 00 00 00 00
00 10
00 00
Page
195
FC Op-Code: Delay for ?? Seconds/Minutes

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The FC Op-Code is used for timing purposes. The Op-Code uses Action 0 as the number of seconds to pause before processing the step specified in goto field 1 (G1). Note: The first (G0) byte of the Goto Field is always set to 0x00 because it is not used (don't care). Action Fields: AC0: AC1: Number of Seconds/Minutes to Pause (Hex value) Protocol: Class 2 00 - No Tester Present messages will be sent during the delay 01 - Send Tester Present messages during the delay Protocol: All Other 00 - Not Used (Default: Tester Present messages will be sent) 00 - Not Used Exceptions: 00 - AC0 will be in seconds 01 - AC0 will be in minutes
AC2: AC3:
Pseudo Code: XX FC AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 Pause for AC0 Seconds/Minutes (based on AC3) If the communication protocol is Class 2 If AC1 is 01 Send Tester Present messages during the delay time Endif Else Send Tester Present messages during the delay time Endif Goto step specified in G1 Typical Interpreter Line: Step 08 Op-Code FC Action Fields 01 00 00 00 Goto Fields 00 0A 00 00 00 00 00 00 00 00
Page
196
FD Op-Code: Reset counter

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The FD Op-Code is used to reset counters. The counter with ID specified in action field 0 will be set to negative one ($FF) and the step in the first goto field will be executed next. If AC0 is set to $FF then all counters are reset to negative one ($FF). Note: The first (G0) byte of the Goto Field is always set to 0x00 because it is not used (don't care). All counters are reset by default before a programming session. Op-Code $FD is needed when a counter is reused in the same programming session. Counters are NOT reset by default between part 1 and part 2 of a GMLAN utility file. Action Fields: AC0: AC1: AC2: AC3: ID of Counter to reset (Valid counter ID's are: 0x00 0x13 for individual counters or 0xFF to reset all counters.) 00 - Not Used 00 - Not Used 00 - Not Used
Pseudo Code: XX FD AC0 AC1 AC2 AC3 G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 If AC0 is $FF Reset all loop counters (set the value of each loop counter to 0xFF) Else Reset loop counter with ID of AC0 (set the value to 0xFF) Endif Goto step specified in G1 Typical Interpreter Line: Step 08 Op-Code FD Action Fields 06 00 00 00 Goto Fields 00 00 00 00 00 00
00 0B
00 00
Page
197
FF Op-Code: End with SUCCESS

Supported By: UART Interpreter 0 Class 2 Interpreter 1 KWP2000 Interpreter 2 GMLAN Interpreter 3 Description: The FF Op-Code is used to signal the reprogramming software that the device has been reprogrammed successfully. The Interpreter will end processing and return a success to the main program. Note: To eliminate any confusion, the programming status progress bar will be incrementally updated up to 100 percent upon the execution of this OpCode. For a 2-part utility file, the update will take place in part 2 of the utility file. Action Fields: AC0: AC1: AC2: AC3: 00 - Not Used 00 - Not Used 00 - Not Used 00 - Not Used
Pseudo Code: End reprogramming and return success Typical Interpreter Line: Step 98 Op-Code FF Action Fields 00 00 00 00 Goto Fields 00 00 00 00 00 00 00 00 00 00
Page
198
System Errors and Op-Code Failures

Interpreter system errors will be assigned a global error number when they occur. This error number will be displayed along with a brief description. Below is a list of the current Interpreter system errors and descriptions (the descriptions may not match the screen text): 100 - The user requested to quit from the No Communications screen. 101 - Communications failed (maximum retry is three). 102 - The Utility file header contained an Interpreter type that is not supported. 103 - The Goto field of an interpreter step leads to a No Operation Op-Code. 104 - Not used. 105 - Could not find the prolog in the routine section of the Utility file. 106 - Could not find the routine in the routine section of the Utility file. 107 - Invalid storage ID specified in the Interpretive Information. 120 - Encountered a step 00 in the Interpretive Information. 121 - Offset to device routines points beyond the end of the Utility file. 122 - Invalid Section ID for file to download. 123 - Loop step sent to an EE Op-Code on first pass. 160 - Fatal Programming Error - Attempt to program while engine is running or vehicle speed exceeds limit. 161 - Fatal Programming Error - Invalid module ID sent to module. 166 - Fatal Programming Error - Failure to program to zero. 169 - Fatal Programming Error - Failure to Erase. 170 - Fatal Programming Error - Device /Manufacturer code not supported. 171 - Fatal Programming Error - Devices not compatible. 172 - Fatal Programming Error - Security problem. 173 - Fatal Programming Error - Flash reprogram error. 174 - Fatal Programming Error - Checksum fault. 175 - Fatal Programming Error - Processor reset. 213 - Reprogramming Attempt has failed. 281 - Error trying to open a calibration file. 297 - Reprogramming Attempt has failed. 298 - Reprogramming Attempt has failed. If an Op-Code fails during the programming process the Step and Op-Code that failed will be displayed with a brief description of what occurred. All error codes are prefaced by the letters SPS before they are displayed to the user. For example: SPS05D0 - Invalid response received from the device. The above error code indicates that a failure occurred during step 05, which was attempting a D0 - Mode 6 Download Calibration/Software File. The complete list of reprogramming error codes and descriptions will be included in a later version of this document. Disclaimer: Not all vehicle protocols are setup to report these global error code conditions. In addition, not all SPS applications utilize these error codes for displaying corresponding error messages to the user.
Page
199
Procedure for Adding New Op-Codes or Exceptions to Existing Op-Codes

When new devices are released for production, new Op-Codes and add exceptions to existing Op-Codes may be required. The Op-Codes and their functionality need to be included in the SPS software before being included in the interpreter instructions of a Utility File. To ensure the timing of changes, the Development Engineers from the controllers supplier will have to work closely with the Systems Engineers at GM Customer Care & Aftersales. A formal procedure has to be created, to ensure that the development process is structured and kept under control. The supplier must provide the GM Customer Care & Aftersales SE with a complete description of the Op-Codes exact functionality. The description must contain a byte-by byte breakdown of how to build the message as well as a byte-by byte description of all the possible responses (for an example see CD-1024). The detail of the request should be comparable to the Pseudo Code sections of the Op-Code descriptions. The GM Customer Care & Aftersales SE will review the request and decide whether a new OpCode or an exception to an existing Op-Code is required. After the Op-Codes/exceptions have been created, a new software package will be available for testing. The Op-Code updates will be documented and tested by the supplier and GM Customer Care & Aftersales personnel. Provided the new software works as specified the new interpreter will be released for production. Any changes or additions to the Op-Codes will result in updates to this document. In some cases a request for change may be generated by individuals outside of the ECU development area, for these cases the requirements are the same. The described interactions will be between the requesting group and GM Customer Care & Aftersales.
Prior to release of any interpreter/documentation updates any affected groups that use an interpreter-based software must be notified. The key to the process is the detail of the request from the engineering group. If the request is lacking in any way, GM Customer Care & Aftersales personnel will not be able to accurately include the OpCode in the Interpreter.
Note: Once an Interpreter is released, GM Customer Care & Aftersales cannot modify an existing OpCode/exception combination unless the original functionality is unaffected. It is GM Customer Care & Aftersales responsibility to verify that the existing support provided by the Op-Code still works properly. If this is not possible, for any reason, then the Op-Code/exception combination cannot be changed. GM Customer Care & Aftersales should always plan to create a new Op-Code or a new exception to an existing Op-Code when new Interpreter functions are needed. This rule can only be violated when the change has NO impact on existing Interpreter Op-Code function.
Page
200
Appendixes
A - UART Interpreter Examples B - Class 2 Interpreter Examples C - Keyword Protocol 2000 Interpreter Examples D - Abbreviations and Acronyms E - Revision Log F - Related Documents
Page
201
Appendix A - UART Interpreter Examples

The following lines of interpretive code are examples of how lines in the interpretive section of a Utility File are used by the tools. The examples are not in a particular order and are strictly for explanatory purposes. Step 01 Op-Code 05 Action Fields F4 01 00 00 AA 02 Goto Fields 05 04 09 05 FF 06 00 00
The first step is a 05 Op-Code (Ram Download Request). The tool will send an ALDL mode 5 message. The 01 exception tells the interpreter to wait for an F0 poll before sending the mode 5 message. For this example assume an AA response was received from the device, after the mode 5 message was sent, the interpreter would jump to the step specified after the AA in the goto fields (step 02). If a 05 response were received, the interpreter would jump to step 04. A 09 response would jump to step 05 and any other responses would jump to step 06. Step 02 Op-Code C0 Action Fields 02 03 F4 00 AA 03 Goto Fields 05 04 FF 06 00 00 00 00
This step is a C0 Op-Code that is used to Download Routines to RAM and then execute the routines. The line instructs the interpreter to send routine 02 to device ID F4 using routine 03 as the prolog. Prologs are only used when a routine is larger then the maximum routine packet size. Prologs generate responses for the device as the pieces of a routine are being downloaded to RAM. All of the routines are contained in the routine section of the Utility Files. After all of the routine is downloaded the device will execute the routine and a response will be returned. Assume that an AA is returned from the device, so step 03 (Goto field 1) will be the next step interpreted. Step 03 Op-Code D0 Action Fields 01 39 F4 01 06 07 Goto Fields 15 04 FF 05 00 00 00 00
The next Op-Code to execute is D0 (Download Calibration / Software file). The tool will send to device F4 the file with ID 01 and since the exception 01 is specified, 39 will be the prolog. After the file is downloaded to the device a response will be returned to the tool. Assume a 15 is returned, the Goto field 2 will be the next step executed (04). This return is an error and will cause the process to loop. See the next Op-Code. If a 06 was returned then the programming event would be a success and the process would end (see step 07). If any other return value were returned then Goto step 3 (05) would be executed. This will signal that the programming event has failed and the module should to be replaced (see step 05). Step 04 Op-Code FB Action Fields 01 03 00 00 00 02 Goto Fields 00 05 00 00 00 00 00 00
If this step is executed the counter 01 is set to 03 and the interpreter will jump to the step specified in Goto step 1 (02). Each subsequent time this step is executed, counter 01 will be decremented by one. If the counter is above zero the first Goto step (02) is executed again. If the counter is zero, meaning that the counter has expired, the step specified in Goto step 2 (05) is executed. Step 05 Op-Code EE Action Fields 00 00 00 00 00 00 Goto Fields 00 00 00 00 00 00 00 00
This step is executed if an error has occurred during the programming process and the replace module message should be displayed. Step 06 Op-Code EE Action Fields 01 00 00 00 00 00 Goto Fields 00 00 00 00 00 00 00 00
This step is executed if an error has occurred during the programming process. The 01 in AC0 indicates that a message instructing the user to replace the control module should be displayed on the error screen. Step 07 Op-Code FF Action Fields 00 00 00 00 00 00 Goto Fields 00 00 00 00 00 00 00 00
This step indicates a successful completion of the programming process.
Page
202
Appendix B - Class 2 Interpreter Examples

The following lines of interpretive code are examples of how lines in the interpretive section of a Utility File are used by the tools. The examples are not in a particular order and are strictly for explanatory purposes. Step 01 Op-Code 01 Action Fields F1 00 00 00 00 02 Goto Fields 00 00 00 00 00 00 00 00
The first step is a 01 Op-Code (Setup Global Variables). The tool sets the global tester ID to the value in AC0 ('F1'). The zero in AC1 instructs the tool to turn the periodic transmission of 3F messages off. The step then goes to the step indicated by the value in G1 ('02'). Step 03 Op-Code 28 Action Fields 10 00 03 00 68 04 Goto Fields FD 14 FF 16 00 00 00 00
Step 3 is an example of an Op-Code 28, which is used to disable normal communications. The 10 in AC0 is used by the tool as the target address of the mode 28 message. The 00 in AC1 instructs the tool to disable normal class 2 communications. The 03 in AC2 is used as a time-out (3 * 50ms) value used while waiting for multiple devices to respond to the mode 28 message. The variable time-out should be used whenever a message is sent to all devices ("FE") and the default time-out of 250ms is not acceptable. The tool will keep looping while it receives successful mode 28 responses or until the time-out value is exceeded without another response being returned. Step 09 Op-Code A0 Action Fields 10 FE 05 00 AA 0A Goto Fields BB 12 FF 0D 00 00 00 00
Step 9 is an Op-Code A0 that is used to request high-speed communications. The 10 is used by the tool as the target address of the mode A0 message. The 05 in AC2 is used by the tool to determine the number of 50ms increments to wait (5 * 50ms) for all devices to respond to the mode A0 message. In this case, the tool will process all responses until an error is received or 250ms have elapsed without another response. The 00 in AC3 instructs the tool to look at response byte 5 for the next goto step to execute. Step 1A Op-Code B0 Action Fields 10 02 00 83 73 26 Goto Fields 74 28 FF 29 00 00 00 00
Step 1A is an example of an Op-Code B0 which is used to download routines to RAM using mode 36 messages. The value in AC0 is used as the target address in the mode 36 message. The value in AC1 indicates the routine number, from the routine section of the Utility File, to download to the control module. The tool parses through the Utility File to find the routine corresponding to the value in AC1. The value in AC3 is used to determine the maximum packet length and transmit type to use in the message. Since the value is 83, which is greater than 80, the tool uses 4000 bytes as the maximum packet length. The 83 also indicates to the tool to send the mode 36 messages with a transmit type of download and execute. Step 06 Op-Code B4 Action Fields 10 01 03 01 73 07 Goto Fields FF 09 00 00 00 00 00 00
Step 06 is an example of an Op-Code B4 that is used to download calibrations to the control module using mode 36 messages. The value in AC0 is used as the target address in the mode 36 message. The value in AC1 corresponds to the calibration ID for the calibration to be downloaded. The value in AC2 identifies the routine number to use as a data prolog while downloading the calibration to the control module. The value in AC3 is used to determine the type of download strategy to use during programming. In this example, 01 indicates the tool should use car platform strategies with two byte addressing. Step 07 Op-Code EE Action Fields 01 00 00 00 00 00 Goto Fields 00 00 00 00 00 00 00 00
This step is executed if an error has occurred during the programming process. The 01 in AC0 indicates that a message instructing the user to replace the control module should be displayed on the error screen. Step 08 Op-Code FF Action Fields 00 00 00 00 00 00 Goto Fields 00 00 00 00 00 00 00 00
This step is indicates a successful completion of the programming process.
Page
203
Appendix C - KWP2000 Interpreter Example Example Utility File (with Control Routines) 0 0 0 0 0 7 F 0 0 7 0 A 0 0 0 5 4 F 1 0 5 0 9 8 0 0 3 0 0 0 0 3 0 4 0 0 0 1 7 9 0 0 4 5 0 0 C 0 0 F 0 0 0 5 9 0 1 1 0 3 F 0 0 0 E 0 0 0 0 0 0 0 0 0 0 8 8 0 1 3 0 0 9 0 0 0 6 A 0 1 F 0 0 0 0 0 0 E B 0 0 F 0 0 0 8 0 0 5 3 F F 0 0 0 0 F 0 0 C 5 7 1 9 0 0 0 B 0 0 B 6 3 0 0 0 7 0 0 0 0 7 3 4 0 0 4 1 0 1 0 0 2 4 9 0 0 2 0 0 0 0 0 3 9 0 0 7 6 0 3 0 0 6 0 0 0 0 F 0 0 0 0 3 0 0 0 2 D 0 0 0 0 5 0 0 0 0 0 0 0 0 0 3 0 2 0 0 8 0 0 0 0 6 0 0 0 0 F 0 0 0 4 D 0 0 0 0 F 7 0 0 0 E 0 0 0 0 0 9 0 0 0 A 0 0 0 0 9 3 4 0 0 4 0 0 0 6 0 0 0 0 0 3 0 0 3 7 0 1 0 0 0 2 0 0 8 0 0 0 0 0 1 4 2 0 3 5 0 0 9 0 A E 0 0 1 3 0 0 0 0 8 D 0 0 0 7 0 0 0 A 9 A B 0 0 0 0 0 0 F 3 C 8 0 0 8 0 0 0 F 2 4 0 0 0 3 0 7 0 0 A 3 0 0 0 3 6 3 0 0 5 6 0 0 0 0 3 0 0 0 B 4 2 0 0 8 4 A 0 0 3 5 0 0 C F 0 F 0 0 9 0 0 2 3 F 0 D 0 0 9 0 0 8 0 0 0 0 0 0 C 0 0 1 4 9 0 8 0 0 D 0 2 1 F 0 0 3 0 0 D 2 0 0 F 0 0 6 9 0 4 0 0 0 0 0 0 0 E 0 4 0 0 0 9 0 0 8 E 0 E 0
Following are the explanations of how a reprogramming tool would flow through the lines of the Interpreter Instructions from the example Utility File above. The first highlighted section above represents the Header Information. The middle section (not highlighted) contains the Interpreter Instructions. The second highlighted section is the Control Routine section. In this example the Control Routine section contains two routines. The example data is not for a particular ECU it is strictly for explanatory purposes. The data in the Interpreter Instructions is hexadecimal values.
Step XX 01
Op-Code OP 01
Action Fields AC0 AC1 AC2 AC3 10 F1 00 00
Goto Fields G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 00 02 00 00 00 00 00 00 00 00
Step $01 is a 01 Op-Code (Setup Global Variables). The tester sets the global target byte to the value in AC0, or $10, and the global source byte to the value in AC1, or $F1.
Step XX 02
Op-Code OP 81
Action Fields AC0 AC1 AC2 AC3 10 00 00 00
Goto Fields G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 C1 03 FF 09 00 00 00 00 00 00
Step $02 is an example of a Start Communications Op-Code (81). If the positive response service ID of $C1 is returned this step goes to step $03. For any other response values the tester uses the $FF goto value and jumps to step $09.
Step XX 03
Op-Code OP 83
Goto Fields G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 C3 04 FF 09 00 00 00 00 00 00
Step $03 is an example of an Access Communication Parameter Op-Code (83) which is used to setup the optimum reprogramming times. If the positive response service ID of $C3 is returned this step goes to step $04. For any other response values the tester uses the $FF goto value and jumps to step $09.
Step XX 04
Op-Code OP 27
Goto Fields G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 67 05 37 08 33 08 FF 09 00 00
Step $04 is an example of a Security Access Request Op-Code (27) which is used to unlock an ECU for reprogramming. The value in AC0 represents the algorithm that is used on the seed to determine the key. The tester uses the response bytes to determine the next step to execute. If the positive response byte service ID of $67 is returned this step goes to step $05. If the security request fails for either a "required time
Page
204
(continued) delay not expired" or "security access denied" error this step jumps to step $08. For any other response values the tester uses the $FF goto value and jumps to step $09.
Step XX 05
Op-Code OP 31
Goto Fields G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 71 06 FD 08 FF 09 00 00 00 00
Step $05 is an example of a Start Routine by Local Identifier Op-Code (31). This step is used to start executing a routine that is embedded in the ECU's memory. The local Identifier of the routine to execute is contained in AC0; this example starts routine $03. If the positive response service ID of $71 is returned this step goes to step $06. If a "No Communications" error occurred then this step goes to $08. For any other response values the tester uses the $FF goto value and jumps to step $09.
Step XX 06
Op-Code OP 34
Goto Fields G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 74 07 FF 09 00 00 00 00 00 00
Step $06 is an example of a Download Request Op-Code (34). If a positive response service ID of $74 is returned this step goes to step $07. For any other response values the tester uses the $FF goto value and jumps to step $09.
Step XX 07
Op-Code OP 93
Goto Fields G0-G1 G2-G3 G4-G5 G6-G7 G8-G9 73 0A FD 08 36 08 FF 09 00 00
Step $07 is an example of a Transfer Calibration Op-Code (93) which is used to transfer calibration files to an ECU. This step will transfer the calibration with a calibration ID equal to the value in AC0 ($01). If the positive response byte $73 is returned indicating the ECU is ready for the next block this Op-Code continues with the transfer until the entire calibration is transferred to the ECU. When the calibration is completely transferred if a positive response code $73 is returned this step goes to step $0A. If either a "No Communications" or a "Block Transfer Data Checksum" error occurs then this step goes to $08. For any other response values the tester uses the $FF goto value and jumps to step $09.
Step XX 08
Op-Code OP FB
Step $08 is an example of a Set and Decrement Counter Op-Code (FB) which is used to perform loop processing in a Utility File. This Op-Code sets or decrements (if counter was previously set) counter $01 (AC0). This step will goto step $04 (G1) if counter $01 is greater than zero otherwise this step will goto step $09 (G3) if counter $01 is zero. To reset a counter, so it can be reused for another loop, a $FD Op-Code should be issued for the counter number to reset.
Step XX 09
Op-Code OP EE
Step 09 is an End with Error Op-Code (EE) that is used to indicate a reprogramming event ended with an error. The $01 in AC0 is used to toggle the display of a message instructing the user to replace the ECU on the error screen ($01 - display message, $00 - do not display message).
Step XX 0A
Op-Code OP FF
This step is an example of a Programming Successful Op-Code (FF) that is used to indicate a successful completion of a reprogramming event.
Page
205
Appendix D GMLAN Utility File Guidelines
GMLAN Utility File Guidelines

Version 1.3 Rick Kacel
Page
206
Revision History (Appendix D: GMLAN Utility File Guidelines)
Version
1.0 1.1 1.2 1.3 1.4
Date 20Aug2004 19Aug2004 24Aug2004 24Sept2004 06Mar2006
Author Rick Kacel Andrea Merrick John Cline Erwin Frank Setterlun Initial Release Added assumption
Comments
Fixed Flowcharts and miscellaneous changes Several Modifications 256 Byte internal data buffers update.
Related Documents GMW3110 GMLAN Enhanced Diagnostic Test Mode Specification Version 1.4, 1.5Service Programming System (SPS) Interpreter Programmers Reference Manual Version Date: November 13, 2003
Page
207
Assumptions
This file represents the programming of a module with one Operating Software module and 2 Calibration Software modules. Please use this as an example for setting up a utility program.
The ECUs security algorithm number ($00 - $FF) has already been assigned by GM SPO CCA for levels 1&2. The example ECU is a simple, straightforward implementation. The ECU has only one type of Flash memory. A Flash routine, included in the Utility file, is downloaded to the ECU and handles the programming of the Operating software and Calibration modules. The Utility file is being executed to program the ECU either for the first time, or as an update to the Operating software or Calibration modules. If the Operating software for the ECU is downloaded, all Calibration modules for the ECU will be downloaded. This ensures consistency. If one Calibration module needs to be updated, all Calibration modules for the ECU will be downloaded. The VIN number, the Tester Serial number, and the Programming date need to be programmed into ECU memory after a successful programming event. The ECU supports the GMLAN CAN protocol. The ECU sends a $7F $31 response if the software part number is requested and the software has not been programmed in the box. The Module IDs of the calibration files should be assigned to align with the order the files will be downloaded. Module ID $01 is reserved for the primary Operational Software as stated in GMW311
Page
208
Programming Flow
Utility File Start
OpCode - $34
Step $08
Retry3
PreSteps
The programming application tool executes several GMLAN service messages before the first Interpreter instruction is executed. See the GMLAN message flow diagrams in this document or GMW 3110 for more information.
RequestDownload $34 Service
Prepare to Download Operating Software Error
OpCode - $B0 TransferData $36 TransferData $36 Service
Step $09
Retry3
Download the Operating Software Error
ProgCal Step $01

Set Target and Source Address
Step $0A Set Global Header Length
Start
OpCode - $27
SecurityAccess $27 Service SPSRequestSeed SecurityAccess $27 Service SPSSendKey
Step $02
Perform Seed & Key
Retry1 Error
OpCode - $34 RequestDownload $34 Service
Step $0B
Retry3
Prepare to Download Error 1st Calibration
SetUp
Step $03
Retry3
OpCode - $B0 TransferData $36 Service
Prepare to Download Flash Routine #1 Error
Step $0C Download the 1st Calibration
Retry3 Error
Step $04
Retry3
Step $0D
Retry3
Download Flash Routine #1 to RAM Error
Prepare to Download Error 2nd Calibration
Retry3 OpCode - $1A

ReadDataByIdentifier $1A Srvc.
Step $05
Request the Operating Software Part Number
Error Not Programmed
Step $0E
Download the 2nd Calibration
Retry3 Error
ProgState
ProgCal Values Equal
Step $06
Evaluate the Part Number
OpCode - $A2
ReportProgrammedState $A2 Srvc
Step $0F
Retry2
Request the Programmed State Error
Values Not Equal
ProgOp
Step $07
Set Global Header Length
Step $10
Evaluate Programmed State
Error
ECU Fully Programmed Status Success
Page
209
Executed by the programming application prior to Part 2 of the Utility file Success
ReturnToNormalMode$20 Service
Pre-Step
Reset
Step $1C
Exit Interpreter with Success
Pre-Step
Bus Wakeup (Occurs Automatically by the Programming Tool)
Exit
ReadDataByIdentifier$1A Service DID $BO
Pre-Step
Get CAN IDs
Error Part 2
OpCode - $3B
WriteDataByidentifier$3B Service
Step $11
Write the VIN
Retry4 Error
Step $1D
Exit Interpreter with Error
OpCode - $3B
Step $12
Retry4
Write the WriteDataByidentifier$3B Service Tester Serial Number Error
Exit
OpCode - $3B
WriteDataByidentifier$3B Service
Step $13
Retry4
Write the Programming Date Error
Success
Retry1 Step $14

Initialize Retry Counter& Decrement
Error
Retry2 Step $16

Error
Retry3 Step $18

Error
Retry4 Step $1A

Error
Step $15
Retry Delay for 1 Second
Step $17
Step $19
Step $1B
Jump toStart
Jump toProgState
Jump toSetUp
Jump toPart2
Page
210
Step $01 Set Target and Source Address

The Interpreter uses these values for the programming process. It needs to know the target address (the Diagnostic address) of the ECU being programmed and the source address (the Diagnostic address) of the test tool. This step will place the values into global memory locations for access as GMLAN messages are output and received by the Interpreter.
Action Fields AC0 $11 AC1 $F1 AC2 $00 AC3 $00 G0-G1 00 $02 G2-G3 00 00 Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $01
OpCode $01
OpCode - $01 Setup Global Variables

This step sets up global variables that are used during the programming process. This is an internal Interpreter command that does not output any messages on the GMLAN bus.
Action Fields AC0 Target Address

This is the target address (the Diagnostic address) of the ECU module the tester communicates with. This value MUST be either the value returned in the response to the service $1A DID $B0 request, or the least significant byte of the SPS_TYPE_C CAN ID as described in GMW 3110, Chapter 11.
AC1 Source Address

This is the source address (the Diagnostic address) of the tester that is programming the ECU. This value is not required for GMLAN implementations, but is placed for consistency with other protocols.
AC2 Not Used

Set to $00.
AC3
Set to $00. Goto Fields
Goto Fields G0-G1 (Return Code/Jump To Step Number)

Always a $00 on return. Go to the next step.
G2-G3, G4-G5, G6-G7, G8-G9 Not used
Page
211
Step $02 Start Perform Seed and Key

This step unlocks an ECU by performing the Diagnostic security services on the ECU.
Action Fields AC0 $68 AC1 $00 AC2 $00 AC3 $00 G0-G1 $67 $03 G2-G3 $FD Retry1 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $02
OpCode $27
OpCode - $27 Security Access

This Interpreter command sends out two Diagnostic Commands to the ECU. The first command is Diagnostic service $27 SecurityAccess with subfunction 1 SPSrequestSeed. The ECU returns its seed value to the tester. Next, Diagnostic service $27 SecurityAccess with subfunction 2 SPSsendKey is sent to the ECU that contains the key to unlock the ECU based on the Security Algorithm number that was previously assigned (see assumptions).
Action Fields AC0

Security Algorithm number previously assigned or known in the range of $00 - $FF.
AC1
Set to $00.
AC2 Not used

Set to $00.
AC3
A $00 tells the Interpreter to disable sending the key if the seed returned by the ECU is 0, indicating that the ECU is not currently protected.

If a positive response $67 is received, then go to the next step.
G2-G3 (Return Code/Jump To Step Number)

If response $FD is returned, then a timeout has occurred. Go to Retry1 step.

Wildcard $FF. If any other response is returned, terminate the sequence immediately by jumping to the Error step
G6-G7, G8-G9 Not used
Page
212
Step $03 SetUp Prepare to Download Flash Routine #1 from Utility File
The Flash routine resides within the Utility file archive, and is given a numeric value (1, 2, etc). The routine is downloaded from the Utility file to the ECU, and erases and writes data to the Flash memory device. It is downloaded and placed into RAM by the bootloader software. The flash routine usually has two components: one that erases memory and one that writes memory. The Utility file has information about the length of the routine. The Bootloader has information about each of the components. In some cases the Flash routine is embedded into the Bootloader software and permanently resides in the ECU.
OpCode $34 Action Fields AC0 $00 AC1 $01 AC2 $00 AC3 $00 $74 G1 $04 G2-G3 $FD Retry3 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $03
OpCode - $34 Request Download

This command outputs the Diagnostic service $34 RequestDownload message to the ECU. When it is received by the ECU, the ECU jumps to the Bootloader software (if not already there) and indicates that a download of data is about to occur. This command must be executed prior to the Block Transfer to RAM command.
Action Fields AC0

AC0 is used in the $34 service for the dataFormatIdentifier field. It tells the ECU the format of the data to be downloaded. In this example, the data is unencrypted and uncompressed ($00).
AC1
AC1 is the Routine number identifier so that the Interpreter retrieves the correct Flash routine from the Utility file. In this example the routine number is 1.
AC2
Set to $00
AC3
The upper nibble of AC3 tells the Interpreter where to get the length. In this case it is retrieved from the Routine number specified in AC1 ($0X). The lower nibble of AC3 determines how many bytes represent the address. In this example, the address length is specified by the Utility file header in the Type of Addressing field ($X0).

If a positive response $74 is received continue to the next step.


Wildcard $FF. If any other response is returned, terminate the sequence immediately by jumping to Error step.
Page
213
Step $04 Download Flash Routine #1 from Utility File

Flash Programming Routine 1 is downloaded to the ECU and stored in RAM memory. This Interpreter command outputs a series of Diagnostic service TransferData $36 messages to download the data.
Step $04
OpCode $B0
OpCode - $BO Block Transfer to RAM

This command downloads the specified software module to the ECU. The downloading of data to the module is made up of many Diagnostic service TransferData $36 messages. The number of messages is dependent on the length of the data to download.
Action Fields AC0

Not used when Flash routines are downloaded into the ECU from the Utility File. Set to $00.
AC1
Specifies the Flash routine number to be downloaded. In this example, the Flash routine is embedded in Routine #1.
AC2
The upper nibble specifies the subfunction value for the TransferData $36 service. It determines what action to take after the download is complete. In this example the Flash routine is being downloaded, not executed, so it is set to download only ($0X). The lower nibble determines if the address is incremented or held constant. Since the Flash routines are being downloaded to RAM, the value ($X0) is set to increment the address for storage after every $36 message. The address is incremented by the number of bytes in each download.
AC3
The upper nibble of AC3 tells the Interpreter where to get the start address. In this case it is retrieved from the Routine number specified in AC1 ($0X). The lower nibble of AC3 determines how many bytes represent the address. In this example, the address length is specified by the Utility file header in the Type of Addressing field ($X0).

If a positive response ($76) is received, continue to the next step.


Page
214
Step $05 Request the Operating Software Part Number

Step 5 retrieves the Operating Software Part Number and stores the value in Data Storage #1. This value is used for comparison in the next step to determine if the Operating software needs updating.
Action Fields AC0 $C1 AC1 $01 AC2 $00 AC3 $00 G0-G1 $5A $06 G2-G3 $31 ProgOp Goto Fields G4-G5 $FD Retry3 G6-G7 $FF Error G8-G9 00 00
Step $05
OpCode $1A
OpCode - $1A Read Data By Identifier

This Interpreter command requests data from DIDs in the ECU by invoking Diagnostic service ReadDataByIdentifier $1A. The software part number of the specified ECU is returned.
Action Fields AC0

Set to $C1, which is the corporate DID to retrieve the Operating software part number from the ECU. $C1 specifies software module 1, which is always the Operating software.
AC1
Specifies the buffer in the Interpreter program to store the software part number information. In this example, it is Data Buffer #1.
AC2 Not Used

Set to $00.
AC3
AC3 determines if a 256-byte or a 2-byte data buffer is to be used. In this example, a 256-byte buffer is being used since the part number is more than two bytes.

If a positive response $5A is received, then a part number was retrieved. Continue to the next step.

If a RequestOutOfRange $31 negative response is returned, jump to the programming of the Operating software and skip comparison. The Operating software was never programmed into this ECU.


G8-G9 Not used
Page
215
Step $06 Evaluate the Application Software Part Number Value

Compares the value of the Operating software part number retrieved from the ECU with the Module part number stored in the VIT2 table of the programming application.
OpCode $53 Action Fields AC0 $01 AC1 $01 AC2 $01 AC3 $00 G0-G1 $00 ProgCal G2-G3 $00 $07 Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $06
OpCode $53 Compare Data

This Interpreter command compares the part number retrieved from the ECU and stored in Data Buffer #1 with the part number for Module 1 stored in the VIT2 table. The part number in the VIT2 table is in ASCII format. Please see the Interpreter.doc file for more information on the VIT2 table.
Action Fields AC0

Set this to the Data Buffer to be used in the comparison. In this example, Data Buffer #1 holds the part number retrieved from the ECU.
AC1
Specifies the Module ID to use for the comparison. In this example, the Operating software part number is being compared, so the module ID is always 1.
AC2
Set AC2 to $01 if the part number is reported by the ECU as a 4 byte hex value. Set to $00 if the part number is reported out in ASCII format. In this example, it is reported by the ECU in hexadecimal and must be converted for comparison.
AC3
The value in AC3 tells the Interpreter where to get the part number for comparison. Set to $00 for this example to tell the interpreter to get it from the VIT2 table.

If the values match, then the Interpreter jumps to the step indicated in G1. In this example, the Operating software programming is skipped and the Calibrations modules are programmed.

If the values dont match, then the Interpreter jumps to the step indicated in G3. In this example, the next step is executed, which will begin the programming of the Operating software and Calibration modules.
G4-G5, G6-G7, G8-G9 Not used
Page
216
Step $07 ProgOp Set the Global Header Length

Set the length of the Operating software header that will be sent in the first packet of data to the ECU.
Action Fields AC0 $00 AC1 $00 AC2 $32 AC3 $00 G0-G1 00 $08 G2-G3 00 00 Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $07
OpCode $F3
OpCode $F3 Set Global Header Length

In most cases, this command is not required. This command sets the length of the header for the Operating software. Setting the global header length allows the tool to send a file to the ECU in two parts. The first part is the header whose length is defined by the $F3 op-code, and the second part is the rest of the Operating software. If you don't specify the header length (or set it to 0), then the file is downloaded without a break between the header and the program data. It is sometimes necessary to begin downloading the data with a new mode $36 message at the point in the file where the actual program would begin getting written to flash. One instance where this is needed is if the microprocessor cannot put the header at the beginning of the code space. Certain micros have their interrupt table at the beginning of flash memory. They download the header first, flash program it to memory (or have a duplicate copy embedded in the Operating software) to support reprogramming, and then flash program the Operating software at the beginning on the flash memory.
Action Fields AC0 - AC3

Specifies the length of the header. AC0 MidHigh byte of header length AC1 MidLow byte of header length AC2 Low byte of header length AC3 High byte of header length (allows 4 byte length) In this example the header is specified as $32 bytes long.

Go to the step specified in G1, in this example the next step.
Page
217
Step $08 Prepare to Download the Operating Software

This step prepares the ECU to receive the data associated with the Operating software.
Step $08
OpCode $34
OpCode $34 Request Download

This command outputs the Diagnostic service RequestDownload $34 message to the ECU. When it is received by the ECU, the ECU jumps to the Bootloader software (if not already there) and indicates that a download of data is about to occur. This command must be executed prior to the Block Transfer to RAM command.
Action Fields AC0

AC0 is used in the $34 service for the dataFormatIdentifier field. It tells the ECU the format of the data to be downloaded. In this example, the data is unencrypted and uncompressed.
AC1
AC1 is set to $00 in this example based on the value in AC3.
AC2
Set to $00.
AC3
The upper nibble of AC3 tells the Interpreter where to get the length. In this case its from the header of the Utility file ($1X). The lower nibble of AC3 determines how many bytes represent the length. In this example, the address length is specified by the Utility file header in the Type of Addressing field ($X0).



Page
218
Step $09 Download the Operating Software

The Operating software is downloaded to the ECU and programmed into memory. This Interpreter command outputs a series of Diagnostic service TransferData $36 messages to download the data.
OpCode $B0 Action Fields AC0 $01 AC1 $00 AC2 $01 AC3 $10 G0-G1 $76 $0A G2-G3 $FD Retry3 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $09

This command downloads the specified Operating software to the ECU. The downloading of data to the ECU is made up of many Diagnostic service TransferData $36 messages. The number of messages is dependent on the length of the data to download.
Action Fields AC0

Set to the Module ID number of the data to be downloaded. The Operating software is always set to $01.
AC1
Set to $00. This is not a Routine being downloaded.
AC2
The upper nibble specifies the subfunction value for the TransferData $36 service. It determines what action to take after the download of data is complete. In this example the Operating software is being downloaded, so it is set to download only ($0X). The lower nibble determines if the address is incremented or held constant. In this example, it is held constant ($X1). The ECU is placing the data where it belongs and wants the $36 message to put each block of data into the same location in RAM for processing.
AC3
The upper nibble of AC3 tells the Interpreter where to get the start address. In this case its from the header of the Utility File ($1X). The lower nibble of AC3 determines how many bytes represent the address. In this example, the address length is specified by the Utility file header in the Type of Addressing field ($X0).



Page
219
Step $0A ProgCal Set the Global Header Length

Since step $07 set this to the size of the Operating software header, this will cause the Calibration file header to be downloaded contiguously with the rest of the calibration file.
Action Fields AC0 $00 AC1 $00 AC2 $00 AC3 $00 G0-G1 $00 $0B G2-G3 00 00 Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $0A
OpCode $F3
OpCode $F3 Set Global Header Length

In most cases, this command is not required. In this example, step $07 sets the header length so that the Operating software downloads the header separate from the program data. Setting all the AC fields to a $00 will default the system to a one part download.
Action Fields AC0, AC1, AC2, AC3

Specifies the length of the header. Set to $00 $00 $00 $00 in this example to reset the value.

Go to the step specified in G1, in this example the next step.
Page
220
Step $0B Prepare to Download the First Calibration Module

This step prepares the ECU to receive the data associated with the first Calibration file.
Action Fields AC0 $00 AC1 $00 AC2 $00 AC3 $10 G0-G1 $74 $0C G2-G3 $FD Retry3 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $0B
OpCode $34

This command outputs the Diagnostic service RequestDownload $34 message to the ECU. This command must be executed prior to the Block Transfer to RAM command.
Action Fields AC0

AC1
AC2
Set to $00.
AC3



Page
221
Step $0C Download the First Calibration Module

The first Calibration module is downloaded to the ECU and programmed into memory. This Interpreter command outputs a series of Diagnostic service TransferData $36 messages to download the data.
Action Fields AC0 $02 AC1 $00 AC2 $01 AC3 $10 G0-G1 $76 $0D G2-G3 $FD Retry3 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $0C
OpCode $B0

This command downloads the specified Calibration module to the ECU. The downloading of data to the module is made up of many Diagnostic service TransferData $36 messages. The number of messages is dependent on the length of the data to download.
Action Fields AC0

Set to the Module ID number of the data to be downloaded. The Module ID follows in order after the Operating software Module ID 1. In this case, the value is 2
AC1
AC0 set to $00. This is not a Routine being downloaded.
AC2
The upper nibble specifies the subfunction value for the service TransferData $36. It determines what action to take after the download of data is complete. In this example the first Calibration module is being downloaded, so it is set to download only ($0X).
The lower nibble determines if the address is incremented or held constant. In this example, it is held constant ($1). The ECU is placing the data where it belongs and wants the $36 message to put each block of data into the same location in RAM for processing.
AC3
The upper nibble of AC3 tells the Interpreter where to get the start address. In this case its from the header of the Utility file ($1X). The lower nibble of AC3 determines how many bytes represent the address. In this example, the address length is specified by the Utility file header in the Type of Addressing field ($X0).



Page
222
Step $0D Prepare to Download the Second Calibration Module

This step prepares the ECU to receive the data associated with the second Calibration file.
Action Fields AC0 $00 AC1 $00 AC2 $00 AC3 $10 G0-G1 $74 $0E G2-G3 $FD Retry3 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $0D
OpCode $34

This command outputs the Diagnostic service RequestDownload $34 message to the ECU. This command must be executed prior to the Block Transfer to RAM command.
Action Fields AC0

AC1
AC2
Set to $00.
AC3



Page
223
Step $0E Download the Second Calibration Module

The second Calibration module is downloaded to the ECU and programmed into memory. This Interpreter command outputs a series of Diagnostic service TransferData $36 messages to download the data.
Action Fields AC0 $03 AC1 $00 AC2 $01 AC3 $10 G0-G1 $76 $0F G2-G3 $FD Retry3 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $0E
OpCode $B0

This command downloads the specified Calibration module to the ECU. The downloading of data to the module is made up of many Diagnostic service TransferData $36 messages. The number of messages is dependent on the length of the data to download.
Action Fields AC0

Set to the Module ID number of the data to be downloaded. In this example, the Module ID is 3.
AC1
AC0 set to $00. This is not a Routine being downloaded.
AC2
The upper nibble specifies the subfunction value for the service TransferData $36. It determines what action to take after the download of data is complete. In this example the second Calibration module is being downloaded, so it is set to download only ($0X).
The lower nibble determines if the address is incremented or held constant. In this example, it is held constant ($1). The ECU is placing the data where it belongs and wants the $36 message to put each block of data into the same location in RAM for processing.
AC3
The upper nibble of AC3 tells the Interpreter where to get the start address. In this case its from the header of the Utility file ($1X). The lower nibble of AC3 determines how many bytes represent the address. In this example, the address length is specified by the Utility file header in the Type of Addressing field ($X0).



Page
224
Step $0F ProgState Request the Programmed State

Step $0F requests the programmed status of the ECU and stores it into Data Storage #2. This value is used for comparison in the next step to determine programming was successful.
Action Fields AC0 $02 AC1 $00 AC2 $00 AC3 $00 G0-G1 $E2 $10 G2-G3 $FD Retry2 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $0F
OpCode $A2
OpCode - $A2 Report Programmed State and Save Response

This command outputs the Diagnostic service ReportProgrammedState $A2 message to the ECU. The programmed state of the specified ECU is returned and stored.
Action Fields AC0

Specifies the 2-byte buffer in the Interpreter program to store the programming state information. In this example, it is Data Buffer #2.
AC1, AC2, AC3 Not Used

Set to $00

If a positive response $E2 is received, then the programmed state was returned. Continue to the next step.

If response $FD is returned, then a timeout has occurred. Go to step Retry2.

Page
225
Step $10 Evaluate the Programmed State Value

Compares the 2-byte value of the programmed state in Data Storage 2 to the fully programmed value ($00) as defined in GMW 3110.
Action Fields AC0 $02 AC1 $00 AC2 $00 AC3 $00 G0-G1 00 Succes s G2-G3 00 Error Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $10
OpCode $50
OpCode $50 Compare Data

This Interpreter command compares the programmed state retrieved from the ECU and stored in Data Buffer #2 with the fully programmed value.
Action Fields AC0

Set this to the Data Buffer to be used in the comparison. In this example, Data Buffer #2 holds the programming state retrieved from the ECU.
AC1, AC2
AC1 is the most significant byte (MSB), and AC2 is the least significant byte (LSB) of the vale used for comparison. In this example, the Fully Programmed value of $0000 is used.
AC3 Not used

Set to $00

If the values match, then the Interpreter jumps to the step indicated in G1. In this example, the Success step.

If the values dont match, then the Interpreter jumps to the step indicated in G3. In this example, the Error step.
Page
226
Step $11 Part 2 Write the VIN

This is the second part of the programming of an ECU. Part one of a utility file ends when either an end with success or end with error op-code is encountered. If part one ended with success, a reset and request for CAN IDs will be sent, and part 2 of the Utility file will be executed. The step number for part two is stored in the Utility file header in the Type of Header/Utility field. If this is set to 0 then there is no part two. Part 2 is concluded with either an end with success or end with error op-code.
Please Note: The programming application will automatically send service messages ReturnToNormalMode $20, and ReadDataByIdentifier $1A, DID $B0 (ECUDiagnosticAddress) before Part 2 of the utility file is processed. If an ECU needs additional time after a reset and prior to the VIN write, a delay should be includes in the Utility file as the first step of Part 2.
OpCode $3B Action Fields AC0 $90 AC1 $00 AC2 $00 AC3 $00 G0-G1 $7B $12 G2-G3 $FD Retry4 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $11
OpCode - $3B Write Data By Identifier

This Interpreter command writes data to DIDs in the ECU by invoking Diagnostic service WriteDataByIdentifier $3B.
Action Fields AC0

Set to $90, which is the corporate DID VehicleIdentificationNumber.
AC1
AC1 specifies where to get the VIN data. When set to $00, the Interpreter uses internal data that is stored by the test tool or the manufacturing device. The VIN number was previously retrieved from the system (see assumptions).
AC2
Set to $00.
AC3
Set to $00, which tells the Interpreter to use internal data.

If a positive response $7B is received, then the VIN was written successfully. Continue to the next step.


Page
227
Step $12 Write the Tester Serial Number

This step writes the Tester Serial Number using DID 0x98 into the ECU. This method can be used to write different types of information to the ECU.
Action Fields AC0 $98 AC1 $00 AC2 $00 AC3 $00 G0-G1 $7B $13 G2-G3 $FD Retry4 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $12
OpCode $3B

Action Fields AC0

Set to $98, which is the corporate DID RepairShopCodeorTesterSerialNumber.
AC1
AC1 specifies where to get the data. When set to $00, the Interpreter uses internal data that is stored by the test tool or the manufacturing device. The data was previously retrieved from the system (see assumptions).
AC2
Set to $00.
AC3
Set to $00 that tells the Interpreter to use internal data.

If a positive response $7B is received, then it was written successfully. Continue to the next step.


Page
228
Step $13 Write the Programming Date

This step is writes the Programming Date using DID 0x99 into the ECU. This method can be used to write different types of information to the ECU.
Action Fields AC0 $99 AC1 $00 AC2 $00 AC3 $00 G0-G1 $7B Success G2-G3 $FD Retry4 Goto Fields G4-G5 $FF Error G6-G7 00 00 G8-G9 00 00
Step $13
OpCode $3B

Action Fields AC0

Set to $99, which is the corporate DID ProgrammingDate.
AC1
AC1 specifies where to get the data. When set to $00, the Interpreter uses internal data that is stored by the test tool or the manufacturing device. The data was previously retrieved from the system (see assumptions).
AC2
Set to $00.
AC3
Set to $00 that tells the Interpreter to use internal data.

If a positive response $7B is received, then it was written successfully.
G2-G3

Page
229
Step $14 Retry1 Initialize Retry counter and decrement

This is a retry counter that is called if a timeout occurs at step $02 during the seed and key operation.
Action Fields AC0 $01 AC1 $03 AC2 $00 AC3 $00 G0-G1 00 $15 G2-G3 00 Error Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $14
OpCode $FB
OpCode $FB Set and Decrement Counter

This is an internal Interpreter command that does not output any messages on the GMLAN bus. It is used with one of the 20 Interpreter loop counters. Each loop counter is initially set to $FF (or reset), and the first time this OpCode is called the counter is loaded with the counter value in AC1. The counter also gets decremented after initialization so that must be accounted for in the total count. Subsequent calls simply decrement the counter until it reaches zero. In this example, the retry counter is set to 3 that result in 2 retries.
Action Fields AC0

This is the loop counter to be used ($00-$13).
AC1
This is the initial value of the counter.
AC2, AC3 Not used

Set to $00.

If the loop counter is greater than zero, jump to the step indicated in G1. In this example, the next step.

If the loop counter equals zero, jump to the step indicated in G3. In this example, jump to the Error step.
Page
230
Step $15 Retry1 Delay

On a retry it is normally desirable to delay for a certain period of time.
Action Fields AC0 $01 AC1 $00 AC2 $00 AC3 $00 G0-G1 $00 Start G2-G3 00 00 Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $15
OpCode $FC
OpCode $FC Delay for nn Seconds

This is an internal Interpreter command that outputs the Tester Present message on the GMLAN bus during the delay. It waits for the specified amount of time before proceeding.
Action Fields AC0

AC0 is set to the number of seconds of delay. In this example, it is 1 second.
AC1, AC2, AC3 Not used

Set to $00.

When the time has expired, jump to the step indicated in G1. In this example it goes to the Start step that performs the Seed and Key operations.
Page
231

This is a retry counter that is called if a timeout occurs at step $0F when the programmed state is requested.
Step $16
OpCode $FB

Action Fields AC0

AC1
AC2, AC3 Not used

Set to $00.


Page
232

Action Fields AC0 $01 AC1 $00 AC2 $00 AC3 $00 G0-G1 $00 ProgStat e G2-G3 00 00 Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $17
OpCode $FC

This is an internal Interpreter command that outputs the Tester Present message on the GMLAN bus. It waits for the specified amount of time before proceeding.
Action Fields AC0


Set to $00.

When the time has expired, jump to the step indicated in G1. In this example it goes to the ProgSat step.
Page
233

This is a retry counter that is called if a timeout occurs for most of the interpreter steps.
Step $18
OpCode $FB

Action Fields AC0

AC1
AC2, AC3 Not used

Set to $00.


Page
234

Action Fields AC0 $01 AC1 $00 AC2 $00 AC3 $00 G0-G1 $00 SetUp G2-G3 00 00 Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $19
OpCode $FC

Action Fields AC0


Set to $00.

When the time has expired, jump to the step indicated in G1. In this example it goes to the SetUp step.
Page
235
Step $1A Retry4 Initialize Retry counter and decrement

This is a retry counter only used by Part 2 steps if a timeout occurs.
Action Fields AC0 $04 AC1 $03 AC2 $00 AC3 $00 G0-G1 00 $1B G2-G3 00 Error Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $1A
OpCode $FB

Action Fields AC0

AC1
AC2, AC3 Not used

Set to $00.


Page
236
Step $1B Retry4 Delay

Action Fields AC0 $01 AC1 $00 AC2 $00 AC3 $00 G0-G1 $00 Part2 G2-G3 00 00 Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $1B
OpCode $FC

Action Fields AC0


Set to $00.

When the time has expired, jump to the step indicated in G1. In this example it goes to the Part2 step.
Page
237
Step $1C Success Exit Interpreter with Success

Exit the Interpreter program indicating that the programming was successful.
Action Fields AC0 $00 AC1 $00 AC2 $00 AC3 $00 G0-G1 00 00 G2-G3 00 00 Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $1C
OpCode $FF
OpCode $FF End with SUCCESS

This is an internal Interpreter command that does not output any messages on the GMLAN bus. The $FF OpCode is used to signal the successful completion of the Utility file part (Part 1 or Part 2).
Action Fields AC0, AC1, AC2, AC3 Not used

Set to $00.
Goto Fields
G0-G1, G2-G3, G4-G5, G6-G7, G8-G9 Not used
Page
238
Step $1D Error Exit Interpreter with Error

Exit the Interpreter program with an error indicating that the programming failed.
Action Fields AC0 $00 AC1 $00 AC2 $00 AC3 $00 G0-G1 00 00 G2-G3 00 00 Goto Fields G4-G5 00 00 G6-G7 00 00 G8-G9 00 00
Step $1D
OpCode $EE
OpCode $EE End with ERROR

This is an internal Interpreter command that does not output any messages on the GMLAN bus. The $EE OpCode is used to signal the tool programming software that an error has occurred. The Interpreter ends processing and returns an error code to the main software.
Action Fields AC0

AC0 is used by the tool to indicate if the product has to be replaced. This example, it is set it to $00 signifying an error occurred and the product may not need to be replaced.

Set to $00.
Goto Fields G0-G1, G2-G3, G4-G5, G6-G7, G8-G9 Not used
Page
239
SPS Editor Output of Interpreter Instructions

Checksum: ModuleId: PartNumber: DesignLevelSuffix: TypeOfHeaderUtility: TypeOfInterpreter: OffsetToRoutineSection: TypeOfAddressing: DataAddressInformation: DataPacketLength: 0x0 0x0 0x0 0x0 0x0B 0x3 0x1E8 0x4 0xFFFF4000 0x806 0 0 0 0 11 3 488 4 -49152 2054
Label
Start SetUp
Step#
01 02 03 04 05 06
Action Fields
01_SetupGlobalVariables (11; F1) 27_SecurityAccess (68) 34_RequestDownload (00; 01; 00) B0_BlockTransferToRam (00; 01; 00; 00) 1A_ReadDataByIdentifier (C1; 01; 00) 53_CompareData (01; 01; 01; 00) F3_SetGlobalHeaderLength (00; 00; 32; 00) 34_RequestDownload (00; 00; 10) B0_BlockTransferToRam (01; 00; 01; 10) F3_SetGlobalHeaderLength (00; 00; 00; 00) 34_RequestDownload (00; 00; 10) B0_BlockTransferToRam (02; 00; 01; 10) 34_RequestDownload (00; 00; 10) B0_BlockTransferToRam (03; 00; 01; 10) A2_ReportProgrammedStateSave2 (02) 50_CompareBytes (02; 00; 00) 3B_WriteDataByIdentifier (90; 00; 00; 00) 3B_WriteDataByIdentifier (98; 00; 01; 00) 3B_WriteDataByIdentifier (99; 00; 00; 00) FB_SetAndDecCounter (01; 03) FC_DelayForSeconds (01; 00; 00) FB_SetAndDecCounter (02; 03) FC_DelayForSeconds (01; 00; 00) FB_SetAndDecCounter (03; 03) FC_DelayForSeconds (01; 00; 00) FB_SetAndDecCounter (04; 03) FC_DelayForSeconds (01; 00; 00) FF_EndWithSuccess () EE_EndWithError (00)
Goto Fields
(00:Next) (67:Next; FD:Retry1; FF:Error) (74:Next; FD:Retry3; FF:Error) (76:Next; FD:Retry3; FF:Error) (5A:Next; 31:ProgOp; FD:Retry3; FF:Error) (00:ProgCal; 00:Next) (00:Next) (74:Next; FD:Retry3; FF:Error) (76:Next; FD:Retry3; FF:Error) (00:Next) (74:Next; FD:Retry3; FF:Error) (76:Next; FD:Retry3; FF:Error) (74:Next; FD:Retry3; FF:Error) (76:Next; FD:Retry3; FF:Error) (E2:Next; FD:Retry2; FF:Error) (00:Success; 00:Error) (7B:Next; FD:Retry4; FF:Error) (7B:Next; FD:Retry4; FF:Error) (7B:Success; FD:Retry4; FF:Error) (00:Next; 00:Error) (00:Start) (00:Next; 00:Error) (00:ProgState) (00:Next; 00:Error) (00:SetUp) (00:Next; 00:Error) (00:Part2) () ()
ProgOp
07 08 09
ProgCal
0A 0B 0C 0D 0E
ProgState Part2
0F 10 11 12 13
Retry1 Retry2 Retry3 Retry4 Success Error
14 15 16 17 18 19 1A 1B 1C 1D
Page
240
GMLAN Message Flow Diagrams

These messages are sent and received by the programming application prior to the first utility file interpreter step
External Programmer ECU Module(s)
$100
High Voltage Wakeup

$101 $FD $10 $04
Response From All Gateway Modules
All Nodes Gateways Wake up all subnets
$101 $FE $1A $B0
Responses only from Type A&B ECUs with Permanent CAN ID and Device ID
All nodes Read Databyte Identifier $B0 Return ECU Diagnostic Address
$101 $FE $10 $02
Responses only from Type A&B ECUs
All nodes Disable DTCs
$101 $FE $28
Responses only from Type A&B ECUs Type A&B ECUs Respond with Permanent CAN ID Type C ECUs Respond with Device ID + $300
All nodes Disable Normal Communications
$101$FE
$A2
All nodes Report Programmed State
$101 $FE $A5 $XX ($01, $02)
Type A, B, & C ECUs Respond
All nodes Request Programming Mode
$101 $FE $A5 $03
No Response allowed form ECUs Continued
All nodes Enable Programming
Page
241
These messages are sent and received by the programming application based on the Interpreter instructions in the Utility file
Specific ECU is targeted for flash programming. Note that not all Interpreter step output messages on the GMLAN bus External Programmer ECU Module
Step $02 Perform Seed and Key

ECU pos/neg response ECU pos/neg response
ECU CANID $XXX .. $27 $01 .. ..
Request Seed of specific ECU

ECU CANID $XXX .. $27 $02 .. ..
Send Key of specific ECU

ECU CANID $XXX .. $34 $00 .. ..
Step $03 Prepare to Download Flash

ECU pos/neg response Request Download
ECU CANID $XXX .. .. $36 $00 .. ..
Step $04 Download Flash Routine

Multiple transmits and ECU responses
Transfer Data Sequence Numbers
Step $05 Request Part Number

ECU pos/neg response
ECU CANID $XXX .. $1A $C1 .. ..
Request Operating Soft Part #

ECU CANID $XXX .. $34 $00 .. ..
Step $08 Prepare to Download Op Soft

Request Download
ECU CANID $XXX .. .. $36 $00 .. ..
Step $09 Download Operating Software

Transfer Data
Step $0B Prepare to Download Cal #1

ECU CANID $XXX .. $34 $00 .. ..
Request Download
ECU CANID $XXX .. .. $36 $00 .. ..
Step $0C Download Calibration Module

Transfer Data
Continued
Page
242
Completion of messages based on the Interpreter instructions in the Utility file
External Programmer
ECU Module
Step $0D Prepare to Download Cal #2

ECU CANID $XXX .. $34 $00 .. ..
Request Download
ECU CANID $XXX .. .. $36 $00 .. ..
Step $0E Download Calibration Module

Transfer Data
Step $0F Report Programmed State

ECU CANID $XXX .. $A2
Report Programmed State
The Interpreter instructions end in either a Success or Error mode
Part 2 of the Interpreter instructions

Step $11 Write the VIN
ECU CANID $XXX .. .. $3B $90 .. ..
Step $12 Write Tester Serial Number

ECU CANID $XXX .. .. $3B $98 .. ..
Step $13 Write Programming Date

ECU CANID $XXX .. .. $3B $99 .. ..
The Interpreter instructions end in either a Success or Error mode
Page
243
Appendix E - Revision Log (Interpreters Document)

Name Jay Wells Jay Wells Jay Wells Jay Wells Date 03/01/93 04/15/93 06/09/93 12/08/93 Description of Revision Initial release of document. Removed signature page. Updated B4 Op-Code to reflect changes added for the PCM-66U and the PCM32U. Completed error descriptions. Added class 2-interpreter example section. Added FE loop response processing for class 2 messages, which will generate multiple responses. This is in Class 2 response processing. Added capability to turn on and off the transmission of a periodic 3F to all devices to keep modules not being communicated with disabled. This is in 01 Op-Code of Interpreter 1. Added more detail to B4 Op-Code concerning packet size. Attempted to clean up the format of the document. Changed the planned implementation of the 3B Op-Code. Initial release of document for review only. Incorporated changes and added functionality based on input from STG-E. Added all Op-Codes to support programming based on final version of KWP2000 - Part 3: Implementation. Sent to STG-E for distribution and final review. Added Op-Code F2 to set global memory size. Modified Op-Codes 34, 90, and 93 per request from Bosch. Added Op-Codes 32, 33, 39 and 3A. Compared pseudo code to source code and updated where necessary. Added 7F response processing to pseudo code for Class 2 response processing. Added Op-Code 02 to allow users to define Op-Codes. Added Op-Code 11 for ECU Reset. Added Op-Code 30 for IO Control by Local ID. Modified Op-Code 10 Programming mode byte to be Action Field 0. Updated the Security Op-Code 27 to reflect actual implementation. Update FB Op-Code examples, Update 3B & 3D sections Modified 3B, AE and FC Op-Codes Update negative response processing for duplicate response codes. Added new Op-Codes 52 and 72. Modified Op-Code 3B to reset a block of memory. Modified Op-Code 3B to write end model number in BCD format. Added Op-Code 31 - Start Diagnostic Routine by Test Number. Modified Op-Code 3B to send a routine from the utility file. Added Op-Code 20 return to normal Fixed several errors in the B4 Op-Code, the normal and block response processing Revised text for clarification in the following sections: 10, A0, B0, B2, F0, FC OpCodes and the 7F negative response processing section. Added header byte description (pg. 6-7). Added Programming Algorithm Overview (page 8). Modified Op-Code 34 to support sending simplified message with no extra data. Enhanced and revised the Overview, Architecture and Technical Specifications, Utility File Structure, Reprogramming Algorithm Overview and Op-Code Structure sections. Added utility file examples with supporting step-by-step descriptions. Added UART Op-Codes 00, 02, 03, A3, 0A, C3, D4, D5. Modified UART Op-Codes C0 & D0. Added Class 2 Op-Code 3C. Compared source code to pseudo code for all Op-Codes and made revisions as necessary. Updated the System Errors and Op-Code failures section. Revised the Procedure for adding new Op-Code and OpCode Testing sections. Updated the Class 2 3B, 3C, 72 and 52 Op-Codes to include Saturn programming information. Made minor formatting changes to page numbers. Revised description of B4 exceptions. Updated the Uart 08, 0A and D4 Op-Codes. Update the Class 2 34 Op-Code. Made minor formatting changes to page numbers. Fixed minor spelling errors. Added the Uart 20 Op-Code. Modified the Class 2 B4 Op-Code by adding exception 04. Removed all references to STG and replaced with GM Service and Parts Operations. Added exception 05 to Class2 3B Op-Code. Added the Class 2 14 Op-Code. Page 244
Jay Wells Jay Wells Jay Wells Jay Wells
12/20/93 03/15/94 03/24/94 04/30/94
Jay Wells Jay Wells Jerry Anderson Jerry Anderson Jerry Anderson Jay Wells
05/13/94 11/18/94 2/3/95 04/20/95 06/02/95 7/18/95
Jay Wells Dennis Pesonen Dennis Pesonen Dennis Pesonen Philip Barone Philip Barone Philip Barone
8/10/95 9/28/95 04/22/96 8/02/96 01/23/97 03/06/97 07/31/97
Rob 10/07/97 Dennis Pesonen 10/12/97 Dennis Pesonen 10/24/97
Phil Barone Greg Powell
01/27/98 09/21/98
Greg Powell
10/6/98
Greg Powell Greg Powell Greg Powell Greg Powell Greg Powell
10/30/98 11/02/98 12/14/98 1/6/99 1/12/99
Dennis Pesonen 2/18/99

Dirk Heinemann John Cline John Cline John Cline John Cline John Cline John Cline John Cline John Cline John Cline John Cline John Cline John Cline John Cline Dirk Heinemann Dirk Heinemann Dirk Heinemann Thomas Walter Dirk Heinemann Dirk Heinemann Dieter Rapp Dirk Heinemann Dirk Heinemann Dirk Heinemann Dirk Heinemann Dirk Heinemann Jerry Rainko Dirk Heinemann Dirk Heinemann Dirk Heinemann Dirk Heinemann Dirk Heinemann Jerry Rainko David Setterlun David Setterlun 3/23/00 4/13/00 5/01/00 6/07/00 7/11/00 7/11/00 7/11/00 7/11/00 7/11/00 7/11/00 7/11/00 7/11/00 7/24/00 7/24/00 8/15/00 8/15/00 8/15/00 8/22/00 8/29/00 8/29/00 8/31/00 11/13/00 4/18/01 4/18/01 4/18/01 6/29/01 8/3/01 11/13/01 11/13/01 11/13/01 11/14/01 12/5/01 1/9/02 01/10/02 02/28/02
Added AC3 option in Op-Code 27 for security level 2. Added AC3 option x03 to OpCode 93. These changes were for SAAB.
GMLAN B0 Op-Code Mode 36 Block Transfer to RAM changed. Exceptions have changed from the beta version of the document. Accepted changes from 3/23/00. Added 04 Byte address to utility file header. Removed Class 2 indication from Op-Code F1. Updated footer for 1993-2000. Revised Table of Contents to show Interpreter 2 Add Op-Code 3E and 40 to Class 2 interpreter 1 Move UART Op-Code A3 to proper location Remove initials DH from GMLAN Op-Code 34 Correct description for GMLAN Op-Code F2 Add KWP2000 Op-Code 02 Add Op-Code F3 to Communications Independent Op-Codes Update GMLAN Op-Code B0 description Update KWP2000 Op-Code 27 for valid security algorithm range Update UART Op-Code 0C description Added GMLAN Interpreter to Op-Codes 50, 51, EE, F7, F8, FB, FC, FD and FF Added Blocks 22, 23 and 24 to Class 2 Op-Code 3B Removed Target ID from GMLAN Op-Codes Added Target ID to GMLAN Setup Global Variables Changed GMLAN Op-Codes 34, B0 exception handling from bit to nibble coded Added GMLAN example Removed GMLAN Op-Code 27 5 tries 2 second wait logic Added note for FC Op-Code AC1 and AC3 Updated Class 2 Op-Code 27 (Perform Security) pseudo-code Added Exception to Mode 1A Read Data by Identifier to identify storage location 2 bytes byte buffer or 10 bytes data buffer. Changed Compare Data Op-Code 52 to 53 (had same value as Class2 Write Checksum to Block 82) Added more detailed description for Op-Code 90 Transfer a Routine to ECU (2 3 byte address information) Added more detailed description for Op-Code 93 Transfer a Calibration File to ECU (2 3 byte address information) Modified GMLAN Op-Code AE Request Device Control to allow 0 to 5 control bytes Documented the block descriptions (AC1) for the Class2 3B Op-Code. Updated KWP2000 3B Op-Code description Fixed GMLAN example step 4 G1 jump to 05 Updated Format of Header definition (Utility File module ID = 0x0000) Added GMLAN Op-Code 3B write multiple DIDs via calibration file support Added more detailed description to Common Op-Code 51 Compare Checksum Updated Op-Code 3C logic to reflect what is actually being done. Added Class 2 support for the F3 Op-Code Set Global Header Length. Added Global Header Length descriptions & logic to the Class 2 B4 Op-Code. Updated Op-Code $53 to change VIT2 compare reference values used within the AC1 field to reference the Part #, VIN, information. Previous documentation was incorrect and also updated to allow for future P/N expandability. Added KWP2000 Op-Code $84 to Set Communications Parameters. Updated KWP2000 Op-Code $3B Write Data by Local ID added conversion of programming date into a 6 character ASCII string formatted as YYMMDD if AC0 is $00, AC1 is $99, AC2 is $06 and AC3 is $00. Changed GMLAN 3B Op-Code Mode 3B Write Data by Identifier to support access to 20 bytes buffers Added Common 54 Op-Code Change Data Changed F7 Op-Code description to match existing code behaviour (from should never the destination to goto step G1) Modified FC Op-Code to indicate support for Delay For Minutes for KWP2000 protocol. Modified Class 2 Op-Code $27 to document retry logic for a TIME DELAY NOT EXPIRED response condition. Added KWP2000, new 23 Op-Code SR 23 to Read Memory by Address and Save Bytes Added KWP2000, 3B Op-Code, new AC2 $02 Use module for record values Added KWP2000, 10 Op-Code, new AC1 Baud rate Identifier Added KWP2000, 27 Op-Code, new AC2 Security IDs Changed FB Op-Code Set and Decrement Counter description to match existing code behaviour
Dieter Rapp Dieter Rapp
04/29/02 04/29/02
Dirk Heinemann Dirk Heinemann Dirk Heinemann Jun Bradburn David Setterlun Dirk Heinemann Dirk Heinemann Dirk Heinemann Dirk Heinemann Dirk Heinemann
07/08/02 07/08/02 09/20/02 09/20/02 10/30/02 11/21/02 11/21/02 11/21/02 11/21/02 12/04/02
Page
245
Dirk Heinemann Dirk Heinemann Dieter Rapp Dieter Rapp Dieter Rapp Dieter Rapp Dieter Rapp Dieter Rapp David Setterlun
12/04/02 12/04/02 05/19/03 05/19/03 05/19/03 05/19/03 05/19/03 05/20/03 22 May 2003
Dieter Rapp Dieter Rapp Dieter Rapp Dieter Rapp Dieter Rapp Dieter Rapp Dieter Rapp Dieter Rapp Dieter Rapp Setterlun
06/30/03 06/30/03 06/30/03 06/30/03 06/30/03 07/01/03 07/01/03 07/01/03 09/18/03 10/08/03
John Cline/ Lisa Cleaveland John Cline Dieter Rapp Dieter Rapp Dieter Rapp Dieter Rapp David Setterlun
11/13/03 11/13/03 03/03/04 03/03/04 04/22/04 04/22/04 08/12/04
David Setterlun
08/19/04
Updated KWP2000 90 Op-Code: SR 36 to Transfer a Routine to ECU added AC3 $40, $41 Updated KWP2000 93 Op-Code: SR 36 to Transfer a Calibration File to ECU added AC3 $40, $41, $42, $43, $C0, $C1 Updated KWP2000 10 Op-Code: Added baud rate switch Updated KWP2000 20 Op-Code: Added baud rate switch to 10400 Bd Updated KWP2000 3D Op-Code: new AC3 Multiple services to download Added KWP2000, new F4 Op-Code to Ignore Responses for a Specified Number of Milliseconds Updated Common 51 Op-Code: new AC2 Checksum Type Updated Common F7 Op-Code: Changed description to match existing code behaviour (always go to next step) - Updated common Op-Code $53 (Compare Data) to support 20 (decimal) Part Numbers (from 16). - Updated GMLAN Op-Code $3B (Write Data by Identifier) to support the data identifier 0xCB (End-Model Part Number). - Resolved a few minor spelling/grammar errors Seemed to have lost some of these fixes from Cline (13 Dec. 2002). Added UART $C4 Op-Code for Holden Telematics (Download Routine to RAM using Mode 20) Added UART $C5 Op-Code for Holden Telematics (Execute Routine using Mode 21) Added UART $D6 Op-Code for Holden Telematics (Erase Flash Block using Mode 22) Added UART $D7 Op-Code for Holden Telematics (Download Software Module using Mode 23) Added UART $D8 Op-Code for Holden Telematics (Execute Software Module using Mode 24) Added GMLAN $02 Op-Code for development use only (Send Single Frame) Added GMLAN $03 Op-Code for development use only (Re-Initialize Network for Programming) Updated GMLAN Op-Code $27 (Security Access): Added exception $01 send key even if seed is 0. Moved Op-Code $F4 from the KWP2000 section to the communication independent section. Added Op-Code $F5 (Common Op-Code) Override Utility File Message Length Field (Changes made based on Dieters 18-Sept-2003 interpreters document. Also, updated the copyright date within the footer. Reformat document - Remove 30 pages without losing content. Remove development only information from document. Update Copyright Information per GM management direction Added GMLAN Op-Code $84 (SetCommunicationParameters) to override STmin Updated KWP2000 Op-Code $27 (Security Access): Added special handling if AC1 is $01 send key even if seed is 0. Updated GMLAN Op-Code $27 (Security Access): Added handling of AC1 (security level) and AC2 (algorithm type - GM vs. non-GM). Added GMLAN Op-Code $AA Read Data By Packet Identifier. Update Op-Code $53 to support part number module IDs 1 through 99 by adding more VIT2 reference numbers 0x81-0xE3 (Mod IDs 01-99)). Update the copyright date. Update Op-Code $54 to not list $53 as the Op-Code (oops bug fix). Put in disclaimers stating that the following is not supported for SAE J2534 GMLAN interface types (code is not in VCS 4.0 yet): GMLAN Op-Code $84 GMLAN Op-Code $AA GMLAN Op-Code $27 (Security Level and Security Access support AC1/AC2) Common Op-Code $F5 (not supported for GMLAN J2534) Add documentation to Class 2 Op-Code $27 to state that a mode $28 will be sent out to all devices prior to the $27 $01 (update the interpreter documentation to be the same as the code). And also add support for AC3, so that if AC3 is set to 0x01, then the mode $28 will not be sent out.
Page
246
John Cline/ Lisa Cleaveland
12/01/04
Replace Appendix D with updated GMLAN utility file guidelines document.
Dirk Heinemann
David Setterlun
03/08/05
04/21/05
Correct UART Op Code D7 AC1: description to reflect calibration number Corrected FC Op-Code description for Tester Present and Delay For Minutes.
- Update the copyright date (2005). - Update the complete Interpreter 1 Class 2 section to be more consistent with the newer interpreter documentation and to better document the logic within the VCS code. - Update the complete Independent opcode (common) section to be more consistent with the newer interpreter documentation and to ensure that it matches the VCS code. - Removed the disclaimers stating that certain functionality is not supported for SAE J2534. It is now supported with VCS 4.1: GMLAN Op-Code $84, GMLAN Op-Code $AA, GMLAN Op-Code $27 (Security Level and Security Access support AC1/AC2), Common Op-Code $F5 - Repage the TOC.
Setterlun
04/28/05
Dieter Rapp Dieter Rapp
10/19/05 10/19/05
Setterlun
10/20/05
Cline
1/13/2006
Cline Cline Wist
1/19/2006 1/20/2006 2/14/06
Wist Wist Setterlun
2/14/06 2/14/06 03/06/06
Setterlun/Cline
5/09/2006
- Reformat the TOC (issues with Appendix D). *** Be carfull when updating Appendix D (GMLAN Utility File Guidelines) because of a FORMATTING conflict (Header 1, Header 2, usage) - - - DONT DO IT ! Added GMLAN Op-Code $20 Return to Mormal Mode. Fixed typo in GMLAN Op-Code $34 Request Download, changed AC3 description: Replaced 0X - Use length from the routine indicated by AC2 (2 bytes) by 0X - Use length from the routine indicated by AC1 (2 bytes). The routine is indicated by AC1, not by AC2. Four items (all very minor): 1) Misc. formatting pagebreak items, (continued) belongs on top of the next page. 2) Add the bubble comments by Dirk and Dieter into document text. 3) Put a disclaimer in the System Errors and Op-Code Failures section. 4) Updated comments for OpCodes that reference an index to state if that index is zero based or not (list acceptable values). OpCodes: UART OpCode $C2; Class 2 OpCode $B2; KWP2000 OpCodes $23, $71, $78; GMLAN OpCodes $3B; Common OpCode $54. 1. Update Copyright for 2006 2. Add 52 Op-Code 3. Add Appendix G 54 Op-Code Additional Information 4. Modify Caution message in 20 Op-Code 5. GMLAN 3B Op-Code Use VIN digits 10-17 (exception 4X) Add appendix H GATS Option string processing New RPO Op Code changed from 52 to 55 due to conflict with Class 2 Op Code 52 Modified document to expand 20 byte internal buffers to 256 byte buffers. Affected op-codes include KWP2000 op-code $23, GMLAN op-codes $1A, $3B, and $AA. Communications independent op-codes affected include $51, $53, and $54. Also made changes to Appendix G and Appendix H where the 20 byte buffers were referenced. Modified GMLAN op-code $34 pseudo code to correct refererence to AC1 (was AC2) when obtaining routine data. Modified op-code $54 to add new exception that allows data to be read in from a routine and stored into one of the 256 byte buffers. 1) GMLAN Mode 20 Update (ONLY allowed in Part 2 of a utility file). CR1627 2) Minor cosmetic updates to the 256 byte buffer changes (from Al). CR1635 3) Date/CoverPage/Revision Log/TOC update. 4) Pseudo code Update OpCode $54 loading buffer data via a routine. 5) Other very minor updates (cosmetic only) throughout the document. 6) Appendix G updates (Op-Code $54 changes) simplify. 1) Op Code $FF bar graph increments to 100% 2) Op Code $34 GMLAN length based on calibration option 3) Op Code $3B Class 2 add AC3 exception 6 and 7 4) Op Code $72 Class 2 Update for SAE J2534-1
Page
247
Setterlun/Cline
6/20/2006
Setterlun/Cline Kacel/Cline Cline/Setterlun Cline/Setterlun Cline/Setterlun Cline Cline Cline/Koski Cline Cline/Setterlun
8/16/2006 9/20/2006 9/20/2006 9/20/2006 10/04/2006 4/01/2007 4/01/2007 4/01/2007 4/01/2007 4/01/2007
J. Cline J. Cline J. Cline
4/04/2007 4/05/2007 7/12/2007
Setterlun
8/15/2007
Cline/Koski Cline/Wist Koski/Wist Cline/Setterlun A. Wist Setterlun/Wist Cline/Setterlun Cline Cline Setterlun
8/26/2007 12/06/2007 2/29/2008 2/29/2008 2/29/2008 2/29/2008 2/29/2008 2/29/2008 4/12/08
Cline/Setterlun Cline Cline/Setterlun
8/01/2008 8/01/2008 8/12/2008
- Page 235 correct offset to routine in utility example - Page 235 correct TypeOfHeaderUtility value to 11 - Added GMLAN op-code $01 fatal error on Target Address FE and TIMEOUT description. - Changed GMLAN op-code $14 description to indicate physical addressed usage. - Changed GMLAN op-code $20 description to indicate development only usage. - Class 2 OpCode $3C and OpCode $3B Use of internal storage buffers to read/write data from these buffers. Appendix D GMLAN message flow steps $12 and $13 correct messages from $34 to $3B Add GMLAN Op Code $25 for Global A Security Code Modify all storage buffer values from 00-09 to 0x00 - 0x13 Add comments to GMLAN mode $27 for Timer Not Expired 37 functionality Remove GMLAN Development Op Codes $02 and $03 Add GMLAN Op Code $22 Read data by PID Per Devin Koski modify Op Code $25 action fields AC1, AC2 and AC3 Add Op Code $84 for Class 2 Set Communications Parameters Add delay - Update KWP2000 and GMLAN Op Code $27 security access information - Add clarification to the statement from the header which becomes from the utility file header where appropriate Update Op Code $51 text for 20 buffers. Add Class 2 to Op Codes $53 and $54 Spelling and grammar check. GMLAN Op Code $AA add note concerning optional interface support GMLAN Op Code $84 add note concerning assembly plant support GMLAN Op Code $3B Correct AC1 ID for saved bytes (0x00 0x13) Page 243 correct spelling of Cleaveland Class 2 Op Code $3B Correct AC3 and Example 6 storage buffer is AC2 Class 2 OpCodes 3B & 3C: Updated these OpCodes to better explain how data is read from and stored to one of the internal storage locations - - - specifically regarding the amount of data. GMLAN Op Code $25 Update Security Code Text description for AC2 to Security Code 1 or Security Code 2 Add Internal Data Specificers $44 (Tire Type) and $45 (TPIM placard data) to Op Code $53 and Op Code $54 Op Code $25 Update text for improved security code description GMLAN Op Code $27 Add Security Table GMLAN-1 information to AC2 and description Op Code $53/$54 Add Internal Data Specificer $46 (Diesel Injector Mass Adjustment) Op Code $54 Add AC2 exception $08 Copy the data from one storage buffer to another Op Codes $FB/$FD Increase loop counters from 10 to 20 ( 0x00 0x13) Update copyright for 2008 Add Op Code $56 Plant/Service/FCP Add note to Op Code $53 numeric part number names in DPS GMLAN Op Code $84 Add ESCAN link info. Minor Cosmetic Updates based on comments from Dirk (Setterlun) -- OpCode FF, GMLAN OpCode 20, Class 2 OpCode A8 My Update OpCode $53 comment (DPS). Add Internal Data Specifier support for GMLAN mode $3B per GM AVG request. Add documentation to clarify $3B usage and Data integration into $3B message. Replace all reference to GM Service Operations with GM Service and Parts Operations Add option to FD Op-Code to clear all counters per GM AVG. Update documentation to include default operation of counters.
Page
248
Cline/Setterlun
12/15/2008
Cline Cline/Wist Wist
12/15/2008 9/01/2009 03/29/2011
Setterlun
04/01/2011
Add Programming Storage Buffers Recommended Usage section (beginning of this document) and appropriate Note updates to several OpCodes that use storage buffers: Class2: $B2 - Kwp2000: $23, $71, $78 GMLAN: $1A, $22, $A2, $AA Common: $50, $51, $53, $54. Add Note concerning Type C ECUs and OpCode $AA usage in part one of utility file Add Comments to Op Code $54 and GMLAN Op Code $3B for assembly plant data ID $46. Update GM Corporation to GM Company. Plant Manufacturing Specific Updates to: - GMLAN OpCode $3B (AC2, AC3==03 Update) Special Plant Data IDs. - OpCode $53 Added Internal Data Identifiers $47-$49 (plant only). - OpCode $54 AC1, AC2, AC3: Plant data IDs $47-$49 update. Minor Updates: (for April 1, 2011 document) - Copyright update, SPO changed to CCA, version/date updates, - KWP OpCode 84 P2Max resolution is 25ms not 250ms. - OpCode $54 shift actions are exceptions 04 or 05 (not 03 or 04).
Page
249
Appendix F - Related Documents

CD-1039 CD-1036 UART Programmers Quick Reference Guide XDE 5024 Keyword Protocol 2000 Part 1: Physical Layer Keyword Protocol 2000 Part 2: Communication, and Error Handling Keyword Protocol 2000 Part 3: Implementation GME12000 Diagnostic Protocol KWP2000 Functional Description XDE-1039 Generic UART Flash Programming Communications Protocol and Software Requirements XDE-1045 Generic Class 2 Flash Programming Communications Protocol and Software Requirements XDE-3001B General Motors Class 2 Message Strategy and Application SAE J-2190 Enhanced E/E Diagnostic Test Modes Corporate ALDL Data Communications Specification GMW 3110 GMLAN Enhanced Diagnostic Test Mode Specification
Page
250
Appendix G $54 Op-Code Additional Information
Helpful hints on using Op-Code $54:

(The best way to explain it is by example see below.) Op-Code $54: Description / Action Fields / Pseudo Code See Op-Code $54 information above (Communications Independent Programming Op-Codes).
General Information (typical scenario):

1) The application has 20 internal storage buffers to temporarily hold data (mostly vehicle data). These storage buffers can be thought of as storage buffer #1 through #20; however, most Op-Codes (and internal code) refer to these buffers as #0x00 through #0x13. In addition, the 256 bytes of data within a single storage buffer is referenced by starting at position #00 and going up to position #255 ($FF hexadecimal). This referencing is done by most Op-Codes (including this Op-Code) and also within internal code. Also, bit positions are referenced starting at position 0 through position 7 (and NOT 1-8). 2) Data can be placed into these storage buffers via a Read Data type of OpCode ($1A for GMLAN). 3) OpCode $54 can then be used to change the data within one of these internal storage buffers. More than one OpCode $54 line may need to be in the utility file if multiple data bytes/bits need to change. 4) And finally, this newly manipulated data can be written back into the controller, typically with a write data type of OpCode ($3B for GMLAN).
GMLAN Example: Step 02 03 04 05 06 Op AC Goto 1A 03 09 00 00 5A 03 FD 12 FF 12 00 00 00 00 - Read DID $03 and place in storage buffer #09 upon a positive response, goto step 03 54 09 01 00 AA 00 04 00 00 00 00 00 00 00 00 - Set the second byte (01) of buffer #9 EQUAL (00) to a value of AA go to step #4 54 09 00 01 F0 00 05 00 00 00 00 00 00 00 00 - Set bits 0-3 of the first byte (00) of buffer #9 equal to zero (AND (01) with 0xF0) go to step #5 54 09 03 02 E0 00 06 00 00 00 00 00 00 00 00 - Set bits 5-7 of the fourth byte (03) of buffer #9 equal to one (OR (02) with 0xE0) go to step #6 3B 03 09 05 30 7B 07 FD 12 FF 12 00 00 00 00 - Write the first 05 bytes of data from storage location 09 to DID #03 upon a positive response, goto step 07
Page
251
Byte / Bit Manipulation:

Value Before 0x1A 0x3F Operand EQUAL (00) AND (01) Mask Value 0xD1 0xE7 Value After 0xD1 0x27 Comments Full byte replacement. Set bits 3 and 4 to zero: 0 0 1 1 1 1 1 1 (0x3F) 1 1 1 0 0 1 1 1 (0xE7) ------------------- Like multiplication. 0 0 1 0 0 1 1 1 (0x27) Set bits 4, 5, 6, 7 to a one: 1 0 0 0 0 1 0 1 (0x85) 1 1 1 1 0 0 0 0 (0xF0) ------------------- As long as one of the bits is a 1. 1 1 1 1 0 1 0 1 (0xF5) Reverse the bits (compliment) of the byte: 1 1 0 1 0 0 1 1 (0xD3) 1 1 1 1 1 1 1 1 (0xFF) ------------------- Set to 1 if NOT identical bit values. 0 0 1 0 1 1 0 0 (0x2C) Byte Shift Left Shift the bytes in the buffer LEFT (3 2, 2 1, ) by the number of positions defined in AC1 (fill vacated positions with 0x00). Byte Shift Right Shift the bytes in the buffer RIGHT (1 2, 2 3, )by the number of positions defined in AC1 (fill vacated positions with 0x00).
0x85
OR (02)
0xF0
0xF5
0xD3
XOR (03) (exclusive OR)
0xFF
0x2C
See Comments
SHL (04) (shift left fill w/ 0x00) SHR (05) (shift right fill w/ 0x00)
N/A
See Comments
See Comments
N/A
See Comments
Page
252
Appendix H $55 Op-Code Additional Information - GATS Option String Processing

The General Assembly Test System (GATS) options processing evaluates an ASCII string (mask) consisting of RPO data, operands (e.g. logical and, or, not, wildcard characters), and option specifiers. Option specifiers consist of the vehicle VIN, and/or model designator information. Any set of characters in the string that is not white space or an option specifier, and is not preceded by a specified letter and colon is considered an RPO. If the RPO matches one of the RPOs in the build data, that RPO is considered a match. The entire string must match for the evaluation to result as true. Option specifiers are identified by a single letter followed by a colon followed by the data to match against. There cannot be a space on either side of the colon. The following are the valid options identifiers that can be used when building a GATS options string: M: Represents the Model Designator. The string following the colon is compared to the Model Designator in the build data. Wildcard characters may be used as part of this specifier to match on multiple designators. See examples for further clarification Represents the VIN. The string following the colon is compared to the VIN extracted from the build data. Wildcard characters may also be used as part of this option specifier so that individual characters within the VIN can be masked on (e.g. restraint code or vehicle model year). See examples for further clarification.
V:
The option string can contain several special characters to interpret portions of the build string. These characters allow greater flexibility when setting up the masks. Following is a description of how these wild card characters work. ? A question mark is used to indicate that any one character can occupy that position in the string. Matches occur for any single character in the same location of the string. An asterisk is used to indicate that any character can occupy that position and all the trailing positions in the string. Any number of characters are valid. All characters that follow an asterisk are ignored. These characters (where N represents any character) are used to indicate any single character in that position in the string that is not N. Matches occur for any single character in the same location of the string that is NOT that value.
^N
[M-N] These characters (where M and N represent any characters) are used to indicate a range of M to N inclusive. Matches occur for any character in the same location of the string that is in the range of M to N. ^[M-N] These characters (where N and M represent any characters) are used to indicate a "NOT" range of M to N inclusive. Matches occur for any character in the same location of the string that is NOT in the range of M to N. [M,N,O,...] These characters (where N, M and O represent any characters) are used to indicate a list of valid characters. Matches occur for any character in the same location of the string that matches M, N, O. More than three characters may be specified. ^[M,N,O,...] These characters (where N, M and O represent any characters) are used to indicate a list of invalid characters. Matches occur for any character in the same location of the string that is NOT M, N, O. More than 3 numbers may be specified. The option configuration string uses wild card and Boolean characters to interpret each part of the build data. These characters allow greater flexibility when setting up the masks. The following is a description of how these Boolean characters work. The previous section describes the wild card characters. This section describes the Boolean characters. & This character represents the Boolean "AND" operation. When used, if both operands are true, then the entire statement is true. This character represents the Boolean "OR" operation. When used, if either operand is true, then the entire statement is true.
Page
253
This character represents the Boolean "NOT" operation. When used, if the operand is true, then the entire statement is false. If the operand is false, the entire statement is true. These characters represent that Boolean association rules apply. They are used to specify a grouping of conditions. Option String Examples Comments True if the RPOs L26 and OP1 exist in the build data. True if the RPOs L35 or OP4 exist in the build data. True if the RPO LY7 does not exist in the build data. True if RPOs JM4 and either OP4 or OP5 exist in the build data. Notice the parentheses change the logic of this statement. If OP4 and OP5 RPOs exist in the build data and JM4 does not, then this statement evaluates to false. True if RPOs JM4 and OP4 are part of the build data or if OP5 is part of the build data. True if the vehicle VIN exactly matches the first 10 characters. Characters 11 through 17 dont matter. True if the first 4 character of the vehicle VIN th are 1G2W and the 5 character is not 5, and digits 6 through 10 are 1567N. Digits 11 through 17 dont matter. True if the first 4 character of the vehicle VIN th are 1G2W and the 5 character is either a 4, 5, th or a 6. The value of the characters after the 5 are ignored. True if the first 4 character of the vehicle VIN th are 1G2W and the 5 character is not 4, 5, or th 6. The value of the characters after the 5 are ignored. True if the first 4 3 characters of the vehicle VIN th are 1G2, the 4 character is either A, C, or W, th and the 5 character is 5. Characters 6 through 17 are ignored. Not a valid string. The number of characters inside the brackets must be the same for all possible values within the range. A valid string would be V:1G2W[01-12]567N* True if the first character of the vehicle VIN is a 1 or a 3, characters two through four are G2W, characters five and six are not 23 through 44 and also not 55, character 7 can be anything, character eight is a 6, and the rest of the characters are ignored. True if the vehicle model designator is 1WB19, 1WC19, or 1WD19 True if the vehicle model designator is 1WB19 or if the RPO AU0 is part of the build data, or if the RPO AP3 is part of the build data. th True if the 10 digit of the VIN is a 6. The leading ? are single character wildcards and the * indicates that all characters after the 6 in the 10 digit are dont cares.
( )
Option String L26 & OP1 L35 | OP4 !LY7 JM4 & (OP4 | OP5)
JM4 & OP4 | OP5 V:1G2W51567N*
V:1G2W^51567N*
V:1G2W[4-6]*
V:1G2W^[4-6]*
V:1G2[A,C,W]5*
V:1G2W[1-12]567N*
V:[1,3]G2W^[23-44,55]?6*
M:1W[B,C,D]19 M:1WD19 | AU0 | AP3
V:?????????6*
Page
254

Interpreters April 01 2011

Uploaded by

Copyright:

Available Formats

Interpreters April 01 2011

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Interpreters April 01 2011

Uploaded by

Copyright:

Available Formats

What is the purpose of the document?

What is the purpose of the document?

What are some of the op-codes described in the document?

What are some of the op-codes described in the document?

Service Programming System (SPS) Interpreter Programmers Reference Manual

Utility File Structure

Header Information (24 bytes)

Format of Header Information

Offset to routine section from byte $00

2 bytes $10-$11 4 bytes $12-$15 2 bytes $16-$17

Example Header Information 790E00000000000000000000000100A80002000020000040 (ASCII Hex Format)

Format of Interpreter Instructions

Reprogramming Algorithm Overview

Additional Utility File Information - Best Practices and recommendations

Programming Storage Buffers Recommended Usage

Interpreter 0 - UART Communications Programming Op-Codes

UART Support for No Communication Faults

XX OP AC0 AC1 AC2 AC3

G0-G1 G2-G3 G4-G5 G6-G7 G8-G9

UART Return Type Processing

00 Op-Code: Enable Normal Communications

01 Op-Code: Request message from the device

03 Op-Code: Verify programming of a EEPROM device (NAO EEPROM)

04 Op-Code: Device control - Mode 4

05 Op-Code: Ram download request - Mode 5

08 Op-Code: Disable Normal Communications

09 Op-Code: Enable Normal Communications

0A Op-Code: Clear Trouble Codes - Mode 10

0C Op-Code: Program EEPROM - Mode 12

0D Op-Code: Perform Security - Mode 13

20 Op-Code: Receive a normal mode message from device

C0 Op-Code: Download Routine to RAM and Execute using Mode 6

C1 Op-Code: Download Routine to RAM and Execute using Mode 16

Typical Interpreter Line: Step 10 Op-Code C3 Action Fields 01 39 F9 00 Goto Fields FD 20 FF 21 00 00

C4 Op-Code: Download Routine to RAM using Mode 20 (Holden Telematics)

C5 Op-Code: Execute Routine using Mode 21 (Holden Telematics)

D0 Op-Code: Download Calibration / Software File using Mode 6

D1 Op-Code: Download Calibration or Software Module using Mode 16

D2 Op-Code: Download VIN using Mode 6 & 16

D4 Op-Code: Download Calibration / Software File using Mode 6 (Saturn EEPROM)

D5 Op-Code: Download Calibration / Software File using Mode 12 (Electric Vehicle)

D6 Op-Code: Erase Flash Block using Mode 22 (Holden Telematics)

D7 Op-Code: Download Software Module using Mode 23 (Holden Telematics)

Request Byte 1 2 3 4 5 6 7 7+N 8+N

Value AC0 4+N 17 XX XX XX XX

D8 Op-Code: Execute Software Module using Mode 24 (Holden Telematics)

F0 Op-Code: Wait for Poll from a Device

Interpreter 1 - Class 2 Communications Programming Op-Codes

Class 2 No Communications Processing

Class 2 Response Processing

01 Op-Code: Setup Global Variables

10 Op-Code: Initiate Diagnostic Operation

14 Op-Code: Clear Diagnostic Information

20 Op-Code: Return to Normal Mode

27 Op-Code: Perform Security - Mode 27

28 Op-Code: Disable Normal Communications - Mode 28

29 Op-Code: Resume Normal Communications - Mode 29 (Obsolete Use Op-Code 20)

31 Op-Code: Start a Diagnostic Routine by Test Number

Typical Interpreter Line: Step 08 Op-Code 31 Action Fields 40 22 00 00 Goto Fields 73 09 FD 12 FF 99

34 Op-Code: Request the Control Module for Block Transfer - Mode 34