|
Page 247
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:
--``,,``````,``,,``,,,`,`,`,,
Do'stlaringiz bilan baham: |
