The EOLGM component implements a protocol mix used in several GM hardware components.
For further details refer to the SiemensVDO document "End Of Line Protocol". The
EOLGM component is intended to be used together with a CAN component.
In contrast to other ECUs supporting the EOL protocol GM hardware is somewhat special. The complete diagnosis suite
consists of four incompatible protocols:
GMLan mode
The normal diagnosis operation mode is GMLan. There is no SiemensVDO compatible EOL
or production diagnosis activation procedure, so a GMLan service has to be issued to leave the GMLan mode.
Production diagnosis mode
When the GMLan mode is left the ECU enters a production diagnosis mode. This mode is similar, but not compatible with
the EOL protocol. The major differences are:
- No special activation is required after GMLan mode is left.
- A tester present service is defined and may be required to avoid session timeouts.
- The service id is mirrored to the response to distinguish responses when issuing concurrent services (which is not
supported by the EOLGM component).
- More error codes than for EOL are defined, especially for busyRepeatRequest and responsePending.
EOL mode
The EOL mode itself is compatible with the SiemensVDO EOL protocol but still differs regarding the activation:
To enter EOL mode a special service is defined which is not answered by the ECU. After that the ECU switches to
a higher bitrate and expects the EOL activation sequence which must not change the bitrate again.
Flash mode
When the flash toolbox is downloaded another unnamed protocol is used for the remaining flash process.
Remarks
The single wire CAN with support of a high voltage wakeup may not be supported by most CAN hardware. At current the
only hardware supporting this feature which is known to work with the AIDA CAN component are the CANcardX, CANcardY and
CANcardXL from Vector Informatik with an appropriate CANcab attached (e. g. type 5790c).
To avoid flooding of the CAN cell when no ECU is connected, specific AIDA_bDataFlags of the
CAN component are monitored. This has been successfully tested only with CAN hardware from Vector Informatik.
For a bitrate change the stack temporarily goes offline which is a normal behaviour and must not be treated
as an error situation by the application. The stack status events are filtered and thus will not be visible
to the application.
Even though the stack may go offline during the activation procedure the stack may not be unloaded at this
time. The component will block the corresponding API functions.
Currently the component supports only the GM production diagnosis and the GM EOL variant. To make the use easier the GMLan
wakeup CAN id and the services can be entered in raw format. If the transmit data string is set the component
wakes the ECU and issues the configured service. Note that the request and the response must be single frame
data and must contain the whole CAN frame data.
The flash protocol is not supported at all.
The answer data format is not being unified by the component which means that the application also must track
the communication state to interpret the answers correctly.
As the EOL mode does not have any timeout the component provides a method of directly setting the mode of communication.
This might e. g. be necessary if the ECU is reset by other means or if the stack is set offline while the component
was in EOL mode.
With AIDA_bDataFlags in transmit data events the communication mode of the
component can be set (see header file bsk_aida_eolgm.h).
With the flag EOLGM_nMSGFLAG_CLREOL (0x01) the component is switched to production diagnosis mode (only possible
while in EOL mode), with the flag EOLGM_nMSGFLAG_SETEOL (0x02) the component is switched to EOL mode (only possible
while not in EOL mode). The CAN bitrate will be adapted accordingly. The mode switch is being executed before the event is sent.
Furthermore the component provides a raw data flag (EOLGM_nMSGFLAG_RAW 0x04) which is provided for compatibility with
the EOLTest component. Its usage is strictly discouraged as it breaks the ISO/OSI layer model.
As of version 1.02.004 SR 8 the parametrisation of the component has been enhanced. Configuration files made with previous versions of the component are not compatible.
Parameters
-
LowBitrate
-
The CAN bitrate to be used when not in EOL mode.
-
HighBitrate
-
The CAN bitrate to be used when in EOL mode.
-
BitrateSwitchIdleTime
-
The idle time after a bitrate change before the component goes on bus again. Note that a bitrate change requires to set
the stack offline internally which may take some time (several 100ms). See parameter OfflineOnlineLatency
-
SendID
-
Source ID for transmitted CAN messages. The component only supports a single ID for GMLan, production diagnosis
and EOL transmissions.
-
ReceiveID
-
Source ID expected for received messages. The component only supports a single ID for GMLan, production diagnosis
and EOL transmissions.
-
GMLanModeHVWUPID
-
Source ID used for wakeup messages. This parameter is only used if GMLanModeProductionDiagnosisRequest is not empty.
-
GMLanModeProductionDiagnosisRequest
-
Hexadecimal string containing the raw production diagnosis service request. The string must consist of an even number of hexadecimal digits without any spaces.
The component only allows to transmit a single CAN message so the service must fit into a single frame. The service string is sent without creating a USDT
header so the parameter must contain the actual content of the CAN message as it would be sent by the USDT or
GMLanSCT component. When this parameter is empty the parameters GMLanModeHVWUPID, GMLanModeProductionDiagnosisResponse,
GMLanModeResponseTimeout and GMLanModeRetries will have no meaning and will be blocked from editing and saving.
-
GMLanModeProductionDiagnosisResponse
-
Hexadecimal string containing the raw production diagnosis service response. The string must consist of an even number of hexadecimal digits without any spaces.
The component only allows to receive a single CAN message so the service must fit into a single frame. The service string is compared to a received CAN message
without stripping the header so the parameter must contain the actual content of the CAN message as it would be received by the USDT or
GMLanSCT component. The received message is allowed to be longer than the message configured by the paramter which is useful to ignore
padding bytes for which USDT/GMLan does not specify the content. This parameter is only used if GMLanModeProductionDiagnosisRequest is not empty.
-
GMLanModeResponseTimeout
-
Timeout in [ms] where the answer for the GMLanModeProductionDiagnosisRequest must arrive. This parameter is only used if GMLanModeProductionDiagnosisRequest is not empty.
-
GMLanModeRetries
-
Number of retries for the whole wakeup and production diagnosis request procedure. This parameter is only used if GMLanModeProductionDiagnosisRequest is not empty.
-
ProductionDiagnosisModeEOLActivationModeRequest
-
Hexadecimal string containing the production diagnosis service to request EOL mode. The string must consist of an even number of hexadecimal digits without any spaces. Note that this service does
not provide a positive response which is quite problematic as a bitrate switch follows but the component must wait for the configured timeout time for a possible negative
response. When the switch to EOL mode is successful the component fakes a positive response for the application.
-
ProductionDiagnosisModeResetServiceString
-
Hexadecimal string containing the production diagnosis service to reset the ECU. The string must consist of an even number of hexadecimal digits without any spaces.
The component monitors all transmit events issued by the application to detect a communication stop as well as it will issue this service itself if any other service
is sent containing a stop communication flag while in production diagnosis mode.
-
ProductionDiagnosisModeTesterPresentServiceString
-
Hexadecimal string containing the TesterPresent service while the component is in production diagnosis mode. The string must consist of an even number of hexadecimal digits without any spaces.
-
ProductionDiagnosisModeTesterPresentInterval
-
Interval in [ms] for the TesterPresent service. Will be sent if the communication is established and component is idle. Set to 0 to
disable the TesterPresent service. Note that this parameter only has a meaning when ProductionDiagnosisModeTesterPresentServiceString is not empty and will be blocked from being edited and saved
otherwise.
-
ProductionDiagnosisModeResponseTimeout
-
Specifies in units of [ms] how long the component waits for the reception of the first CAN message after sending to the ECU (production diagnosis mode).
-
ProductionDiagnosisModeRetries
-
Maximum number of retries in the production diagnosis mode.
-
EOLActivationModeEOLModeRequest
-
Hexadecimal string containing the request for EOL mode activation. The string must consist of an even number of hexadecimal digits without any spaces.
-
EOLActivationModeEOLModeResponse
-
Hexadecimal string containing the response for EOL mode activation. The string must consist of an even number of hexadecimal digits without any spaces.
-
EOLActivationModeResponseTimeout
-
Specifies in units of [ms] how long the component waits for the reception of the CAN message after sending to the ECU (EOL activation mode).
-
EOLActivationModeRetries
-
Maximum number of retries in the EOL activation mode.
-
EOLModeResetServiceString
-
Hexadecimal string containing the EOL diagnosis service to reset the ECU. The string must consist of an even number of hexadecimal digits without any spaces.
The component monitors all transmit events issued by the application to detect a communication stop as well as it will issue this service itself if any other service
is sent containing a stop communication flag while in EOL diagnosis mode.
-
EOLModeResponseTimeout
-
Specifies in units of [ms] how long the component waits for the reception of the first CAN message after sending to the ECU (EOL diagnosis mode).
-
EOLModeRetries
-
Maximum number of retries in the EOL diagnosis mode.
-
TxIntermessageTimeout
-
Specifies in units of [ms] how long the component waits between sending of CAN messages (production and EOL diagnosis mode).
-
RxIntermessageTimeout
-
Specifies in units of [ms] how long the component waits between CAN messages received from the component below (from end of reception of one CAN message to the end of reception
of the next CAN message, production and EOL diagnosis mode).
-
BusyRepeatRequestIdleTime
-
Specifies in units of [ms] how long the component waits before a retry due to a busy response. If TesterPresentInterval is not set to 0 be sure to keep the idle time lower
than TesterPresentInterval as otherwise session timeouts may occur. Note that this parameter currently only is used while in production diagnosis mode.
-
BusyRepeatRequestRetries
-
Specifies how often the component does a retry due to a busy response. Note that this parameter currently only is used while in production diagnosis mode.
-
PositiveResponseCodes
-
Hexadecimal string containing all error codes to be treated as positive response. The string must consist of an even number of hexadecimal digits without any spaces (production and EOL diagnosis mode).
-
ResponsePendingCodes
-
Hexadecimal string containing all error codes to trigger the response pending handling. The string must consist of an even number of hexadecimal digits without any spaces (production diagnosis mode).
-
BusyRepeatRequestCodes
-
Hexadecimal string containing all error codes that should lead to a retry. The string must consist of an even number of hexadecimal digits without any spaces (production diagnosis mode).
-
CommuStartIdleTime
-
Time in units of [ms] since the last bus activity before the component tries another communication start.
-
WakeupTime
-
Specifies in units of [ms] how long the component waits for Wakeup.
-
ModeChangeTime
-
Specifies in units of [ms] how long the component waits for a mode change to GMLan mode.
-
MaxLatency
-
EXPERT PARAMETER, Change is strongly discouraged. Internal maximum latency in [ms], will be added once when waiting for events, twice for the generation of status events.
-
OfflineOnlineLatency
-
EXPERT PARAMETER, Change is strongly discouraged. Latency for setting the stack internally online or offline in [ms]. Times are in the order of several 100ms and dependent of used hardware and production or debug library.
-
CommuState
-
A read only parameter where the application can poll the current communication state of the component:
| -1 |
EOLGM_nenCsStopped |
No communication is active. |
| 0 |
EOLGM_nenCsGMLan |
The component currently handles the wakeup and mode switch to production diagnosis. |
| 1 |
EOLGM_nenCsPD |
The production diagnosis is active. |
| 2 |
EOLGM_nenCsPDSwitchBitrate |
The component has detected a EOL mode service request and currently switches to the EOL mode bitrate. |
| 3 |
EOLGM_nenCsEOLAct |
The component currently handles the EOL activation. |
| 4 |
EOLGM_nenCsEOL |
The component is in EOL mode. |
See Also
AIDA Overview, list of AIDA components