Corporate Group Requirement

Specification

For Programming Control Units

with

Keyword Protocol 2000,

Transport Protocol 2.0

Date: 2003-01-27
Version: 1.1
Authors: Gerhard Bauersachs, EESN/1, Tel: 05361 – 9 – 44003
Michael Zweck, I/EE-92, Tel: 0841 – 89 – 42851

1
1 General Information........................................................................................................... 4
1.1 General requirements................................................................................................. 4
1.2 Further applicable documents .......................................................................................... 5
1.3 Changing history............................................................................................................ 5
1.4 Version administration .................................................................................................... 6
1.5. Abbreviations ............................................................................................................... 7
2 Data and Software.......................................................................................................... 8
2.1 Data delivery ............................................................................................................ 8
2.2 Data coding .............................................................................................................. 8
2.3 Data compression .......................................................................................................... 8
2.3 Flash-Container-Definition........................................................................................... 8
3 Programming ..................................................................................................................... 9
3.1 Pre-conditions ............................................................................................................... 9
3.2 Conditions within the BLF ................................................................................................ 9
3.3 KWP-services............................................................................................................... 10
3.3.1 ECU-Ident ............................................................................................................. 10
3.3.2 Status Flash .......................................................................................................... 11
3.3.3 General negative responses ..................................................................................... 12
No Program ...................................................................................................................... 12
3.3.3.1 Negative responses within the FP........................................................................... 12
3.4 Time requirements ....................................................................................................... 13
3.4.1 KWP-Parameter ..................................................................................................... 13
3.5 Termination of the programming .................................................................................... 13
3.6 Reconnection............................................................................................................... 14
3.6.1 Control unit ........................................................................................................... 14
3.6.2 Programming device ............................................................................................... 15
4 Access safety ................................................................................................................... 16
4.1 Rules.......................................................................................................................... 16
4.2 Mini-instruction set....................................................................................................... 16
4.3. Arithmetic instruction .................................................................................................. 16
4.4 Flow commands ........................................................................................................... 17
4.5 Coding the set of instructions......................................................................................... 18
4.6 Example ..................................................................................................................... 18
A. Services .......................................................................................................................... 20
A.1 ReadECUIdentification .................................................................................................. 20
A.3 Security Access............................................................................................................ 21
A.3.1 RequestedSeed...................................................................................................... 21
A.3.2 SendKey ............................................................................................................... 21
A.4 RequestDownload .................................................................................................... 22
A.4.1 TransferResponseparameter .................................................................................... 22
A.4.2 DataFormatIdentifier .............................................................................................. 23
A. 5 StartRoutineByLocalIdentifier EraseFlash ........................................................................ 24
A.6 RequestRoutineResultsByLocalIdentifier EraseFlash........................................................... 25
A.7 TrasferData................................................................................................................. 25
A.8 RequestTransferExit ..................................................................................................... 26
A. 9 StartRoutineByLocalIdentifier CalculateFlashChecksum.................................................. 26
Data .................................................................................................................................... 26
Parameter name.................................................................................................................. 26
Value................................................................................................................................... 26
Positive Response ............................................................................................................... 26
Negative Response ......................................................................................................... 26
A.10 RequestRoutineResultsByLocalIdentifier CalculateFlashChecksum ...................................... 27
A.11 StopCommunication.................................................................................................... 27
B. FlashSequence ................................................................................................................ 28
B1. Positive Flash process at ECU with application .................................................................. 28
B2. Entrance Flash process at ECU within the boot loader ........................................................ 31
C. Problems for programming device .................................................................................. 32

2
 C1. With regard to Chapter 3.4.1.1 ...................................................................................... 32
C2. With regard to Chapter 3.4.1.2 ...................................................................................... 32
C.3 with regard to Chapter 3.6.1 ......................................................................................... 32
C.4 Appendix A ................................................................................................................. 32
C.5 StopDiagnosticSession .................................................................................................. 32
C.6 with regard to Chapter A.2 ............................................................................................ 32
C.7 with regard to Chapters A.6 and A.10 ............................................................................. 32
D. Broadcast commands ...................................................................................................... 33
D.1 Mute .......................................................................................................................... 33
D.1.1 Preconditions ........................................................................................................ 33
D.1.2 Operation ............................................................................................................. 33
D.2 Delete central FSP ....................................................................................................... 33
E. SCA Insertion .................................................................................................................. 34
E.1 WriteDataByLocalIdentifier SCA...................................................................................... 34
E.2 Sequence Chart with initializing of the SCA ...................................................................... 35
F. Programming of multiple-processor control units ........................................................... 36
F.1 Multiple processor systems with single diagnostic addresses ............................................... 36
F.2 Multiple processor system with multiple diagnostic addressing ............................................ 36
F.3 Combinations............................................................................................................... 36

3
1 General Information
The raising complexity and the increasing cross linking of functions in our devices make it necessary to
exchange the Software in the control units for a short time in the future. For a short time means here,
in the context of the stipulated operations of the product manufacturing, but without a long dispatch of
the control units to the suppliers. The possibility of reprogramming the software is achieved on the
currently existing diagnosis interfaces. The requirement specification describes the total operation for
the update programming. The requested infrastructure for the data management and version
management, which are eventually in each individual device, are not the object of this specification.

1.1 General requirements

• The information about the maximum deletion times and writing times, as well as the data
volumes provided, are to be indicated by the manufacturer at each release. A current PG has to
serve here as testing aid. The basic conditions are to be specified by the system supplier.
• The block diagram for the memory architecture of the control unit is requested.
• Communication ability with the KWP2000 services through TP2.0 on the device internal bus
systems, corresponding to the effective bus systems for the device.
• The general requirements of the control units have to be accomplished (requirement
specification and VW 80101).
• An ECU, which is ordered by the AUDI/VW for reprogramming, is to be dispatched with
functional, approved driving software.
• After a termination of the programming procedure (e.g. interruption of the diagnosis
communication or the system crash of the control unit/programming device), the control unit
has to be immediately able to be again programmed. For this, an appropriate mechanism, e.g.
the implementation of a watchdog is to be foreseen. A boot sector able to communicate is to be
always made available. In addition, the hardware item number and the approved software item
number have to be stored undetachably in the control unit (EEPROM). The ECUs with a discrete
PinKl.15 require a PinKl.15-Reset.
• A starting operation of the control units with not authentic software is to be really prevented.
• Approved software is to function on every hardware which is approved, i.e. compatible, thus it
will be guaranteed, that the software-updates are independent of the software existing in the
ECU. The characteristics of the ECUs protected through manipulation are to be separately taken
into account.
• The Hardware-known value has to be clear.
• Requested pins within a plug module are to be foreseen for programming at control units with a
modular plug. PinsKl.30 (respectively the requested supply voltage), PinKl.31, PinKl.15 (if
available), as well as CAN-High/-Low, respectively other communication lines (e.g. MOST), are
to be allocated to standard positions.
• The control units have to be able to be programmed both in the device, as well as individually.
• The communication ability and the programmability have to be tested by the development for
each program and data status. Similarly, the programming preconditions are to be clearly
defined.
• There are no restrictions regarding the programming sequence of the control units within the
device. At functional connections of the ECUs (e.g. Master-Slave), the sequence between the
ECU-responsible and the supplier is to be established.
• At some control units, the legal requirements are to be taken into account (e.g. in the USA
“pass-thru”).
• The parallel programming of several control units in an entitled condition is possible. The
exceptions at the ECUs with functional connections (e.g. Master-Slave) are to be clearly
marked.
• The same rules regarding the version management as for a control unit exchange (e.g.
generating a new item number or release process) serve for an update programming.

4
 • The behavior regarding the coding of a control unit is not generally established. The responsible
for the system has to take care of the functional efficiency, and has to describe the behavior
regarding the different coding at flashing in the diagnostic-LH.
• The system coordinator must, in accordance with the quality assurance and purchase, negotiate
and document guarantee conditions.

1.2 Further applicable documents

The present version serves for all documents. The existing versions are to be included in the control
unit requirement specification.
/1/ Corporate group-description-control table for update-programming
/2/ Workshop-identifying
/3/ Minimal container for control units that can be coded/programmed
/4/ VW 801 15 – control units-identifying with KWP2000 services
/5/ VW 801 01 – electric and electronic assembly groups in motor vehicles
/6/ Corporate group requirement specification CAN-transport protocol 2.0
/7/ KWP2000 on TP2.0 (full duplex)
/8/ Corporate group requirement specification KWP2000 light plus
/9/ VAG-Code-List
/10/ VW 801 14 – standard on-board diagnosis system of electronic device systems

1.3 Changing history

12.06.00 Original version, derived from Flash 2.1 from EEOA

27.06.00 2.3 and 2.4 make reference to the control table description and flash-container
29.06.00 3 system transfer to high Baud rate inserted
28.05.01 First version for TP2.0
11.10.01 Revised regarding the descent in the boot sector and negative answers
30.01.02 General revision of all chapters
11.02.02 summary of the flow diagrams

Date Version Change

18.04.02 1.0 Revision for version 1.0; the change of the original document is taken
over;
(Internal) Concept “DataLinkLayer” for negative responses 0x21, and 0x78 replaced
with “DefaultResponses”
Chapter Abbreviations included (1.4):
Expansion for writing of the Flash-Data (3.52);
Expansion of the service “Delete Flash” for closing the TP-channel (3.4.2,
4.4);
Tables of figures inserted;
Extension of the positive operation for closing the TP-channel after a
complete execution of the programming operation (3.4.2.)
06.05.02 1.01 Inserting the service “StopCommunication” in the operation table (3.4.2)
(Internal)
07.05.02 1.02 inserting the “Negative Response Pending” in the ECU at the end of the
flash- operation (3.4.2)
(Internal) Indication at “delete flash” inserted in a positive operation (3.4.2).
28.05.02 1.03 Process flow of the reconnection at control units without PinKl 15 inserted
(3.5.2)
29.07.02 1.04 Revision: all revisions are marked; this version is intended only for
(Internal) internal allocation to the editors-team.
Version 1.03 is a condition enabled for implementation.
01.08.02 1.05 revision of all chapters
(Internal)
09.10.02 1.06 editor version for
5
 (Internal)
07.11.02 1.011 revision chapter 2:
(Internal) - omission of redundant definitions, reference to further applicable
documents
revision of chapter 3;
- Restructuring
- Omission of the SecurityAccess within the flow program, only within
the Bootloader Flasher
- Exchange the table “Positive flash flow” with sequence chart with
explanations (Appendix B)
- Detailed description of the operation flows
Revision Chapter 4:
- Description of the services within the Appendix A
- Completion “SecurityAccess” and “StopCommunication”
- Revision of the negative responses
Completion Appendix C:
- Description of the ECUs, serves for all PGs
Completion Appendix D:
- Description of the integration of the Broadcast-service “Mute”
introduced
Completion Appendix E:
- Description of the procedures at the multi-processor systems
14.01.03 1.1 Revision in (Appendix A) RoutineResults of the
services RequestRoutineResult EraseFlash and CalculateFlashChecksum

1.4 Version administration

Version <H.NV>

<H> Main version main textual changes

<N> Secondary version compatible textual changes/ bugfix
<V> Preliminary version design for a new main / secondary version

Only versions with <H.N> are given for implementation. Preliminary versions serve only as
information, respectively for discussion.

6
1.5 Abbreviations

Abbreviation Meaning
ASCII American Standard Code for Information Interchange
BLF BootLoaderFlasher
Bzgl. Regarding
C Conditional
CAN Controller Area Network
CD Conditional Default Responses
FDC Flash Data Container
FP Driving Program
FSP Error memory
FTC Flash Tool Code
IKA Individual Components Authentifying
Kl.15 Pin 15 (ignition pin)
Kl.30 Pin 30 (continuous voltage supply)
KWP Keyword Protocol
LH RequirementsSpecification
LSB Least Significant Bit / Byte
NM NetworkManagement
NRC NegativeResponseCode
PG Programming device (Tester)
SCA Software Container Autentifying
ECU Control Unit
SVM Software Versions Management
SW Software
TE Technical Development
TP Transport Protocol
U User optional
WFS Immobilizer System
WSC Work Shop Code
z.B for example

7
2 Data and Software
2.1 Data delivery

The supplier has to transfer the data to the stipulated data container-formats.
The data is transferred to the production in an SGML-format according to /3/. The processes quality
assurance and production start are taken into account. At the same time, the data is transferred to the
spare part nature.
The customer service has access to all necessary data container. A control table according /1/ enables
the customer-service-tester, in connection with the item number and software index, respectively
number version, to find a possible updated data record. A re-programming to aged software is not
allowed. Additionally, the TE delivers the compatibility information for the control table regarding the
control unit concerned.

2.2 Data coding

In order to avoid damages to the control unit, certain safety measures for the serial control units are
necessary. Since they can be hindering in the test operation, there may be an exception here. Attempt
data records are never allowed to abandon the development departments.

Data records, which are meant for control, must be available in the container in a coded form. The
procedure is to be secretly maintained, and must be made known only to the circle of the directly
concerned persons.
The data container for the customer service is converted to an illegible format (SGO-format). The
system coordinator may obtain the conversion program.

2.3 Data compression

An additional necessary compression of a data record is to be adjusted between the supplier and the
control unit developer. The ECU-developer decides in accordance with the production and customer
service, starting with which programming time, respectively with which data size this is necessary.

2.4 Flash-Container-Definition

The requested information is established in chapter /3/.

Observation: The following Tags have no relevance and do not have to be updated for the new
control units, which are developed according to this LH.
<KWP-2000>

…
<BAUDRATEN-2000><BAUDRATEN-2000>
KWP-2000-TGT></KWP-2000-TGT>
The following Tag has no significance, but must be updated (possible values are 0xFF):
<KWP-2000-ACP>
<KWP-2000-P2MIN>0xFF</KWP-2000-P2MIN>
…
< KWP-2000-ACP>
</KWP-2000>

8
3 Programming
The details for the programming operation are described in this chapter. The total operation of the
flash programming is described in the Appendix B.
If the ECU is built with more than one processor, then Appendix F is to be taken into account.
If it goes about a functional dependent system (e.g. Master-Slave), then the possible specific features
within the flash operation (e.g. sequence of the programming, parallel programming and so on)
between the ECU-responsible and the suppliers are to be established.

3.1 Pre-conditions

The following pre-conditions must be fulfilled by, respectively within an ECU, so that the programming
may follow:
• The programming pre-conditions must be read out according to chapters /4/ and /9/. If the
pre-conditions do not correspond, then the request 0x1085 “StartDiagnosticSession Flash” is to
be answered by the ECU with the NRC 0x22 ”conditionsNotCorrect”
• If the ECU is a component of a WFS-mechanism, then the authentication has taken place in the
WFS. The exceptions in this case are the development-control units (not series).
• The PG has to make available the complete data according to chapter /3/.

3.2 Conditions within the BLF

In general, the following conditions are given during the programming session:
• The programming mode may be quitted only with a Power up, respectively PinKl. 15-Reset (at
ECU with PinKl.15) or with an implicit ECU-Reset (at ECU without PinKl.15).
• The control units Kl.15 must, if they are found within the BLF, reset themselves (software
reset), if they have recognized an internal timeout (no communication visible any more on a
TP-level).
• The cyclic data transfer that takes place in the FP and is consulted there for the error
management of the ECU is switched off during the ECU.
• No NM is supported within the BLF.
• There are no FSP-routines available in the BLF. The error memory is not updated during the
session. The error status bits in 0x1A9C (Chapter 3.3.2) serve as a rudimentary FSP. These
must be served by the BFL during the programming process.
• So that the band width of the present bus system can be completely used for the data transfer
at flash, the control units within the network in the FP must support the Broadcast-service
“Mute” according to chapter /6/. A PG must transmit the “Mute” command after the Appendix D
of this LH, during a complete flash session.
• The ECU must, during the first flow of the flash sequence (after the service 0x31C4
“StartRoutineByLocalIdentifierEraseFlash” has been positively answered), update the following
EEPROM-data (0x1A9C) (the sequence is to be followed):
1. Set the inconsistency bit on “1”
2. Increase the counter for the programming attempts
3. Delete the flash-date, i.e. write ‘-‘(ASCII:0x2D) instead of the data; Format “dd.mm.yy”
4. Examine and insert the FTC in the EEPROM
• If the flash sequence runs more than once in the same session, then the values may not be
described by 0x1A9C (Status Flash).
• The memory areas for the WSC and the FTC are different. If, after a positive answer to the
service 0x31C4 “StartRoutineByLocalIdentifier EraseFlash”, the valid FTC (FTC ≠0) is described
in the corresponding cells, then the WSC must also be described with the same value. If the
transferred FTC = 0, then the ECU transmits the negative response 0x22
“conditionsNotCorrect”. The description of the storage cells is to follow only the first time in the
case of programming several blocks.

9
3.3 KWP-services
The following services are requested in the case of the control units that can be programmed. It is
identified in which status the particular service is requested.

Service Value Sub-function Value Meaning BLF FP

ReadECUIdentification 0x1A IdentificationOption 0x91 Hardware-item + +
number
0x9B Item number / +1 +
ECU -Ident
0x9C Flash status + +
0x86 Extended ECU- +2 +
Ident
StartDiagnosticSession 0x10 Session 0x85 Flash + +
StopCommunication 0x82 - - + +
SecurityAccess 0x27 Access mode 0x01 Seed + -
0x02 Key + -
RequestDownload 0x34 - - + 0
TransferData 0x36 - - + 0
RequestTransferExit 0x37 - - + 0
StartRoutineByLocalIdentifier 0x31 LocalIdentifier 0xC4 Delete Flash + -
0xC5 Calculate + 0
Checksum
RequestRoutineResultsByLocalID 0x33 LocalIdentifier 0xC4 Delete Flash + -
0xC5 Calculate + 0
Checksum
Table 1: Necessary diagnostic services for the Flash Session
Legend: + must be supported → respond positively when accomplishing all
pre- conditions
0 may be supported, is not requested by this LH
- is not allowed to be supported → respond always negatively (Chapter 0)

3.3.1 ECU-Ident

The service 0x1A9B “ReadECUIdentification ECU-Ident” may be displayed reduced, as long as the
version management allows this (Indication: SW-version number in the ECU-description):
ECU-IDP 9B Content Format
1 VW / Audi-Part number 7 Bit-ASCII
...
11
12 Space (0x20) 7 Bit-ASCII
Configuration Program status 7 Bit-ASCII +MSB
13
and programmability3 7 Bit-ASCII
14
15 Data status 7 Bit-ASCII
16

Table 2: Modified extract from chapter /4/ - ECU-Identification 0x9B

1
May be shortened on the part number and program-/ data status (see chapter 3.3.1)
2
only at ECU with SCA-insertion after Appendix E
3
The programmability bit is the MSB in Byte 13 and has inverse logic
Bit = ‘1’ ⇒ ECU can not flash
Bit = ‘0’ ⇒ ECU can flash

10
 3.3.2 Status Flash

The service 0x1A9C “ReadECUIdentification Status Flash” is partly updated within the BLF and/ or
FP. The sequence of the update is currently described in chapter 3.2 for the BFL and in chapter 3.6.1
for the FP and is to be absolutely complied with.

ECU-IDP 9C Content Observation Format

1 Bit # 7 inconsistency bit - is placed within the BFL at the first flow HEX
on ‘1’, when it is started with the deletion
of the Flash-EEPROM
- it is restored within the FP, when the
new internal documentation is completely
new written
Bit # 6 – Not used
Bit # 5 – Not used
Bit # 4 – Not used
Bit # 3 EEPROM error - recognize the internal monitoring
mechanisms of a general error of the
Bit # 24 Flash defect memory
Is placed – recognizes the internal
Bit # 14 communication monitoring
error mechanisms of a general
error of
Bit # 0Flash can not be the memory5
programmed within - a communication error leads to
the
termination of the flash
sequence
- Recognizes the internal
mechanisms
of an error at the check sum6
the BLF
when
2 Counter for programming Is placed within the BFL, when it is started Hex
attempts with the deletion of the flash-EEPROM
3 Counter for successful Is placed within the FP, when the new Hex
programming internal documentation is successfully
written
4 Status of the The preconditions must be monitored Hex
programming-pre- within the FP, and are updated according
conditions the present definition.
The preconditions are deactivated within
the BLF.
5 FTC Is described at the first run within the Hex
… BFL, when it begins with the deletion of
10 the Flash-EEPROM. It also overwrites the
WSC.
11 Flash-Date - is it reset within the BFL, when it is ASCII
… started with the deletion of the Flash-
18 EEPROM.
- is written in the FP, when the message
“mDiagnose_1” is received after the flash.

Table 3: Extract from chapter /4/ - Status Flash 0x9C with explanations for updating

4
May be reset after a successful reconnection
5
it leads in such a way, so that the service0x33C4“RequestRoutineResultsByLocalIdentifierEraseFlash” is negatively answered.
6
it leads in such a way, so that the service 0x33C5 “RequestRoutineResultsByLocalIdentifier CalculateFlashChecksumme” is
negatively answered.

11
 3.3.3 General negative responses

The negative responses, which are applied for all services, are presented here. The
NegativeDefaultResponses CD (see Appendix A) are not explicitly presented, since they must be
served independently from FP or BLF according to chapter /8/. If negative additional responses are
necessary, then they must be agreed upon by the system responsible.

Supported In Active

Access Requested
Correct/Request
Diagnostic Mode

Denied/security
Security Access
Sequence Error
Conditions Not
Service Not
No Program
Negative Response Code 0x90 0x80 0x22 0x33
ECU within the BLF + - 0 +
ECU within the FP - + 0 -
Request unknown, respectively supported + + - -
Program preconditions not accomplished 0 0 + -
Authentication is not given 0 0 0 +
Error in the flash run 0 0 + 0

Table 4: Rules for possible negative responses

Legend: + Requested
0 don’t care
- Forbidden

3.3.3.1 Negative responses within the FP

All services, which can be carried out only in the BLF (see Table 1), are responded with the NRC 0x80
“service-NotSupportedInActiveDiagnosticMode” within the FP.

3.3.3.2 Negative responses within the BLF

All services that are not presented in Table 1 are rejected with the NRC 0x90 “noProgramm” within the
BLF. This negative response facilitates the recognition of the control units for development and
production, and may be currently found within the BFL and do not support certain services.
All services that are not presented in Table 1 are rejected with the NRC 0x90 “noProgramm” within the
BLF.
The NRC 0x11 “serviceNotSupported’ is not allowed for these services within the BLF.
The negative Default Responses must be correctly handled on each position within the flash sequence.
If the access authorization through the “SecurityAccess” is not given, then all the requested services
except from 0x1A “ReadECUIdentification”, 0x1085 “StartDiagnosticSession” and 0x82
“SopCommunication” are answered with the NRC 0x33 “securityAccessRequested”.

12
3.4 Time requirements

The following time requirements are set for control units and programming devices.

3.4.1 KWP-Parameter

3.4.1.1 F_Boot
With the help of F_Boot, the ECU must transmit to the PG a factor for calculating the waiting time
T_Boot, which the ECU requires, in order to enter the BLF mode. The PG must wait the T_Boot time,
until the ECU can communicate again after entering the BLF mode. The parameter is transferred to
the positive response on 0x1085 “StartDiagnosticSessionFlash” (see Appendix A.2).

Value range of F_Boot: 0x00≤XX≤0xFF

Special case: The ECU requires no waiting time and can immediately further
communicate;
The channel is not closed. If a control unit is found within the BLF, then
the 0x00 is to be transferred.
Formula for calculation: T_Boot = F_Boot ⋅ 100ms

3.4.1.2 F_Routine
F_Routine is a factor for calculating the waiting time T_Routine. The PG uses this waiting time only for
the following service 0x33C4 “RequestRoutineResultEraseFlash”. After the response from the ECU to
this service, the PG uses again the pre-set value for P2 (/7/). The parameter is transferred in the
positive response on 0x31C4 “StartRoutineByLocalIdentifierEraseFlash” (see Appendix A.5).

Value range of F_Routine: 0x00≤XX≤0x3C (maximum 10 minutes)

Special case: The ECU requires no waiting time and can immediately further
communicate;
the channel is not closed.
Formula for calculation: T_Routine = F_Routine ⋅ 10 ms
The Connection Test is to be basically correctly handled (see Chapter /6/).
The following timing parameters are always to be used within the BLF. The ECU has to take care, so
that the complex data is to be quickly processed.

Parameter PG / ECU
CAN-Bus7 High speed Low speed
Block size (BS) 15 15
Acknowledgement-timeout (T1) 8 100 ms 100 ms
Minimum reception distance (T3)
9 ≤ 1 ms 1,5 ms10

Table 5: Connection parameter for the transport protocol

3.5 Termination of the programming

The PG through the service 0x82 “StopCommunication” makes the programming termination known to
the ECU. The PG is never allowed to send this service, when there is still data to be flashed.

7
The physical facts are to be taken into account when inserting other bus systems.
8
The coding of the bytes is to be taken from Chapter /6/.
9
T2 and T4 are not to be used (=set 0xFF).
10
Conditioned through lower Baudrate on Lowspeedbus.

13
3.6 Reconnection

3.6.1 Control unit

The actual programming session is quitted with the service 0x82 “StopCommuncation” and the
consequent channel structure. If the programming was successful, the ECU may carry out the transfer
in the newly programmed FP. The following is to be taken into account:
• The ECU without a discrete PinKl.15 performs an implicit software reset.
• The ECU with a discrete PinKl.15 performs a software reset, independent of “PinKl.15 on”. The
control unit developer has to make sure that he does not generate any inconsistency through
overshoot phases
• After the SW-Reset (ECU without PinKl.15) or “PinKl.15 on” (ECU with PinKl.15), the ECU has to
perform a new initializing. Thus, the following EEPROM-data is to be updated (the sequence is
to be maintained):
1. New software status and possible new part number,
2. Incrementing the counter for successful programming,
3. Reset inconsistency bit (‘0’).
4. Write flash date.11
• If an ECU finds itself in the start-up or shooting phase (e.g. motor control unit), then it must
completely perform the initializing sequences (e.g. update the EEPROM, check RAM, check
Flash-Consistency). Only then, the inconsistency bit is reset.
• If an ECU can already communicate on CAN, then all diagnostic requirements are to be rejected
(Negative Response CD), as long as the new internal documentation, except for the flash date,
was not updated. The ReadECUIdentification services were meant by the internal
documentation. Thus, it is guaranteed, that the next requested documentation of the ECU is in
accordance with the actual condition.
• The error memory is to be again activated when the complete initializing phase has been
ended.
• The flash-date is presented within the control unit identification 0x1A9C (Status Flash). It
should be described as soon as possible. If an ECU is programmed within an integrated status
(within de device), then the time stamp should be inferred as a flash date from the
“Diagnose_1” message from gateway. Thus, the first recognized date is to be memorized in the
normal communication (after the initializing) after the flash. This date is regarded as start-up
date with the new software. If no current date is introduced in the message, then the ECU
mustn’t write any data, since these were already deleted in the flash-sequence. The same
applies for the control units, which cannot dispose of a receive-object for the “Diagnose_1”
message. The content of the “Diagnose_1” message is to be taken from the current valid
communication matrix. Because the date is formatted as ASCII-characters within the control
unit identification 0x1A9C, the invalid values are to be converted if necessary within the
“Diagnose_1” message (e.g. from date 0x00 → ‘-‘). The date format is described in Chapter /4/.
In case the programming is not successful, then the ECU still remains within the BLF, and must be
reprogrammed (Chapter 1.1).

11
Only when the date is available.

14
 3.6.2 Programming device
The following procedure applies for a PG, after the flash session has been ended:

• Immediately after dismantling the TP-channel, the PG arranges for PinKl.15 to switch off.
• The PG arranges for PinKl.15 to reset
• The PG initiates the diagnostic communication and retrieves the new internal documentation to
the mentioned sequence:
1. ECU-identification (0x1A9B)
2. HW-part number (0x1A91)
3. Status Flash (0x1A9C)
4. EECU-Identification (0x1A86).
After the inquiry for the new internal documentation, the PG has the opportunity of the consistency
examination of the data (old/new description). If the programming procedure went wrong, then the
ECU is generally not capable to run. The PG can establish this, in case of a correct implementation by
means of the inconsistency bit (‘1’).

15
4 Access safety
The Seed-and-Key-Algorithm serves for the access safety to the control unit through the diagnostic
interface. It should guarantee, that only a valid device has access to certain functions within the
control units through the diagnostic communication.
In order to prevent the unjustified programming of the control units, the control unit transmits an
unexpected Seed. The programming device estimates a Key, which it transmits back to the control
unit. The release follows only when the received Key and the estimation result are the same within the
control unit.

4.1 Rules
A control unit may quit the control unit manufacturer only with an edged Seed-and-Key-algorithm. The
supplier is supposed to program the control units within its work with another method, however he
must guarantee that the devices are irreversibly adjusted in the area to this access safety.
It is left to the system developer to implement a dead time, in which the ECU, after an unsuccessful
attempt of a SecurityAccess, to react to a renewed one with an NRC0x37
“requiredTimeDelayNotExpired”.

4.2 Mini-instruction set

The regulation for converting the Seed and Key is established by the control unit developer.
It is requested to communicate the calculation rule of the programming device and of other
programming devices. This appears within the encrypted data container, as a readable and achievable
instruction from the programming devices. The necessary mini-instruction set limits to few main
operations of the processor.

4.3. Arithmetic instruction

The following applies in general for the performed algorithms:
• Seed and Key are each made up of 32 Bit.
• All are binary accomplished calculations.
• The operand is in each case the result of the previous calculation.
• When starting the operand is loaded with Seed, in the end the Operand contains the Key.
• The values with the instruction to the single operations must be handed over.
• When the operation exceeds 32, then Bit Overflow- or Carry-Bit is set.

A. Rotate to the left [RSL]

Without shifting it over Carry

Carry is set on 1

B. Rotate to the right [RSR]

Without shifting it over Carry

Carry is set on 1

16
C. Ad the value [ADD “Value”]
Operand

+
Value

Overflow Operand

D. Subtract the value [SUB ”Value”]

Operand

-
Value

Overflow Operand

The overflow is set, when the value is larger than the operand.

E. Logical EXKLUSIV ODER with value [EOR “Value”]

Operand
XOR

Value

Overflow = Operand

The operand and value are connected bit by bit through logic EXKLUSIV ODER and stored as new
Operand. The overflow is always reset.

Operand Value Operand

0 0 „ 0
0 1 „ 1
1 0 „ 1
1 1 „ 0
Table 6: calculation table for Exklusiv Oder

4.4 Flow commands

Besides the arithmetic instructions, commands are also necessary for the flow of the calculation.

A. For I = “Value” up to 1, it indicates how often a command or a sequence of commands should

follow.
“Value” = number of flows
Special case: I=0 this case is not foreseen and is not allowed to occur. If this case
occurs through an error or through a miscalculation, then the BLF has to
take care so that the ECU should not become defective (total crash).
Next
The loop closes. It must run as often as the number of operations set.

B. Jump, when the overflow is zero [BCC ”Value”]

17
 When it leads to a branching during the flow, which is determined through a calculation in
process. The “Value” comprises the number of the storage places (Bytes) to be skipped. In this
case it is assumed that the programming counter is placed on the starting address of the next
command.

C. Always jump [BRA “Value”]

It may be used in order to skip certain operation segments. The “Value” comprises the number
of the storage places (Bytes) to be skipped. In this case it is assumed that the programming
counter is placed on the starting address of the next command.

D. Finish
Indicates that the Operand may be sent as Key.

4.5 Coding the set of instructions

The following table establishes the hex numbers for the commands. It is in such a way
coded, so that the arithmetic instructions should contain an even number of bits, while the
flow commands should contain an uneven number.

Operation Hex-Code Values

[RSL] 0x81 -
[RSR] 0x82 -
[ADD”Value”] 0x93 0xww,0xww,0xww,0xww
[SUB”Value”] 0x84 0xww,0xww,0xww,0xww
[EOR”Value”] 0x87 0xww, 0xww,0xww,0xww
For I = “value”of up to 1 0x68 0xww
Next 0x49 -
[BCC”Value”] 0x4A 0xww
[BRA”Value”] 0x6B 0xww
Finish 0x4C -

Table 7: Assignment table for operations and Hex-Codes

4.6 Example
A possible operation should be presented as an example.
Script: 0x68, 0x05, 0x81, 0x4A, 0x05, 0x87, 0x0A, 0x22, 0x12, 0x89, 0x49, 0x4C

Marker Opcode Data (“Value”) Operation point

Start The Operand is taken
over as Seed; the
overflow is set on 0
0x68 0x05 For I =5 to 1 (5 cycles)
0x81 - Rotate to the left
0x4A 0x05 Jump, when the
overflow is 0 after
Marke 1
0x87 0x0A221289 EXCLUSIV ODER with
0x0A221289
Marke 1 0x49 - Next
0x4C - Finish
The Key is transmitted
as Operand

Table 8: Operation example for the calculation at SecurityAccess

18
19
A. Services

The services carried out below, are valid only with the corresponding responses only for the ECU
developed according to this LH.
Legend:
M Byte is to be made available with the indicated value.
U It is not necessary to update the Byte.
CD Place holder for Negative DefaultResponses – {busyRepeatRequest”, 0x23
“routineNotComplete”, 0x78 “requestCorrectlyReceived ResponsePending”}; these are to implemented
according to Chapter /8/.
C0 place holder for the general valid negative responses; defined in Chapter 3.3.3
Cn n-1,2,3,…; optional negative responses; are described in detail in the current services.
XX Place holder for values.

A.1 ReadECUIdentification
These services are to be completely transferred according to Chapter /4/. See the exception in Chapter
3.3.1.
Data Parameter name Value
StartDiagnosticSession
#1 M 10
ReqSId
#2 DiagnosticMode M 85

Positive Response Negative Response

#1 StartDiagnosticSessionPRSId M 50 Negative response SId M 7F
StartDiagnosticSession M 10
#2 DiagnosticModeProgramming M 85
ReqSId
#3 F_Boot12 M XX default Responses CD XX
[according to table 4] C0 XX

Observation: The negative response 0x33 “securityAccessRequested” (C0) is a problem for the PG;
see Appendix C.

`12
Values for XX and meaning for the operation of the flash sequence see Chapter 3.4.1.1.

20
A.3 Security Access

A.3.1 RequestedSeed

Data Parameter name Value

#1 Security Access ReqSId M 27
#2 AccessMode M 01

Positive Response Negative Response

#1 Security Access PRSId M 67 Negative response SId M 7F
#2 AccessMode M 01 Security Access ReqSId M 27
#3 Seed 1 {MSB} M XX default Responses CD XX
[according to Table 4] C0 XX
exceed Number Of Attempts C1 36
required Time Delay Not Expired C2 37

#4 Seed 2 M XX
#5 Seed 3 M XX
#6 Seed 4 {LSB} M XX

C1 the number of unsuccessful attempts exceeded

C2 the off period after the unsuccessful attempt has not elapsed
Observation: the application of the inhibition measures examined in C1 and C2, are established in
agreement with the system coordinator.

A.3.2 SendKey

Data Parameter name Value

#1 Security Access ReqSId M 27
#2 AccessMode M 02
#3 Key 1 {MSB} M XX
#4 Key 2 M XX
#5 Key 3 M XX
#6 Key 4 {LSB} M XX

Positive Response Negative Response

#1 Security Access PRSId M 67 Negative response SId M 7F

#2 AccessMode M 02 Security Access ReqSId M 27

#3 Security Access Status M 34 default Responses CD XX
[according to Table 4] C0 XX
invalid Key C1 35

C1 the received access code is false

21
A.4 RequestDownload

Data Parameter name Value

#1 Security Download ReqSId M 34
#2 Memory Address {MSB} M XX
#3 Memory Address M XX
#4 Memory Address {LSB} M XX
#5 Data Format Identifier M XX
UnCompressed Memory Size
#6 M XX
{MSB}
#7 UnCompressed Memory Size M XX
#8 UnCompressed Memory Size {LSB} M XX

Positive Response Negative Response

#1 Request Download PRSId M 74 Negative response SId M 7F
Transfer Response Parameter Request Download M 34
#2 M XX
{MSB} ReqSId
#3 Transfer Response Parameter U XX default Responses CD XX
{LSB} [according to Table 4] C0 XX
canNotDownloadToSpec C1 42
ifie Adress
improperDownloadType C2 41
canNotDownloadNumbe C3 43
rOfBytesRequested

C1 MemoryAddress in #2…#4 is not supported.

C2 DataFormatIdentifier in #5 is not supported.
C3 UnCompressedMemorySize in #6…#8 exceeds the memory area.

A.4.1 TransferResponseparameter

For the ECU that can be received with more than 255 Byte per piece, the parameter is to be extended
to an additional length byte (Byte #3).

The control units, which can receive maximum 255 Bytes, must assign the length to Byte#2. The
additional length byte must not be transmitted.

The number transmitted is a maximum value, which cannot be exceeded by the PG. Thus, the PG is
compelled to clearly set this value.

The PG must evaluate, according to the response length, which format the ECU has transmitted.
Maximum 4095 Byte can be downloaded to a KWP-frame with an additional Byte (/7/).

22
 A.4.2 DataFormatIdentifier

The parameter “DataFormatIdentifier” is divided into two nibbles. The high nibble indicates the
compression method, and the low one indicates the encryption method.
The format is to be agreed upon by the control units’ responsible.

Hex
high low
nibble nibble

0 X (unCompressed (not compressed)

1...7 X This value range describes the compression method; is set by the supplier
8…F X Reserved for the requirement specification
X 0 Unencrypted (not encrypted)
X 1…7 This value range describes the encryption method; is set by the supplier
X 8…F Reserved for the requirement specification

Table 9: Contents of Byte “DataFormatIdentifier”

23
A. 5 StartRoutineByLocalIdentifier EraseFlash

Data Parameter name Value

Start Routine By Local Identifier
#1 M 31
ReqSId
#2 Routine Local Identifier M C4
#3 Start Address {MSB} M XX
#4 Start Address M XX
#5 Start Address {LSB} M XX
#6 End Address {MSB} M XX
#7 End Address M XX
#8 End Address {LSB} M XX
#9 FTC Byte 1 M XX
#10 FTC Byte 2 M XX
#11 FTC Byte 3 M XX
#12 FTC Byte 4 M XX
#13 FTC Byte 5 M XX
#14 FTC Byte 6 M XX

Positive Response Negative Response

Start Routine By Local Identifier M 7F
#1 M 71 Negative response SId
PRSId
Start Routine By Local M 31
#2 Routine Local Identifier M C4
Identifier ReqSId
#3 F_Routine13 M XX default Responses CD XX
[according to Table 4] C0 XX
CanNotDownloadToSpe C1 42
cifie Adress
improperDownloadTyp C2 41
e
CanNotDownloadNumb C3 43
erOfBytesRequested

C1 StartAddress in #3…#5 is not supported

C2 EndAddress in #6…#8 exceeds the memory area

13
Values for XX and meanings for the flow of the flash sequence see Chapter 3.4.1.2

24
A.6 RequestRoutineResultsByLocalIdentifier EraseFlash

Data Parameter name Value

Request Routine Results
#1 By Local Identifier M 33
ReqSid
#2 Routine Local Identifier M C4

Positive Response Negative Response

Request Routine Results
#1 By Local Identifier M 73 Negative response SId M 7F
PRSId
Request Routine Results By Local
#2 Routine Local Identifier M C4 M 33
Identifier ReqSId
#3 Correct Routine Results C1 00 default Responses CD XX
Incorrect Routine C2 FE [according to Table 4] C0 XX
Results
C1 the given memory area in 0x31C4 “StartRoutineByLocalIdentifier” could be deleted.
C2 the given memory area in 0x31C4 “StartRoutineByLocalIdentifier” could not be definitely
deleted.

A.7 TrasferData
The programming data is transmitted in blocks of maximum 4095 Byte. This boundary results from the
appointed parameters of the service “RequestDownload” (Chapter A.4.1) and from the maximum
possible length information about KWP2000 (/7/).
Values for N: N≤ TransferResponseParameter

Data Parameter name Value

#1 Transfer Data ReqSId M 36
#2 Program Byte #1 M XX
Program Byte #2 M XX
Program Byte #3 M XX
… M XX
#N-1 Progr.Byte #N-1 M XX
#N Progr. Byte #N M XX

Positive Response Negative Response

#1 Transfer Data PRSId M 76 Negative Response SId M 7F

#2 Transfer Data ReqSId M 36

#3 default Responses CD XX
[according to Table 4] C0 XX
illegal Address In Block C1 74
Transfer
illegal Byte Count In Block C2 75
Transfer
C1 the amount of the transmitted bytes does not coincide with those ones that were transmitted in
0x34 “RequestDownload” “UnCompressed MemorySize”

25
C2 The N size of the transmitted blocks exceeds the one allowed in 0x34 “RequestDownload”
“TransferResponseParameter”.

A.8 RequestTransferExit

Data Parameter name Value

#1 Security Access ReqSId M 37

Positive Response Negative Response

Request Transfer Exit M 7F
#1 M 77 Negative Response SId
PRSId
Request Transfer Exit M 37
#2
ReqSId
#3 default Responses CD XX
[according to Table 4] C0 XX
transfer Aborted C1 40
illegal Byte Count In Block C2 75
Transfer

C1 programming data could not be stored.

C2 the amount of the data transmitted does not coincide with the expected amount of the data

A. 9 StartRoutineByLocalIdentifier CalculateFlashChecksum

Data Parameter name Value

Start Routine By Local Identifier
#1 M 31
ReqSId
#2 Routine Local Identifier M C5
#3 Start Address {MSB} M XX
#4 Start Address M XX
#5 Start Address {LSB} M XX
#6 End Address {MSB} M XX
#7 End Address M XX
#8 End Address {LSB} M XX
#9 Checksum Of The Data {MSB} M XX
#10 Checksum Of The Data {LSB} M XX

Negative
Positive Response
Response
Start Routine By Local Identifier M 7F
#1 M 71 Negative response SId
PRSId
Start Routine By Local M 31
#2 Routine Local Identifier M C5
Identifier ReqSId
#3 default Responses CD XX
[according to Table 4] C0 XX

26
A.10 RequestRoutineResultsByLocalIdentifier CalculateFlashChecksum

Data Parameter name Value

Request Routine Results
#1 By Local Identifier M 33
ReqSid
#2 Routine Local Identifier M C5

Positive Response Negative Response

Request Routine Results
#1 By Local Identifier M 73 Negative response SId M 7F
PRSId
Request Routine Results By Local
#2 Routine Local Identifier M C5 M 33
Identifier ReqSId
#3 Correct Routine Results C1 00 default Responses CD XX
Incorrect Routine C2 FE [according to Table 4] C0 XX
Results

C1 the calculated CheckSumme coincides with the previously transmitted one.

C2 the calculated CheckSumme does not coincide with the previously transmitted one.

Observation: In this case, the control unit is not allowed to use the received data, and must be
reprogrammed.

A.11 StopCommunication

Data Parameter name Value

#1 Stop Comunication M 82

Positive Response Negative Response

Stop Comunication M 7F
#1 M C2 Negative Response SId
PRSId
#2 Stop Comunication ReqSId M 82
#3 default Responses CD XX
[according to Table 4] C0 XX

27
B. FlashSequence

The sequence in the following sequence chart is described with positive responses. The reaction of the
programming device and of the control unit with negative responses is different within the individual
services and independent of the negative response.
During the operation, protocols KWP or TP are dealt with in a smooth manner. The correct protocol
handling is to be taken from the current valid requirement specification.

B1. Positive Flash process at ECU with application

If not all conditions are accomplished, then the flash

operation is stopped. The PG may generate an error
message.

The ECU is prepared for the descending the Boot loader. If not
all preconditions are fulfilled, then the ECU responses with
“conditionsNotCorrect”
The following cases are differentiated:
F Boot = 0: When descending the BLF, the ECU may
Starting from here, the PG must send the communicate further on, or it is already found within the BLF
command Mute F Boot > 0: the ECU needs a channel structure for descending
the BLF

The PG starts the waiting time

T_Boot

A channel structure may only follow, if previously, the ECU

removed the channel

The T_Boot time has elapsed; the PG opens a new TP

communication
Quick timing s are adjusted for the new connection
(See chapter
3.4.2) Descend from BLF: The adjustment of the valid
In each case, the timing parameters are re-exchanged parameter follows with the new initializing in the boot
sector (e.g. quick timings)
Access to the BLF: If the ECU is already to be found
within the BLF, then the timing parameter are to be
exchanged

Request Seed
(level 1)
The ECU is not allowed at this point to be disconnected

Transmit the release

Send Key (level 2) (level 2)

Program data parameter notification

Examine the memory area and adjust the decoding

Transfer the possible block length

28
 Delete memory area and FTC transmit

The control unit must, during the first cycle of the flash sequence, update
the following EEPROM-data (1A 9C) (the sequence is important!):
1. Set the inconsistence bit on ‘1’
2. Increase the counter for programming attempts
3. Delete flash-date
4. Examine and insert the FTC in the EEPROM
Confirm after positive examination.

The value of F_Routine applies as a maximum value for the flash deletion
time. An ECU must always be able to reestablish the communication after
the elapse of this time.

The TP_channel is closed for the time P2CAN_Flash (calculation: see LH

Chapter 3.4.1.2)
Exception: if the value of F_Routine = 0, then the TP channel is not
closed, thus the ECU may communicate further on.

If F_Routine = 0, then the PG continues with the next service

“RequestRoutineResultsByLocalIdentifier”

The PG must, out of time reasons, before the expiration of time

P2CAN_Flash, test a channel structure:
T ChS = 4s
Time T_ChS has elapsed; the PG opens a new TP The existing channel is closed for the deletion time
communication

As soon as the ECU is able to reestablish the communication, ,

it must respond positively to the channel

If the ECU still has not reacted after the termination of the
Time P2CAN_Flash, then the PG interrupts the flash sequence.
Timings according
Timings according to Chapter 3.4.2 to Chapter 3.4.2

Request, if the delete process was successful

Quitting

Transfer the program data

Quitting

Terminate the transmit of the program

data

Quit termination

Transmit the check sum and request to calculate the

check sum .
Begin with the calculation of the check sum.
Quit request.
During the check sum calculation, the ECU must be able to
Request the result of the calculation communicate. The calculation usually takes longer, independent of
the data size.
Confirming of the programming correctness.
If further blocks are defined within the data container, then the
PG repeats the programming procedure beginning with
“RequestDownload”

Because of the problem for the

The ECU responds negatively to this request
with “noProgramm”

Termination of the communication

Quit termination

Attention: Normal process after KWP2000 at this point,

i.e. the PG transmits the Disconnect

Initializing the transmission of the broadcast service “Mute”.

In this case, the actual flash procedure is closed.

Figure 3: Flow diagram – positive operation –side 2

29
 Reconnection

In order to guarantee the complete efficiency of the ECUs, the PG must examine the internal documentation of the ECU
ECUs without discrete PinKl.15 perform implicit software reset
Immediately after the TP-channel is dismantled, the PG initiates the ECUs with discrete PinKl.15 perform an implicit software reset
switching off of PinKL.15 independent of “PinKl. 15 on”.

The control unit developer has to make sure that he generates no

inconsistencies through shooting phases or through other similar
The PG initiates the reset of PinKL.15 ones.
New initialization:
An ECU must update the following EEPROM-data from here (the
sequence is to be taken into account):
1. The new SW-status and possible new part number
2. Increment the counter for successful programming
3. Reset the inconsistency bit (‘0’)
4. Write the flash date.

The PG initiates the diagnostic communication and examines the

new internal documentation within the sequence described below

The ECU first responses, when the consistency of the internal

documentation 9B, as well as the internal status of the SW is
guaranteed.

The PG has the possibility of a consistency examination of the data

(old/new description)
If the programming procedure went wrong, then the ECU is not
capable to run in generally. The PG may establish this during a
correct implementation by means of the inconsistency bits (‘1’), and
if necessary, to initiate a renewed flash sequence

Quit termination

Figure 4: Flow diagram – positive process – side 3

30
B2. Entrance Flash process at ECU within the boot loader

Channel structure with quick Timings!

The flash flow is cancelled, if not all preconditions are accomplished

F_Boot = 0 The ECU is found within the BLF

Request Seed (Level 1)

At this point, the ECU is not allowed to be disconnected

Send Key (Level 2)

Send Release (level 2)

It will be repeated, as long as

there are still data blocks to
be programmed

Programm data parameter notification

Examine the memory area and adjust the decryption

Figure 5: Flow diagram – entrance at ECU within the boot loader

31
C. Problems for programming device

Generally, the current LH valid for the conversion time applies for old ECUs. In detail, this means the
following for the PGs:

C1. With regard to Chapter 3.4.1.1

In the case of control unitss, which do not transfer the parameter F_Boot, the PG sets the waiting
period automatically on zero.

C2. With regard to Chapter 3.4.1.2

If the parameter F_Routine is not transferred, then no change of the Timer follows for P2, the channel
is not closed.
In the case of old control units, a value of F_Routine>0 does not mean that the channel is closed. The
problem applies here:
[Extract from the LH version 1.03, Chapter 3.4.2, Page 12, foot note 3]
“The customer service-tester works during the Flash-process with a MNCT of 50sec, i.e. the ECU is not
allowed to serve maximum 50 CT (=50sec) consecutively, until it comes to a termination of the
communication. On the KWP2000 level, the ECU gives the Timeout time for a KWP2000 through
F_Routine.
With the help of the F_Routine and the MNCT of 50sec within the programming device, the dead times
in the communication during Flash-Delete are handled without a communication termination”
The PG distinguishes the behavior depending if the ECU within a time period of 4s after the positive
response to the 0x31C4 “StartRoutineByLocalIdentifier EraseFlash” sends (new) or does not send (old)
an 0xA8 “Disconnect” on the TP-level.

C.3 with regard to Chapter 3.6.1

In the case of reconnecting the old control units, it may happen that the internal documentation
0x1A9B/9C is still old or at least not conclusive when it is requested too early.

C.4 Appendix A
At some points, negative responses, which are not mentioned here any longer, and which in older LH-
versions are displayed as “to be described by the control unit responsible” may be sent back by the
ECU. Thus, the PG does not generally evaluate these responses.

C.5 StopDiagnosticSession
The service 0x20 “StopDiagnisticSession” is no longer available at new control units. According to this
LH, the control units respond to these requirements with 0x90 “noProgram” (within the BLF). This
negative response must not lead to a termination of the flash sequence; instead it has as consequence
the fact that, the PG must send a 0x82 “StopCommunication” according to Appendix B. A PG must take
into account that the old control units must close the TP-channel after a 0x82 “StopCommunication”
0x20 per “Disconnect” 0xA8.

C.6 with regard to Chapter A.2

In case of Request 0x1085 “StartDiagnosticSessionFlash”, old ECUs transmit the NRC 0x33
“securityAccessRequested”, when they were not yet disconnected. Thus, the PG must perform a
Seed&Key-operation:
- Request Seed 0x2701 → evaluate Key on the basis of the Seed transmitted by the ECU
- Send Key 0x2702 <Key> → evaluation of the response by the ECU
- Renewed request 0x1085

C.7 with regard to Chapters A.6 and A.10

Both services 0x33C4 “RequestRoutineResultsByLocalIdentifier EraseFlash” and 0x33C5
“RequestRoutineResultsByLocalIdentifier CalculateFlashChecksumme” can be answered with 0x40
“downloadNotAccepted” in case of an unsuccessful Routine

32
D. Broadcast commands

D.1 Mute

The PG cyclically transmits the Broadcast-service 0x28 “Mute” during the programming session, as
described in the sequence chart.
For the FP, command “Mute” is to be implemented mainly according to Chapter /6/.
For the BLF, the implementation of command “Mute” is not requested.

D.1.1 Preconditions

The PG examines, at the beginning of the flash sequence, the internal documentation 0x1A9C “Status
Flash”, and thus obtains information about the preconditions to be maintained. These must be
accomplished, further examinations of the preconditions are not requested, since, in general, no data
contents ask for cyclic messages.
PGs, which have knowledge about the contents of the cyclic data transfer to the CAN (e.g. bad final
examination), may carry out further examinations. The type of these examinations has to be agreed
upon by the current system responsible.

D.1.2 Operation

The PG begins with the transmit of the “Mute” command as soon as it has received the positive answer
to 0x1085 “StartDiagnosticSessionFlash”. Thus, it is guaranteed, that the programming preconditions
were valid with 0x1A9C at the time of the request. These are no longer to be examined within the BLF
from the point of view of the consistency.
The PG sets the cyclic transmit of the “Mute” command with the completion of the flash operation. The
end is reached, when the ECU positively answers request 0x82 “StopCommunication”.
Besides this, the PG sets the transmit, when the communication is interrupted because of an error
within the flash sequence.

D.2 Delete central FSP

The broadcast-service 0x14 “Delete central FSP” is addressed to the entire network at the
reconnection, after the request of the internal documentation of the programmed ECU. Thus, it is
established that the vehicle is again transferred in a consistent and running order condition.

33
E. SCA Insertion

To be taken into account in the case of control units, at which an additional encryption of the data
blocks of the data container is requested.
The key encryption follows after the Seed&Key-authentication, by means of the service 0x3BC0
“WriteDataByLocalIdentifier SCA” (Chapter E.1).
The attendance and the precise requests for the concerned control units, are to be agreed upon with
the system responsible. It is not part of the LH.
In order to abut the extended flash operation against the key insertion, the tester evaluates the first
FormatIdentifierByte in the data container. If this Byte is registered with 0xX8 (according to A.4.2/),
then the service 0x3BC0 “WriteDataByLocalIdentifier key insertion SCA” carried out; otherwise, the
flash operation is carried on without this service.
The PG obtains, from a database, a valid SCA for the flash software, on the basis of
The control unit serial number from 0x1A86 and Software part number/ control unit identification from
0x1A9B.
After inserting the SCA in the ECU, the PG is able to program encrypted data container appropriate to
the SCA discarded within the ECU. Therefore, the ECU must decrypt the programming data with the
help of the available SCA.
The key encryption is presented in a sequence chart in Chapter E.2.
During the development phase, a special development-SCA is to be used, with which the
corresponding software status can be flashed.

E.1 WriteDataByLocalIdentifier SCA

C1 Data is false encrypted, false data, data frame not complete (e.g. K2 is not transferred).
C2 EE-Prom impossible to write

Data Parameter name Value

#1 WriteDataByLocalIdentifier ReqSid M 3B
#2 RecordLocalIdentifier M C0
#3 Krypted_SCA_K1 [15] M XX
: :
#18 Krypted_SCA_K1 [0] M XX
#19 Krypted_SCA_K2 [15] M XX
: :
#34 Krypted_SCA_K2 [0] M XX

Positive Response Negative Response Value

#1 WriteDataByLocalIdentifier PRSId M 7B Negative response SId M 7F

WriteDataByLocalIdenti M 3B
#2 RecordLocalIdentifier M C0
fier PRSId
#3 default Responses CD XX
[according to Table 4! C0 XX
No reference source
could be found.]
requestOutOfRange C1 31
generalReject C2 10

34
E.2 Sequence Chart with initializing of the SCA

ECU within
the BLF
Request Seed
(level 1)

At this point, the ECU is not allowed to not to be

disconnected.
Send Seed (Level 1)

Send Key (level 2)

Transfer the SCA Send release (Level 2)

Examine and disconnect The SCA

Program Data parameter notification

Examine the memory area and adjust the decoding

Transfer the possible block length

Figure 6: Flow diagram – SCA insertion

35
F. Programming of multiple-processor control units

The following two cases are to be distinguished for the programming of multiple processor systems.

F.1 Multiple processor systems with single diagnostic addresses

The PG handles the systems identically with the single processor systems. The system works within an
interconnection (e.g. Master-Slave). The programming of this control unit follows with a single data
container. During the programming, the main processor (Master) sorts out through an Address-Offset,
which data is to be programmed in which processor. There is no difference for the PG while handling
the multiple-processor systems from this category; these are identified as single ECU.

F.2 Multiple processor system with multiple diagnostic addressing

These control units possess complete diagnostic functionality for each processor, as described in
Chapter /10/. An update of these control units follows with at least the number of the data container,
which is equal to the number of the existing processors (e.g. a data container for each diagnostic
address). For the PG, each processor is to be treated as a single ECU.

F.3 Combinations

In the case of control units starting with 3 processors, it is conceivably to integrate both cases
mentioned above.

36