General Specification Electrical Function gmw3110 General Motors Local Area Network Enhanced Diagnostic Test Mode Specification

GM WORLDWIDE ENGINEERING STANDARDS 
GMW3110 
© Copyright 2010 General Motors All Rights Reserved 
February 2010 
Page 141 of 336 
8.10 DynamicallyDefineMessage ($2C) Service. 
This service is used to dynamically define the contents of 
diagnostic data packets which are formatted as UUDT messages and can be requested via the 
ReadDataByPacketIdentifier ($AA) service. The use of dynamic data packets allows a test device to optimize 
its diagnostic routines and bus bandwidth utilization by packing messages to only contain the diagnostic 
signal/parameter information that is required for the current test. 
8.10.1 Service Description. 
Diagnostic data packets contain a one byte Data Packet Identifier (DPID #) and 
one to seven bytes of signal/parameter data. UUDT diagnostic messages contain a message number and up 
to seven bytes of data. The DPID# for a diagnostic data packet shall be the same as the message number 
used when the diagnostic UUDT message is transmitted (i.e., DPID# $FE will be identified as diagnostic UUDT 
message # $FE). Dynamically definable data packet Identifiers shall start with $FE and be numbered 
sequentially backwards. No DPIDs are allowed to occupy the range of UUDT message numbers from $80 
through $8F as these UUDT message numbers are reserved for the Diagnostic Trouble Code (DTC) services. 
Dynamic data packets will be referenced in subsequent sections of this service as a DPID. 
Each diagnostic signal/parameter is assigned a 2-byte Parameter Identifier (PID) number which is used to 
build the dynamic DPIDs. The term PID will be used to reference diagnostic signals/parameters in subsequent 
sections of this service. 
All of the PIDs packed into a dynamic DPID shall be defined with a single request of this service. This request 
may be a single-frame or multiple-frame message depending on the number of PIDs being packed in the 
DPID. Once the test device receives a positive response from a $2C request, the PIDs in each subsequent 
transmission of the corresponding UUDT message (as requested via service $AA) shall match those of the last 
$2C service request message. A dynamic data packet shall be capable of being initially defined or modified 
any time a node is capable of communications and shall only require a $2C service request to do so (i.e., no 
key cycles or any other special events can be required). It shall also be possible to redefine a DPID while it is 
currently being scheduled by the periodic scheduler. See Service $AA description for more detail on the ability 
to schedule periodic UUDT messages. If the tester redefines a DPID without stopping the scheduler, the PIDs 
in the response message may not be correct until the 2nd response of that message. This is the case because 
a message may be queued for transmission at the time the DPID is being redefined and may not gain access 
to the link until after successful completion of the $2C service. If the tester wants to guarantee that the next 
transmission of the corresponding UUDT message contains the correct information, then the tester should 
remove that DPID from the scheduler prior to redefining it. 
If a $3E (TesterPresent) time-out occurs, or upon receipt of a $20 service (ReturnToNormalMode) request 
message, the device shall retain the contents of all dynamic DPIDs. In addition, the periodic message 
scheduler may be stopped and started without affecting the contents of any dynamic DPIDs. 
A device which implements this service shall be capable of buffering a 3-frame request message. This is the 
maximum number of frames needed to define a single dynamic DPID.