10
edits
Changes
no edit summary
=== Module IDs ===
=== Module IDs ===
The table below lists IDs for various modules across several Commodore models.
The table below lists IDs for various modules across several Commodore models.<ref>[https://pcmhacking.net/forums/viewtopic.php?f=10&t=2857&sid=9043dc10c08dc6a2b63e2bccc31c4039 pcmhacking.net - GM Reverse Engineering]</ref>
{|class="wikitable"
{|class="wikitable"
| align="center" | <code>BD</code> || BCM (VR/VS)
| align="center" | <code>BD</code> || BCM (VR/VS)
|-
|-
| align="center" | <code>F0</code> || ALDL Tester
| align="center" | <code>E4</code> || Telematics Module (VY)
|-
| align="center" | <code>EA</code> || ECC - Climate Control (VY)
|-
| align="center" | <code>EB</code> || Radio (VY)
|-
| align="center" | <code>F0</code> || ALDL Tester/Scan Tool
|-
|-
| align="center" | <code>F1</code> || BCM (VT/VX/VY)
| align="center" | <code>F1</code> || BCM (VT/VX/VY)
|-
|-
| align="center" | <code>F2</code> || SRS (VR/VS)
| align="center" | <code>F2</code> || SRS (VR/VS)
|-
| align="center" | <code>F3</code> || PIM (VY)
|-
|-
| align="center" | <code>F4</code> || PCM (VR/VS V8)
| align="center" | <code>F4</code> || PCM (VR/VS V8)
| align="center" | <code>F7</code> || PCM (VX/VY)
| align="center" | <code>F7</code> || PCM (VX/VY)
|-
|-
| align="center" | <code>F9</code> || ABS (VR/VS)
| align="center" | <code>F9</code> || ABS/TCS (VR/VS)
|-
|-
| align="center" | <code>FA</code> || SRS (VT)
| align="center" | <code>FA</code> || SRS (VT)
|-
| align="center" | <code>FB</code> || SRS (VX/VY)
|}
|}
== Modes ==
== Modes ==
ALDL diagnostic requests work on the principle of '''modes'''. To issue a diagnostic request, an ALDL frame is sent with an ID corresponding to a module's diagnostic ID (see [[#Module IDs|Module IDs]]), and the first data byte set to the mode number of the request. ALDL diagnostic requests will therefore always have a minimum of 1 data byte. A typical response to a diagnostic request will be an ALDL frame with the same ID as the original request, the first data byte set to the mode number of the request, and an optional number of extra data bytes forming the response. The table below lists the various ALDL modes.
{|class="wikitable"
{|class="wikitable"
=== Mode 0 ===
=== 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.
ALDL Mode 0, or '''Normal Mode''' reverts the effect of any previous ALDL requests (except requests with lasting effect such as a DTC clear), returning the addressed module to normal operation.
=== Mode 1 ===
=== Mode 1 ===
|-
|-
| align="center" | 2 || Address || align="center" | ''n'' || 16-bit address in big endian format
| align="center" | 2 || Address || align="center" | ''n'' || 16-bit address in big endian format
|-
| align="center" | 1 || Checksum || align="center" | ||
|}
=== Mode 4 ===
A Mode 4 request is used to control a module for testing purposes. Control can include anything from slewing or setting fixed output values, slewing or setting fixed input sensor values, altering the results of certain calculations and invoking certain module functions. Modules that respond to Mode 4 requests include the; PCM, BCM, [[Holden:Instrument Cluster|instrument cluster]] and ABS/TCS modules. The structure of a Mode 4 request differs greatly depending on the module it is addressed to. The basic structure of a Mode 4 request is illustrated by the table below.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | || ID of the module to be controlled
|-
| align="center" | 1 || Length || align="center" | <code>55</code> + 1 + ''n'' ||
|-
| align="center" | 1 || Mode || align="center" | <code>04</code> ||
|-
| align="center" | ''n'' || Control Structure || align="center" | || Varies depending on module
|-
|-
| align="center" | 1 || Checksum || align="center" | ||
| align="center" | 1 || Checksum || align="center" | ||
=== Mode 8 ===
=== 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.
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 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"
{|class="wikitable"