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 247 of 336 
Procedure 6: 
(For Devices that support Device Control Security Access for Restriction Overrides.)
 
1. Access the device control security level (via $27 service) and repeat procedure 4 for each device control 
that has a manufacturing restriction that differs from the service restriction and verify that device controls 
remain active and that no negative response is sent. 
2. After step 1 above, send no messages for P3
C
and verify that all device controls are cancelled. Then 
repeat step 1 of procedure 4 (for a single device control) and verify that the device control restrictions are 
enabled. 
Procedure 7: 
(Additional checks if the ECU supports negative response code $78.)
 
1. Create conditions under which the ECU should return the $7F $AE $78 response. Send a valid request for 
this service (including applicable CPID and device control parameters) and verify that the $7F $AE $78 
response is received followed by the appropriate final response within the P2
C*
timing window. 
2. Repeat step 1 of this procedure for each possible combination of device control and RC = $78 reason. 
8.20.8 Tester Implications. 
If DTCs are inhibited as a result of this service, a $20 service request message or 
TesterPresent timeout shall be required to re-enable the DTC logic. 
This service should only be requested using physical addressing. 
9 ECU Programming Requirements and Process 
9.1 
This chapter defines the requirements for programming nodes on a GMLAN serial data link using the 
Service Programming System (SPS) and the utility file concept. The GMLAN programming process is also 
detailed in this chapter. 
The programming requirement sections describe general compliance requirements, minimum diagnostic 
service implementation requirements, boot memory requirements, and specific vehicle assembly plant 
performance requirements for programmable ECUs. A section is also included that defines additional 
requirements for all ECUs (includes non-programmable ECUs). Non-programmable ECUs shall also meet the 
requirements in this section in order to ensure that they are tolerant of a programming event. 
The programming process sections describe the steps needed and the diagnostic services required for those 
steps. This process was defined in order to create a common utility file for service and assembly plant 
programming procedures. The programming process described in this chapter provides the possibility for the 
simultaneous programming of multiple GMLAN ECUs on a single vehicle, independent of subnet location, and 
within a single programming event. Simultaneous programming of ECUs can be accomplished by having the 
programming tool process utility files in parallel (which is desirable for vehicle assembly plant usage). This 
process also allows for sequential programming of multiple ECUs or the programming of an individual ECU. 
Note:
Although the GMLAN programming procedure supports the simultaneous programming of multiple 
GMLAN ECUs, the service procedures may only support the programming of an individual ECU. 

ECU Programming General Requirements/Information. 
The SPS programming process can be applied to an SPS programmable ECU in order to: 

Reprogram an ECU which has previously been fully programmed. 

Program an ECU which is shipped to the vehicle assembly plant or service facility without some element of 
its full combination of operational software and calibration data. (See Note Below). 
Note:
This does not include vehicle option content data written to the device using the WriteDataByIdentifier 
($3B) service unless specified in a CTS or supplemental ECU diagnostic specification. 

Reprogram an ECU which has detected an error with memory locations containing software or calibration 
which forces the ECU to run out of boot software. 
SPS programmable ECUs fall into three categories: SPS_TYPE_A, SPS_TYPE_B, or SPS_TYPE_C. 

SPS_TYPE_A: 
An SPS_TYPE_A ECU is a programmable ECU that has already been fully programmed (either by the ECU 
supplier, the vehicle assembly plant, or in the service environment). SPS_TYPE_A ECUs are fully functional 
and can receive diagnostic requests and respond to them using the appropriate diagnostic CAN Identifiers as 
outlined in this specification in paragraph 4.4 These CAN Identifiers shall be further referenced as permanent 
diagnostic CAN Identifiers. 

SPS_TYPE_B/SPS_TYPE_C: 
--``,,``````,``,,``,,,`,`,`,,-`-`,,`,,`,`,,`---
CameraLoops.com

---