10
edits
Changes
no edit summary
== Overview ==
'''ALDL''' or '''Assembly Line Diagnostic Link''' is the diagnostic interface created by GM and used by Holden on the Commodore models from the VN to the VZ. The VE is the first Commodore to exclusively use CAN bus for diagnostics and inter-module communication. The VN through to VS Commodores used GM's original 160 baud interface (compatible with a GM Tech 1 or Tech 2 scan tool), whilst the VT through to VZ Commodores used the newer 8192 baud interface (compatible with a Tech 2 scan tool). This article will focus on the 8192 baud interface. For information on the 160 baud interface, see [[Holden:ALDL (160 Baud)|ALDL (160 Baud)]].
== Frame Structure ==
An ALDL frame consists of a message ID, length, an optional number of data bytes (up to 64 bytes), and a 2's compliment checksum. The table below illustrates the structure of an ALDL frame.
{| class="wikitable"
! Length (bytes) !! Field !! Notes
|-
| align="center" | 1 || Message ID || The value <code>0</code> is reserved and is not a valid ALDL message ID
|-
| align="center" | 1 || Length || <code>0x55</code> + ''n'', where ''n'' is the number of data bytes (up to 64)
|-
| align="center" | ''n'' || Data ||
|-
| align="center" | 1 || Checksum || 2's compliment checksum of all bytes in the frame (message ID, length, and data bytes)
|}
=== Module IDs ===
The table below lists IDs for various modules across several Commodore models.
{|class="wikitable"
! ID !! Module
|-
| align="center" | <code>BD</code> || BCM (VR/VS)
|-
| align="center" | <code>F0</code> || ALDL Tester
|-
| align="center" | <code>F1</code> || BCM (VT/VX/VY)
|-
| align="center" | <code>F2</code> || SRS (VR/VS)
|-
| align="center" | <code>F4</code> || PCM (VR/VS V8)
|-
| align="center" | <code>F5</code> || PCM (VS V6/VT)
|-
| align="center" | <code>F7</code> || PCM (VX/VY)
|-
| align="center" | <code>F9</code> || ABS (VR/VS)
|-
| align="center" | <code>FA</code> || SRS (VT)
|}
=== Checksum Calculation ===
An ALDL checksum is calculated by adding every byte prior to the checksum field (ID byte, length byte, and data bytes), and calculating the 2's compliment of the last 8 bits in the sum. Verification works in a similar manner; all bytes of the frame are added (including the checksum byte). The last 8 bits of the sum will equal 0 if the sum is valid.
== Modes ==
{|class="wikitable"
! Mode (decimal) !! Description
|-
| align="center" | <code>00</code> || Normal Mode
|-
| align="center" | <code>01</code> || Live Data
|-
| align="center" | <code>02</code> || Memory Block Read
|-
| align="center" | <code>03</code> || Memory Scatter Read
|-
| align="center" | <code>04</code> || Control Function
|-
| align="center" | <code>08</code> || Disable Bus Chatter
|-
| align="center" | <code>09</code> || Enable Bus Chatter
|-
| align="center" | <code>10</code> || Clear DTCs
|}
=== Mode 0 ===
ALDL Mode 0, or '''Normal Mode''' reverts any previous ALDL commands (except commands with lasting effect such as a DTC clear), returning the addressed module to normal operation.
=== Mode 1 ===
Mode 1 is used to retrieve live data.
=== Mode 2 ===
Mode 2 requests are used to retrieve a block of 64 bytes from the [[Holden:Power-train Control Module|PCM]]'s memory<ref>[http://calibra-classic.org/pages/ecu2pc1.htm#ALDLMode2 Calibra Classic - ECU2PC (ALDL Mode 2)]</ref>. Any 16-bit address within the processor's memory address space may be requested{{Cn}}. This means that ROM, RAM, calibration data and I/O registers may be retrieved with Mode 2 requests. Whilst Mode 2 requests memory in blocks of 64 bytes, the requested address does not need to be aligned on a 64 byte boundary. This may be useful for reducing the number of requests required for values in close proximity to one another. The below table illustrates the full structure of a Mode 2 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | <code>F1</code> ||
|-
| align="center" | 1 || Length || align="center" | <code>58</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>02</code> ||
|-
| align="center" | 2 || Address || align="center" | ''n'' || 16-bit address in big endian format
|-
| align="center" | 1 || Checksum || align="center" | ||
|}
=== Mode 8 ===
Periodically, the BCM sends polling requests amongst other data on the bus. These requests poll the ECM for sensor data and operational parameters used by the [[Holden:Instrument Cluster|instrument cluster]]. A Mode 8 request is used to temporarily disable these messages from being sent. This essentially silences the BCM and quietens the bus, allowing for another device such as a computer or scan tool to transmit with a lower chance of a [https://en.wikipedia.org/wiki/Collision_domain#:~:text=A%20network%20collision%20occurs%20when%20more%20than%20one%20device%20attempts%20to%20send%20a%20packet%20on%20a%20network%20segment%20at%20the%20same%20time packet collision]. Unless another Mode 8 request is sent within a predetermined amount of time{{When}}, the BCM will automatically resume normal bus operation. The below table illustrates the full structure of a Mode 8 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value
|-
| align="center" | 1 || ID || align="center" | <code>F1</code>
|-
| align="center" | 1 || Length || align="center" | <code>56</code>
|-
| align="center" | 1 || Mode || align="center" | <code>08</code>
|-
| align="center" | 1 || Checksum || align="center" | <code>B1</code>
|}
=== Mode 9 ===
Similar to [[#Mode 8|Mode 8]], a Mode 9 request will re-enable BCM chatter. A Mode 9 request can be sent to enable bus chatter earlier, rather than waiting for the original Mode 8 request to time out. This may be useful (and potentially good practice) if a device only requires bus silence for a short period of time, as bus silence for longer periods of time can lead to Check Engine warnings on the cluster{{Cn}}. The below table illustrates the full structure of a Mode 9 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value
|-
| align="center" | 1 || ID || align="center" | <code>F1</code>
|-
| align="center" | 1 || Length || align="center" | <code>56</code>
|-
| align="center" | 1 || Mode || align="center" | <code>09</code>
|-
| align="center" | 1 || Checksum || align="center" | <code>B0</code>
|}
=== Mode 10 ===
The majority of modules in the vehicle can have stored DTCs cleared with a Mode 10 request. These include, but are not limited to; the PCM, BCM, ABS/TCS, SRS modules as well as the instrument cluster. The below table illustrates the full structure of a Mode 10 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | || ID of the module DTCs will be cleared from (see [[#Module IDs|Module IDs]]).
|-
| align="center" | 1 || Length || align="center" | <code>56</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>0A</code> ||
|-
| align="center" | 1 || Checksum || align="center" | ||
|}
== References ==
<references/>
'''ALDL''' or '''Assembly Line Diagnostic Link''' is the diagnostic interface created by GM and used by Holden on the Commodore models from the VN to the VZ. The VE is the first Commodore to exclusively use CAN bus for diagnostics and inter-module communication. The VN through to VS Commodores used GM's original 160 baud interface (compatible with a GM Tech 1 or Tech 2 scan tool), whilst the VT through to VZ Commodores used the newer 8192 baud interface (compatible with a Tech 2 scan tool). This article will focus on the 8192 baud interface. For information on the 160 baud interface, see [[Holden:ALDL (160 Baud)|ALDL (160 Baud)]].
== Frame Structure ==
An ALDL frame consists of a message ID, length, an optional number of data bytes (up to 64 bytes), and a 2's compliment checksum. The table below illustrates the structure of an ALDL frame.
{| class="wikitable"
! Length (bytes) !! Field !! Notes
|-
| align="center" | 1 || Message ID || The value <code>0</code> is reserved and is not a valid ALDL message ID
|-
| align="center" | 1 || Length || <code>0x55</code> + ''n'', where ''n'' is the number of data bytes (up to 64)
|-
| align="center" | ''n'' || Data ||
|-
| align="center" | 1 || Checksum || 2's compliment checksum of all bytes in the frame (message ID, length, and data bytes)
|}
=== Module IDs ===
The table below lists IDs for various modules across several Commodore models.
{|class="wikitable"
! ID !! Module
|-
| align="center" | <code>BD</code> || BCM (VR/VS)
|-
| align="center" | <code>F0</code> || ALDL Tester
|-
| align="center" | <code>F1</code> || BCM (VT/VX/VY)
|-
| align="center" | <code>F2</code> || SRS (VR/VS)
|-
| align="center" | <code>F4</code> || PCM (VR/VS V8)
|-
| align="center" | <code>F5</code> || PCM (VS V6/VT)
|-
| align="center" | <code>F7</code> || PCM (VX/VY)
|-
| align="center" | <code>F9</code> || ABS (VR/VS)
|-
| align="center" | <code>FA</code> || SRS (VT)
|}
=== Checksum Calculation ===
An ALDL checksum is calculated by adding every byte prior to the checksum field (ID byte, length byte, and data bytes), and calculating the 2's compliment of the last 8 bits in the sum. Verification works in a similar manner; all bytes of the frame are added (including the checksum byte). The last 8 bits of the sum will equal 0 if the sum is valid.
== Modes ==
{|class="wikitable"
! Mode (decimal) !! Description
|-
| align="center" | <code>00</code> || Normal Mode
|-
| align="center" | <code>01</code> || Live Data
|-
| align="center" | <code>02</code> || Memory Block Read
|-
| align="center" | <code>03</code> || Memory Scatter Read
|-
| align="center" | <code>04</code> || Control Function
|-
| align="center" | <code>08</code> || Disable Bus Chatter
|-
| align="center" | <code>09</code> || Enable Bus Chatter
|-
| align="center" | <code>10</code> || Clear DTCs
|}
=== Mode 0 ===
ALDL Mode 0, or '''Normal Mode''' reverts any previous ALDL commands (except commands with lasting effect such as a DTC clear), returning the addressed module to normal operation.
=== Mode 1 ===
Mode 1 is used to retrieve live data.
=== Mode 2 ===
Mode 2 requests are used to retrieve a block of 64 bytes from the [[Holden:Power-train Control Module|PCM]]'s memory<ref>[http://calibra-classic.org/pages/ecu2pc1.htm#ALDLMode2 Calibra Classic - ECU2PC (ALDL Mode 2)]</ref>. Any 16-bit address within the processor's memory address space may be requested{{Cn}}. This means that ROM, RAM, calibration data and I/O registers may be retrieved with Mode 2 requests. Whilst Mode 2 requests memory in blocks of 64 bytes, the requested address does not need to be aligned on a 64 byte boundary. This may be useful for reducing the number of requests required for values in close proximity to one another. The below table illustrates the full structure of a Mode 2 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | <code>F1</code> ||
|-
| align="center" | 1 || Length || align="center" | <code>58</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>02</code> ||
|-
| align="center" | 2 || Address || align="center" | ''n'' || 16-bit address in big endian format
|-
| align="center" | 1 || Checksum || align="center" | ||
|}
=== Mode 8 ===
Periodically, the BCM sends polling requests amongst other data on the bus. These requests poll the ECM for sensor data and operational parameters used by the [[Holden:Instrument Cluster|instrument cluster]]. A Mode 8 request is used to temporarily disable these messages from being sent. This essentially silences the BCM and quietens the bus, allowing for another device such as a computer or scan tool to transmit with a lower chance of a [https://en.wikipedia.org/wiki/Collision_domain#:~:text=A%20network%20collision%20occurs%20when%20more%20than%20one%20device%20attempts%20to%20send%20a%20packet%20on%20a%20network%20segment%20at%20the%20same%20time packet collision]. Unless another Mode 8 request is sent within a predetermined amount of time{{When}}, the BCM will automatically resume normal bus operation. The below table illustrates the full structure of a Mode 8 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value
|-
| align="center" | 1 || ID || align="center" | <code>F1</code>
|-
| align="center" | 1 || Length || align="center" | <code>56</code>
|-
| align="center" | 1 || Mode || align="center" | <code>08</code>
|-
| align="center" | 1 || Checksum || align="center" | <code>B1</code>
|}
=== Mode 9 ===
Similar to [[#Mode 8|Mode 8]], a Mode 9 request will re-enable BCM chatter. A Mode 9 request can be sent to enable bus chatter earlier, rather than waiting for the original Mode 8 request to time out. This may be useful (and potentially good practice) if a device only requires bus silence for a short period of time, as bus silence for longer periods of time can lead to Check Engine warnings on the cluster{{Cn}}. The below table illustrates the full structure of a Mode 9 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value
|-
| align="center" | 1 || ID || align="center" | <code>F1</code>
|-
| align="center" | 1 || Length || align="center" | <code>56</code>
|-
| align="center" | 1 || Mode || align="center" | <code>09</code>
|-
| align="center" | 1 || Checksum || align="center" | <code>B0</code>
|}
=== Mode 10 ===
The majority of modules in the vehicle can have stored DTCs cleared with a Mode 10 request. These include, but are not limited to; the PCM, BCM, ABS/TCS, SRS modules as well as the instrument cluster. The below table illustrates the full structure of a Mode 10 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | || ID of the module DTCs will be cleared from (see [[#Module IDs|Module IDs]]).
|-
| align="center" | 1 || Length || align="center" | <code>56</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>0A</code> ||
|-
| align="center" | 1 || Checksum || align="center" | ||
|}
== References ==
<references/>