$EE ALDL Communications

ALDL Message Format

$EE datastream messages, both to and from the ECM, are formatted as follows:

[DEVICE] [LENGTH] [MODE] [MESSAGE …] [CHECKSUM]

DEVICE: 0xF4 for T-Side or 0xE4 for E-Side.  The E-side doesn’t respond to very many requests by default.

LENGTH: The overall length of the message (including checksum, device, etc) plus (dec)82.  This provides a theoretical limit of 173 Bytes, minus header and checksum, only 170 bytes may be communciated during a request…

MODE: See mode table below.

MESSAGE: Any actual data transmitted.

CHECKSUM: This primitive checksum helps garuntee data integrety, and without a correct checksum, the data is rejected.  This is a “1s compliment” checksum (when all bytes including the checksum are added, or summed, the result is zero).

MODE1 – READ DIAGNOSTIC INFORMATION

This mode is commonly used for datalogging, it has various messages that respond with a subset of raw data from memory with engine parameters, malfunction codes, etc.

The message of the request is a single byte indicating the required dataset, and the message in the reply is full of the requested data.

A nearly complete list of mode1 messages is available in these documents: 

Download “LT1 Datastream Definitions” LT1-Datastream-Definitions.zip – Downloaded 313 times – 23 KB

MODE2 – READ MEMORY SEGMENT (64 Bytes)

Dumps 64 bytes of ecm memory when provided with a 16 bit address as two message bytes.  This isn’t address restricted, and can read the eeprom as well.  If you attempt to read memory past the end of the address space, it’ll simply wrap around to the beginning.

MODE3 – READ MEMORY SEGMENT (Arbitrary, 1-84 Bytes)

Takes multiple messages as pairs, and returns the memory contents at those addresses.

MODE4 – TEST ACTUATORS

Manipulate actuators, modes, etc.

This has awesome messages such as ‘fixed timing’ or ‘advance timing’ or ‘disable closed loop’.  The EEHack software suite uses this mode heavily.

I will post a document describing messages for this mode when it’s complete.

MODE5 – ENTER PROGRAMMING MODE

Enter a special mode which accepts mode 6 commands, which write a data segment directly to a specified memory address, then execute it.

This mode has many checks to ensure safety, such as the engine must not be running, and the vehicle must not be moving.

This mode times out fairly quickly, and must be re-enabled before new commands can be sent.

MODE6 –  UPLOAD AND EXECUTE PROGRAM SEGMENT

Enabled only during a Mode5 ‘programming mode’ session.

Specify a memory address and some code, and that code will be written to memory and immediately executed, allowing the ECM to instantly perform any operation that is required by the programmer.

The length of these messages is obviously limited, but by carefully using jump instructions back to the Mode5 loop, longer segments can be appended and finally executed.

MODE7 – BROADCAST

Used for inter-device communication, such as a body control module talking to the ecm.

MODE8 – DISABLE CHATTER

Sending this causes the device to stop sending idle traffic.

This should be sent when a new device (such as a datalogger) is to become the new bus master, and to ensure that the device doesn’t “chat” at random and screw up datalogging or programming.

This is on a timer, it will automatically resume chatter after a predefined period of time.

MODE9 – ENABLE CHATTER

Reverse the effects of Mode8, and resume normal communications.

MODE10 – CLEAR MALF CODES

Simply clears all stored malfunction codes.

MODE12 – PROGRAM AUXILIARY FLASH MEMORY

This is used to program the secondary flash memory with either a new VIN or calibration ID.

This secondary flash memory is completely independant from the main flash memory holding the calibration, so the VIN can persist despite which program is loaded.

Retrieving the current contents can be done with Mode1 or the various memory dump commands.

MODE13 – SECURITY CHALLENGE/RESPONSE

This is the key to unlocking mode 5 (and subsequently mode 6) to execute arbitrary code, including various diagnostic routines.  It’s intended for use by GM developers, as well as TECH reprogramming routines for updating the ECM.

It provides a “seed” (or challenge) and the proper response must be provided to unlock mode 5.  Fortunately they didn’t bother with real encryption; the proper response may be determined or “decoded” by a simple binary NOT operation on the challenge.

The E-Side (which seems to be dead silent) will accept this command as well, enabling it to accept mode5/mode6 operations itself.

The key is always the same between the T-Side and E-Side.

Requesting message 1 will return the challenge.  Then use message 2 for the response.  The ecm responds with message 0xAA when unlock is succesful.