GM WORLDWIDE ENGINEERING STANDARDS
GMW3110
© Copyright 2010 General Motors All Rights Reserved
February 2010
Page 32 of 336
4.5.1.3 Normal Addressing - Flow Control Frames.
Table 22 shows the definition of the Flow Control frame
generated by the network layer of the node (or the tester) when receiving multi-frame messages.
Table 22: Flow Control Frame Examples
Addressing Scheme Name
Identifier
CAN frame data field
Description
ID
1
2
3
4
5
6
7
8
FlowControl
CAN Id
PCI
4.5.1.4 Extended Addressing - Functional Request Messages.
Functionally
addressed request messages
shall always be single frame and shall use the
“extended addressing” frame format, where the combination of
CANId (one of the reserved Functional CAN Identifiers) and an additional data byte (extended address byte, or
EA) indicates the target node(s). Usually, the extended address byte will designate a node or group of nodes
operating as a specific functional sub-system. However, all resulting response messages will be formatted as
physical diagnostic responses with normal addressing (USDT single or multi-frame response, or a UUDT
response. See diagnostic USDT and UUDT response frame format examples above).
Diagnostic request messages using extended addressing shall always be
USDT messages and have the
specific frame formats shown in Table 23 (the legend used is the same as the three previous tables).
Table 23: Diagnostic Request Frame Examples with Extended Addressing
Addressing Scheme Name
Identifier
CAN frame data field
Description
ID
1
2
3
4
5
6
7
8
EXTENDED - SingleFrame
CAN Id
EA
PCI
SIDRQ
LEV/
Data
Data
Data
Data
Data
Note:
See OSEK-COM specification for further details about the UUDT/USDT protocol (message formats,
service primitives).
4.6 ECU Frame Padding Requirements.
GMLAN ECUs shall be capable of receiving diagnostic request
messages that are padded. GMLAN ECUs should be capable of receiving diagnostic
messages that are not
padded.
Note:
Frame padding is adding additional data bytes to a transmitted frame (e.g., single frame, flow control
frame, or the last frame of a multi-frame message) to ensure that the data length
code in the CAN header
control field is fixed to 8 bytes.
An ECU can choose to transmit enhanced diagnostic response messages with or without padding (without
padding is preferred to minimize bus bandwidth). These requirements are applicable to the ECU when
executing either the application software or the boot software. An ECU that does not support the reception of
non-padded diagnostic request messages shall document this in a CTS, SSTS,
or supplemental diagnostic
specification referenced in a CTS or SSTS.
Note:
This specification places no requirements on the value of the pad bytes used in either a diagnostic
request or response message. However, it is recommended to use values of either $55 or $AA (alternating bit
patterns).
Note:
The padding requirements detailed in this section deal with frames transmitted for the enhanced
diagnostic services described in Section 8
of this document, however, implementation of diagnostic services
legislated by OBD/EOBD regulations for ECUs classified as
“emission” devices shall comply with ISO 15765-4
which specifies that OBD diagnostic response messages must be padded.
Do'stlaringiz bilan baham: