98
edits
Changes
Holden:ALDL (8192 Baud) (view source)
Revision as of 08:50, 11 January 2023
, 08:50, 11 January 2023Added radio status request message ID
== Frame Structure ==
== 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.
An ALDL frame consists of a message ID, length, an optional number of data bytes, and a 2's compliment checksum. Whilst the maximum size of an ALDL frame isn't defined, the length byte allows for up to 170 data bytes (173 bytes total including the ID, length and checksum)<ref>[http://fbodytech.com/misc/ee-aldl-communications/ fbodytech - ALDL Communications]</ref>. Any multi-byte fields are always big-endian unless otherwise noted. The table below illustrates the structure of an ALDL frame.
{| class="wikitable"
{| class="wikitable"
| align="center" | 1 || Message ID || The value <code>0</code> is reserved and is not a valid ALDL message ID
| 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" | 1 || Length || <code>0x55</code> + ''n'', where ''n'' is the number of data bytes
|-
|-
| align="center" | ''n'' || Data ||
| align="center" | ''n'' || Data ||
|}
|}
=== Module IDs ===
=== Message IDs ===
The table below lists IDs for various modules across several Commodore models.<ref>[https://pcmhacking.net/forums/viewtopic.php?f=10&t=2857 pcmhacking.net - GM Reverse Engineering (Page 1)]</ref><ref>[https://pcmhacking.net/forums/viewtopic.php?f=10&t=2857&p=47451#p47451 pcmhacking.net - GM Reverse Engineering (Page 10)]</ref>
All ALDL frames are identified by an ID byte. During normal bus operation, message IDs are used to identify a specific type of message (for example, a PCM heartbeat, or radio status message). Each module is typically assigned a ''diagnostic ID'', that can be used to address the module when issuing diagnostic requests. Most diagnostic frames use the same message ID for both the request, and response. The ID used depends on the module and model year. The table below lists some of the IDs commonly used across various modules on the Commodore models.<ref>[https://pcmhacking.net/forums/viewtopic.php?f=10&t=2857 pcmhacking.net - GM Reverse Engineering (Page 1)]</ref><ref>[https://pcmhacking.net/forums/viewtopic.php?f=10&t=2857&p=47451#p47451 pcmhacking.net - GM Reverse Engineering (Page 10)]</ref>
{|class="wikitable"
{|class="wikitable"
! ID !! Module
! ID !! Source !! Destination !! Description !! Model(s)
|-
|-
| align="center" | <code>BD</code> || BCM (VR/VS)
| align="center" | <code>08</code> || BCM || || Heartbeat Frame || VT/VX/VY/VZ
|-
|-
| align="center" | <code>E4</code> || Telematics Module (VY)
| align="center" | <code>11</code> || BCM || || BCM Status Frame || VT/VX/VY/VZ
|-
|-
| align="center" | <code>EA</code> || ECC - Climate Control (VY)
| align="center" | <code>20</code> || BCM || Cluster || Instrument Cluster Status Request || VT/VX/VY/VZ
|-
|-
| align="center" | <code>EB</code> || Radio (VY)
| align="center" | <code>21</code> || Cluster || || Instrument Cluster Status Response || VT/VX/VY/VZ
|-
|-
| align="center" | <code>F0</code> || ALDL Tester/Scan Tool
| align="center" | <code>40</code> || BCM || PCM || PCM Status Request || VT/VX/VY/VZ
|-
|-
| align="center" | <code>F1</code> || BCM (VT/VX/VY)
| align="center" | <code>41</code> || PCM || || PCM Status Response || VT/VX/VY/VZ
|-
|-
| align="center" | <code>F2</code> || Instrument Cluster (VT/VX/VY)
| align="center" | <code>90</code> || BCM || ABS || ABS Status Request || VT/VX/VY/VZ
|-
|-
| align="center" | <code>F2</code> || SRS (VR/VS)
| align="center" | <code>91</code> || ABS || || ABS Status Response || VT/VX/VY/VZ
|-
|-
| align="center" | <code>F3</code> || PIM (VY)
| align="center" | <code>A0</code> || BCM || SRS || SRS Status Request || VT/VX/VY/VZ
|-
|-
| align="center" | <code>F4</code> || PCM (VR/VS V8)
| align="center" | <code>A1</code> || SRS || || SRS Status Response || VT/VX/VY/VZ
|-
|-
| align="center" | <code>F5</code> || PCM (VS V6/VT)
| align="center" | <code>A8</code> || BCM || ECC || Climate Control Status Request || VT/VX/VY/VZ
|-
|-
| align="center" | <code>F7</code> || PCM (VX/VY)
| align="center" | <code>A9</code> || ECC || || Climate Control Status Response || VT/VX/VY/VZ
|-
|-
| align="center" | <code>F9</code> || ABS/TCS (VR/VS)
| align="center" | <code>B8</code> || BCM || Radio || Radio Status Request || VY/VZ
|-
|-
| align="center" | <code>FA</code> || SRS (VT)
| align="center" | <code>B9</code> || Radio || || Radio Status Response || VY/VZ
|-
|-
| align="center" | <code>FB</code> || SRS (VX/VY)
| align="center" | <code>BD</code> || Scan Tool || BCM || BCM Diagnostics || VR/VS
|-
| align="center" | <code>E4</code> || Scan Tool || Telematics || Telematics Module Diagnostics || VY/VZ
|-
| align="center" | <code>EA</code> || Scan Tool || ECC || Climate Control Diagnostics || VT/VX/VY/VZ
|-
| align="center" | <code>EB</code> || Scan Tool || Radio || Radio Diagnostics || VY/VZ
|-
| align="center" | <code>F0</code> || || || Reserved for ALDL Tester/Scan Tool ||
|-
| align="center" | <code>F1</code> || Scan Tool || BCM || BCM Diagnostics || VT/VX/VY/VZ
|-
| align="center" | <code>F2</code> || Scan Tool || Cluster || Instrument Cluster Diagnostics || VT/VX/VY/VZ
|-
| align="center" | <code>F2</code> || Scan Tool || SRS || SRS Diagnostics || VR/VS
|-
| align="center" | <code>F3</code> || Scan Tool || PIM || PIM Diagnostics || VY/VZ
|-
| align="center" | <code>F4</code> || Scan Tool || PCM || PCM Diagnostics || VR/VS V8
|-
| align="center" | <code>F5</code> || Scan Tool || PCM || PCM Diagnostics || VS V6/VT
|-
| align="center" | <code>F7</code> || Scan Tool || PCM || PCM Diagnostics || VX/VY
|-
| align="center" | <code>F9</code> || Scan Tool || ABS || ABS/TCS Diagnostics || VR/VS
|-
| align="center" | <code>FA</code> || Scan Tool || SRS || SRS Diagnostics || VT
|-
| align="center" | <code>FB</code> || Scan Tool || SRS || SRS Diagnostics || VX/VY
|}
|}
|-
|-
| align="center" | <code>10</code> || Clear DTCs
| align="center" | <code>10</code> || Clear DTCs
|-
| align="center" | <code>13</code> || Security Seed/Key
|}
|}
=== Mode 0 ===
=== Mode 0 ===
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.
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. The table below illustrates the full structure of a Mode 0 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | || ID of the module to return to normal mode
|-
| align="center" | 1 || Length || align="center" | <code>56</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>00</code> ||
|-
| align="center" | 1 || Checksum || align="center" | ''c'' ||
|}
=== Mode 1 ===
=== Mode 1 ===
Mode 1 is used to retrieve live data.
Each module maintains a set of tables containing live data as well as stored parameters. When a device issues a Mode 1 request to a module, it provides the number of the table being requested. The module responds by transmitting the requested table number, followed by the contents of the table (the PCM differs in that it does not transmit the table number, only the table data). The exact contents and structure of the table depend on both the table in question, and the module. Tables are numbered sequentially, however most modules have less than 10 tables. When an invalid table number is requested, the response differs depending on the module the request was issued to. When an invalid table is requested, the PCM will simply not respond. When an invalid table is requested from the BCM, it will send a Mode 13 response. When an invalid table is requested from the ABS/TCS module, the response will be an empty table (the requested table number, followed by 0 bytes of data). The table below illustrates the full structure of a Mode 1 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | <code>F1</code> ||
|-
| align="center" | 1 || Length || align="center" | <code>57</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>01</code> ||
|-
| align="center" | 1 || Table || align="center" | ''n'' || Table number
|-
| align="center" | 1 || Checksum || align="center" | ''c'' ||
|}
=== Mode 2 ===
=== Mode 2 ===
! Length (bytes) !! Field !! Value !! Notes
! Length (bytes) !! Field !! Value !! Notes
|-
|-
| align="center" | 1 || ID || align="center" | <code>F1</code> ||
| align="center" | 1 || ID || align="center" | <code>F7</code> ||
|-
|-
| align="center" | 1 || Length || align="center" | <code>58</code> ||
| align="center" | 1 || Length || align="center" | <code>58</code> ||
| 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" | ||
| align="center" | 1 || Checksum || align="center" | ''c'' ||
|}
Expected response:
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | <code>F7</code> ||
|-
| align="center" | 1 || Length || align="center" | <code>96</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>02</code> ||
|-
| align="center" | 64 || Data || align="center" | || Memory contents at the requested address
|-
| align="center" | 1 || Checksum || align="center" | ''c'' ||
|}
=== Mode 3 ===
Mode 3 requests are used for [[w:Vectored I/O|scatter-gather]] memory operations on the PCM. A Mode 3 request is made with a list of 16-bit memory addresses to be read. The PCM responds with the contents of the requested memory locations. Mode 3 scatter-gather requests are useful for retrieving specific values in memory quickly, without creating the large amount of activity on the bus as Mode 2 block reads. The table below illustrates the full structure of a Mode 3 request.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | <code>F7</code> ||
|-
| align="center" | 1 || Length || align="center" | <code>55</code> + 1 + 2''n'' ||
|-
| align="center" | 1 || Mode || align="center" | <code>03</code> ||
|-
| align="center" | 2 || ''A''<sub>1</sub> || align="center" | || First address to be read
|-
| align="center" colspan="4" | ...
|-
| align="center" | 2 || ''A''<sub>n</sub> || align="center" | ||
|-
| align="center" | 1 || Checksum || align="center" | ''c'' ||
|}
|}
| align="center" | ''n'' || Control Structure || align="center" | || Varies depending on module
| align="center" | ''n'' || Control Structure || align="center" | || Varies depending on module
|-
|-
| align="center" | 1 || Checksum || align="center" | ||
| align="center" | 1 || Checksum || align="center" | ''c'' ||
|}
|}
=== 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 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 PCM 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 BCM will respond with a frame containing a single data byte <code>08</code> with an ID of <code>F1</code> (a frame identical to the request). The below table illustrates the full structure of a Mode 8 request.
{|class="wikitable"
{|class="wikitable"
=== Mode 9 ===
=== 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.
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}}. Note that some scan tools issue a Mode 0 request instead of a Mode 9 request to re-enable BCM chatter{{Cn}}. When a Mode 9 request is sent, the BCM will respond with a frame containing a single data byte <code>09</code> with an ID of <code>F1</code> (a frame identical to the request). The below table illustrates the full structure of a Mode 9 request.
{|class="wikitable"
{|class="wikitable"
| align="center" | 1 || Mode || align="center" | <code>0A</code> ||
| align="center" | 1 || Mode || align="center" | <code>0A</code> ||
|-
|-
| align="center" | 1 || Checksum || align="center" | ||
| align="center" | 1 || Checksum || align="center" | ''c'' ||
|}
=== Mode 13 ===
Mode 13 is used for a challenge-response authentication system in order to unlock flash-based PCMs for programming. Once the PCM is in an ''unlocked'' state, certain restricted operations and Mode 1 tables will become available. The challenge-response calculation itself is fairly straightforward. On request, the PCM will provide a 16-bit value as the ''seed''. All bits of the seed are inverted with an XOR operation, which is sent back to the PCM as the ''key''.<ref>[http://fbodytech.com/misc/ee-aldl-communications/ fbodytech - ALDL Communications]</ref> The tables below illustrate the structure of the seed request, key response and PCM unlock response.
First, a request for ''Table 1'' is made in ''Mode 13''.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | <code>F7</code> ||
|-
| align="center" | 1 || Length || align="center" | <code>57</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>0D</code> ||
|-
| align="center" | 1 || Table || align="center" | <code>01</code> ||
|-
| align="center" | 1 || Checksum || align="center" | <code>A4</code> ||
|}
The PCM will respond with a seed value as the challenge.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | <code>F7</code> ||
|-
| align="center" | 1 || Length || align="center" | <code>59</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>0D</code> ||
|-
| align="center" | 1 || Table || align="center" | <code>01</code> ||
|-
| align="center" | 2 || Seed || align="center" | ''S'' || 16-bit Seed Value
|-
| align="center" | 1 || Checksum || align="center" | ''c'' ||
|}
The key ''K'' is calculated by inverting all bits of the seed ''S'' (for example, <code>A2B9</code> becomes <code>5D46</code>), and transmitted back as a write to ''Table 2'' in ''Mode 13''.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | <code>F7</code> ||
|-
| align="center" | 1 || Length || align="center" | <code>59</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>0D</code> ||
|-
| align="center" | 1 || Table || align="center" | <code>02</code> ||
|-
| align="center" | 2 || Key || align="center" | ''K'' || 16-bit Key Value
|-
| align="center" | 1 || Checksum || align="center" | ''c'' ||
|}
If the key is correct, and the unlock operation is successful, the PCM will respond with ''Table 2'' containing a single value <code>AA</code>. The table below shows the full response that can be expected from the PCM after a successful unlock.
{|class="wikitable"
! Length (bytes) !! Field !! Value !! Notes
|-
| align="center" | 1 || ID || align="center" | <code>F7</code> ||
|-
| align="center" | 1 || Length || align="center" | <code>58</code> ||
|-
| align="center" | 1 || Mode || align="center" | <code>0D</code> ||
|-
| align="center" | 1 || Table || align="center" | <code>02</code> ||
|-
| align="center" | 1 || Status || align="center" | <code>AA</code> || Equals <code>AA</code> on successful unlock
|-
| align="center" | 1 || Checksum || align="center" | <code>F8</code> ||
|}
|}