How to Request Mode 3 ALDL Data Using TunerPro RT

EDIT ----
Have been asked a couple of times why this document was created. It's because I could not find anywhere the details of how to do all of this. There were bits and pieces in many places, so I decided to pull it all together in one place so it might help someone trying to do the same thing.

================================================== =============

This documentation uses the AUJP $8D code mask in all of its examples, but the same logic applies to all other code masks. All references to TunerPro (TP) are to v5.

ECM Interface Modes
The ECM has many documented Interface Modes. Each Interface Mode has a different Command Set required to:

• initiate a data request,
• perform an operation on the ECM and/or wait for requested data, and
• receive a reply from the ECM

The most commonly used Interface Modes are:

Mode 1 – Request Diagnostic Data Stream (DDS) for the code mask
Mode 2 – Request 64 sequential bytes in Memory
Mode 3 – Request 8 selected bytes in Memory
Mode 4 – ECM Control Mode
Mode 10 – Clear Malfunction Error Codes

The “Additional Interface Modes” section at the end of this document provides details on all Interface Modes. Mode 3 is specifically discussed below.

Interface Mode Command Set
A request for mode data is triggered by sending the ECM a specific Command Set, in this order:

• Message ID Byte (0xF4 for ALDL Diagnostic data for code mask $8D)
  
  • The first command in the Command Set is the Message ID Byte which lets the ECM know what category of command it is receiving. Since all the above commands are ALDL diagnostic commands, they all have the same message ID byte of 0xF4 (for $8D).
  
  
• Message Length Byte
  
  • The next command in the Command Set is the Message Length Byte. This is the length of the message to be transmitted to the ECM by TP (also called the “ALDL Device”). Each Mode has a certain number of message bytes to be transmitted to the ECM. After that message length is determined, 85 decimal (0x55) is added to that value. This is a convention required by the transmit and receive interrupt handlers of the code mask running on the ECM to ensure accurate data transfer.
  
  
• Mode Byte
  
  • This is the Mode Number (0 to 10) defining the diagnostic task the ECM is to perform
  
  
• Data Bytes
  
  • Individual data bytes requested in the reply, or the address of the first requested data byte in a series of bytes (requested data bytes do not have to be provided for some Modes)
  
  
• Checksum Byte
  
  • The last byte to be transmitted is the Checksum Byte. The Checksum Byte is the two’s complement of the sum of all bytes transmitted. It is calculated as:

0x200 – (hex sum of all bytes transmitted)

As noted above, some Mode requests require Data Byte information to be transmitted after the Mode Byte and before the Checksum Byte, and that’s the case for Mode 3.

Mode 3 Summary
ALDL Mode 3 allows up to 8 bytes of data to be requested from the ECM and to be reported in each TP log sample. The data requested can be from any variable used by the code mask running on the ECM. The purpose of using Mode 3 might be to gain a better understanding of values taken-on by variables, or bit flags within a variable, during code mask execution.

With Mode 3, the variables requested do not have to be in the hard-coded Mode 1 DDS although they can be. Using Mode 3 to request the value of 1 to 8 variables is a much simpler process than trying to do this under Mode 1 if the data variables are not in the DDS.

All the work to request and receive Mode 3 data is done by modifying the TP ADX Definition file. Here’s a summary of what needs to be done:

1. The hex addresses of the up to 8 variables to be requested must be determined
2. Three (3) “Commands” must be created:
   
   1. a Transmit (or Send) Command to request the data
   2. a Receive (or Reply) Command to wait for, receive and process the data
   3. a Macro Command that incorporates the Transmit and Receive Commands for use by TP
   
   
3. The header file “Monitor Command” selection must be changed to reflect the newly-created Macro Command that requests and waits for the Mode 3 data
4. Values and Bit Masks need to be defined for any variables requested so they can be logged
5. Optionally, any defined Values and Bit Masks can be added to an “Item List View” if these items are to be visible during a Mode 3 TP session

How to Request Mode 3 Data
The details of the above 5 steps are provided below:

1. Determine up to 8 Variables to Request
The Mode 3 request discussed here requests data from the ECM for the following $8D variables:

L00A2=TPS AE-Index (0-7) into Table L853B for PW Factor
L0045=Bit flags for AE
L00A4=TPS AE-Extended A/F Limiting

2. Create the Three (3) TP Commands
Transmit (Send) Command
This is the first Command to create. Because this is a Mode 3 request, remember from above that the following information must first be sent to the ECM by TP:

• Message ID Byte = 0xF4
  
  • This is the standard for a $8D ALDL data request on the 1227730 ECM
  
  
• Message Length Byte = 1 + (2 * 3 bytes requested) + 85 = 92 = 0x5C
  
  • 1 is for the Message ID
  • “2 * 3” is for 6 bytes of data sent (each variable address has a Most Significant Byte (MSB) and a Least Significant Byte (LSB)
  • 85 is the standard adder required by the receive interrupt handler of the $8D code mask
  
  
• Mode Byte = 0x03
  
  • for Mode 3
  
  
• Data addresses
  
  • 3 addresses for 6 bytes of requested data:

0x00 0xA2 0x00 0x45 0x00 0xA4

The order in which the addresses (data bytes) are requested is important and must be remembered as discussed later

• Checksum Byte = 0x22

0x200 – (0xF4 + 0x5C + 0x03 + 0x00 + 0xA2 + 0x00 + 0x45 +
0x00 + 0xA4) = 0x200 – 2De = 0xFFFFFFFF22 = 0x22

So the string to send to the ECM in this example is:

0xF4 0x5C 0x03 0x00 0xA2 0x00 0x45 0x00 0xA4 0x22

There are 2 ways to send the Checksum (here 0x22):

• Enter the string to be sent in the “Byte String” window and append the Checksum to that string as shown above. Then select “None” in the “Checksum” drop-down box, or
• Enter the above string without the Checksum, and select “2’s Complement” in the “Checksum” drop-down box. As can be seen in the graphic below, this will cause the calculated Checksum to be displayed.

TP Mode 3 Transmit (Send) Command created under the Commands List:
http://www.gearhead-efi.com/Fuel-Inj...1&d=1391979480

All Commands must have a unique Title and ID. A “Baud Rate” of ‘0’ in the Transmit (Send) Command specifies using the default rate of the ECM (8192 Baud for the 1227730).

Receive (Reply) Command
Next, create the Receive (Reply) Command:
http://www.gearhead-efi.com/Fuel-Inj...1&d=1391979480

Note the following for the Receive (Reply) Command:

• The “Process Data” box must be selected or the information sent by the ECM will be ignored by TP and the log file will be empty
• The “Timeout” of 400ms is a default value and should not be changed unless there is good reason to do so
• “Payload Size” is the number of bytes to be received. In our example, the size is 3 for 3 bytes: L00A2, L0045 and L00A4
• “Payload Offset” is 3, representing the number of bytes to be received before the data bytes:
  
  • Message ID
  • Message Length
  • Mode Number
  
  
• “Body Size” = 6 is the sum of “Payload Size” (3) and “Payload Offset” (3)

Also note according to Magnus at TP, it is technically correct in this example to use ‘7’ for the Body Size. This adds 1 byte for the returned Checksum byte that is not accounted for when using Body Size = ‘6’. However, TP sample rate frequency tests indicate that samples are provided to TP by the ECM much faster when omitting the Checksum byte from the Body Size (see Post #12 at: http://www.gearhead-efi.com/Fuel-Inj...3-ALDL-Command). Fortunately, TP flushes all receive buffers after each receipt, so this is not an issue. If you feel uncomfortable not including the Checksum byte count, or are not worried about sample frequency, then by all means include it. Either way is acceptable.

Macro Command
Now that the Transmit and Receive Commands have been created, the Macro Command can be created. This is called a “Macro” Command because it is the Command used by TP to execute the Transmit and Receive Commands together. Below is the Mode 3 Macro Command:
http://www.gearhead-efi.com/Fuel-Inj...1&d=1391979480

This Macro Command merely instructs TP to first use the “Mode 3 Send” Command and then use the “Mode 3 Reply” Command (both previously created), to request and receive the Mode 3 data. The “Macro Repeat Count” of 1 is the default and should not be changed.

3. Modify the ADX Header
After the above 3 Commands are created, the AXD file header must be changed so Mode 3 Data can be requested rather than the default of Mode 1 data.

Below is the default $8D ADX file Header window. Note it is requesting Mode 1 data by virtue of the “Monitor Command” drop down box showing “Mode 1 ALDL Dump Request Macro”. This is the Macro Command that causes Mode data to be requested, received and logged:
http://www.gearhead-efi.com/Fuel-Inj...1&d=1391979480

After changing the “Monitor Command” to request Mode 3 data, the Title of the Mode 3 Macro (“Mode 3 Macro” in this example) must be visible. Below is the header after selecting “Mode 3 Macro” for “Monitor Command”.
http://www.gearhead-efi.com/Fuel-Inj...1&d=1391979480


4. Create Values and Bit Masks
At this point everything has been set up to request and receive Mode 3 data. But, the requested Mode 3 variables, and optionally any bits in those variables, have not been defined so they can be presented in a Log File.

In this example, there are 3 variables (TP “Values”). There are also 3 TP “Bit Masks” within one of the Values (L0045) we want to see. So the following Values were created under the “Values” list:

Variable	Unique ID	Packet Offset
L00A4	3	2
L0045	2	1
L00A2	1	0

What’s important here is the “Packet Offset” assigned to each variable. This represents the order in which the data were requested in the Data addresses portion of the Transmit String (see above). Remember we requested the data in the following order:

0x00 0xA2 0x00 0x45 0x00 0xA4

This means:

0x00A2 = Packet Offset 0
0x0045 = Packet Offset 1
0x00A4 = Packet Offset 2

The first data byte address requested is always Packet Offset ‘0’ as shown below for 0x00A2:
http://www.gearhead-efi.com/Fuel-Inj...1&d=1391979480

The Packet Offset is also important if Bit Masks will be needed from one or more of the Values. In this example 0x0045 is a byte with 8 bit flags, and we want to report the on/off state of some of those flags. With that in mind, 3 Bit Masks were created to provide the needed information:

• L0045 b3 = In MAP AE
• L0045 b6 = TPS AE Limiting
• L0045 b7 = In TPS AE

Each Bit Mask requires a “Packet Offset”. This is merely the 0-based order of the variable in the returned data. Data will be returned in the order requested. In our example, L0045 (0x0045) is Packet Offset 1, meaning it is the 2^nd item in the data stream if counting 1-based, or the 1^st item if 0-based. Remember we requested the data in the following order:

0x00A2 = Offset 0
0x0045 = Offset 1
0x00A2 = Offset 2

This is important, because if the incorrect Packet Offset is used in defining the Bit Masks, data will not be reported correctly in the Log File.

Below is the Bit Mask definition for L0045 b3 = In MAP AE. Note that “Packet Offset” = 1 is used. The “Bitwise Operation” is always “Bitwise AND” and the following “Operand” and “Result to Test” fields indicate the bit to be reported in the Log File (0x08 here indicating bit 3=In MAP AE). The “Display on TRUE” and “Display on FALSE” indicate what you want to be reported in the Log File and/or in the optional Item List View.
http://www.gearhead-efi.com/Fuel-Inj...1&d=1391979480


5. Creating an Item List View
If you wish to view the Values and Bit Masks while TP is running, an Item List View must be created from the Values and Bit Masks previously defined. Here is the Item List View for our example. It contains the 3 Values and the 3 Bit Masks from Value L0045 (0x0045):
http://www.gearhead-efi.com/Fuel-Inj...1&d=1391979480


Additional Interface Modes
The following information describing ECM Interface Modes was taken from:
http://lukeskaff.com/?page_id=305 and
http://pcmhacking.net/forums/viewtopic.php?f=10&t=219
It has been edited for completeness and compatibility with this documentation.
The ECM has many documented interface modes. Each mode has a different Command Set, performs a different operation on the ECM, and receives different responses from the ECM: The most commonly used Modes are:

Mode 0 – Normal Mode = Clear All ALDL Modes
Mode 1 – Request the Diagnostic Data Stream (DDS)
Mode 2 – Request 64 sequential bytes of Memory
Mode 3 – Request 8 selected bytes of Memory
Mode 4 – ECM Control Mode
Mode 5 – Enter Download Mode (GM Development)
Mode 6 – Address Of Routine to Execute (GM Development)
Mode 7 – Broadcast Mode (GM Development)
Mode 8 – Disable Bus Chatter
Mode 9 – Enable Bus Chatter
Mode 10 – Clear Malfunction Error Codes

The most commonly used modes are Mode 1, 2, 3, and 10.


Interface Mode Command Set
A request for mode data is triggered by sending the ECM a specific Command Set, in this order:

• Message ID Byte (0xF4 for code mask $8D)
  
  • The first command in the Command Set is the Message ID Byte which lets the ECM know what category of command it is receiving. Since all the above commands are ALDL diagnostic commands, they all have the same message ID byte of 0xF4 (for $8D).
  
  
• Message Length Byte
  
  • The next command in the Command Set is the Message Length Byte. This is the length of the message to be transmitted to the ECM by TP. Each Mode has a certain number of message bytes to be transmitted to the ECM. After the message length is determined, 85 decimal (0x55) is added to that value. This is a convention required by the transmit and receive interrupt handlers of the code mask running in the ECM to ensure accurate data transfer.
  
  
• Mode Byte
  
  • The Mode Byte is simply the desired ECM operation Mode Number.
  
  
• Data Bytes
  
  • Individual data bytes requested, or the address of the first requested data byte in a series of bytes (data bytes are not required for all Modes)
  
  
• Checksum Byte
  
  • The last byte to be transmitted is the checksum byte. The Checksum Byte is the two’s complement of the sum of all bytes transmitted. It is calculated as:

0x200 – (hex sum of all bytes transmitted)

As noted above, some Mode requests require additional information to be transmitted after the Mode Byte and before the Checksum Byte. Below is a description of the requirements for each Mode:

• Mode 0 - (Normal Mode) is used by diagnostic equipment attached to the ALDL port to stop any communication on the data line. This would include in-car systems such as a body (suspension) computer and dash board modules which retrieve data from the ECM constantly over the diagnostic line. This communication must be stopped for the diagnostic equipment to accesses data from the ECM consistently at full speed.
• Mode 1 - is used to retrieve diagnostic data (the DDS) from the ECM. Each code mask has a different set of data in its DDS. In Mode 1, the diagnostic equipment or ALDL device (ie – TP) sends the Mode 1 commands over the data line and the ECM replies with bytes of data. The number of bytes returned is dependent on the ECM and the code mask running on the ECM (code mask $8D running on the 1227730 ECM returns 66 bytes):
  
  • 1 byte = the Message ID (0xF4 for $8D)
  • 1 byte = the length of the message being transmitted by the ECM/received by TP
  • 1 byte = the Mode Number
  • 63 Data bytes = the DDS = the values of those bytes at the time the data sample is taken. It is the value of these bytes that are reported in alphabetical order in each sample of a TP log file. These DDS bytes are hard-coded in the code mask and cannot be changed without modifying the code mask program code with a hex editor. How to do that is beyond the scope of this documentation.
  
  
• Mode 2 - is used to request 64 bytes of memory from the ECM starting at a specified address. The most significant byte (MSB) of the desired memory start address and least significant byte (LSB) is transmitted after the mode 2 byte to tell the ECM at which address to start the memory dump. The ECM will then reply with the mode 2 Command Set and the desired 64 bytes of data.
• Mode 3 – is used to request up to 8 defined addresses (bytes of data). The eight desired addresses are transmitted after the mode 3 command. These addresses are transmitted with the most significant byte first followed by the least significant byte. The ECM will then reply with the mode 3 Command Set and the desired 1 to 8 bytes of data. These addresses can be any addresses in the whole system including registers, RAM, and ROM.
• Mode 4 is a controller mode where the user may change engine fuel, spark, and other engine parameters. It is primarily used for GM development and debugging.
• Mode 10 - is used to clear any trouble codes the ECM has stored. A trouble code is a code stored in the ECM memory when it detects a fault or error in any of its sensor readings. This is commonly seen by the end user as a “service engine soon” light on the dash board. The ECM code masks generally have 64 trouble codes stored in 8 bytes, with each bit representing a trouble code. A mode 10 Command Set can be transmitted to the ECM to clear all stored trouble codes.