Script based flashing
Version 1.0
2007-03-20
Application Note AN-IMC-1-010
Author(s)
Restrictions
Abstract
Andreas Patzer
Public Document
Show the flashing possibilities of CANape / CANdito based on scripting
Table of Contents
1.0
1.1
1.2
1.3
1.3.1
1.3.2
2.0
2.1
2.2
2.2.1
2.2.2
2.2.3
2.2.4
3.0
3.1
3.1.1
3.1.2
3.2
3.2.1
3.2.2
4.0
4.1
4.2
4.3
4.4
4.5
5.0
6.0
Overview ..........................................................................................................................................................1
Tool Overview ...............................................................................................................................................2
Development Environment and Script Language .........................................................................................3
ECU integrated Flash Boot Loader (FBL) .....................................................................................................4
Bootloader...................................................................................................................................................4
Flash Driver.................................................................................................................................................4
Introduction ......................................................................................................................................................4
Physical Basics .............................................................................................................................................4
Flash concept ................................................................................................................................................5
Usage of a Flash Boot Loader (FBL) ..........................................................................................................6
Technical flash concept ..............................................................................................................................6
Different places to flash ..............................................................................................................................7
Security .......................................................................................................................................................7
Protocol Overview............................................................................................................................................8
How to use the diagnostic services with CANape / CANdito ......................................................................11
Record the Diagnostic Services with Macro Recorder .............................................................................12
With function / script editor of CANape / CANdito ....................................................................................13
Flash Demo .................................................................................................................................................15
CANape 6.1 / CANdito 2.1 Flash Demo ...................................................................................................15
CANape 6.1 / CANdito 2.1 Flash Demo via COM Interface and with ODX-F Files..................................16
Vector Tools Overview...................................................................................................................................16
CANfbl: ........................................................................................................................................................16
CANdelaStudio:...........................................................................................................................................16
CANdelaFlash: ............................................................................................................................................17
CANdito: ......................................................................................................................................................17
CANape:......................................................................................................................................................17
Additional Resources .....................................................................................................................................17
Contacts .........................................................................................................................................................17
1.0 Overview
The goal of this document is to show the flashing possibilities of CANape / CANdito based on the script language
of these tools. CANdito is a subset of CANape. The flash process described in this document is not manufacturerspecific, but based on the “KWP2000 on CAN” standard ISO 15765-3.
1
Copyright © 2007 - Vector Informatik GmbH
Contact Information: www.vector-informatik.com or ++49-711-80 670-0
Script based flashing
In the context of flash programming we can identify different parts:
•
•
•
Flash Boot Loader (FBL): The primary software in an ECU that allows erasing and to reprograming of the
ECU’s flash memory. The FBL receives commands and dates via a serial interface e.g. CAN.
Flash Container: A data container containing all information, that is necessary for flashing a new content
into the flash memory of the ECU:
o FlashJob: the PC based flash tool runs the flash job to transfer a Binary-file from the PC into the ECU
flash memory.
o Binary-File: the new content that should be transferred into the flash memory.
o Flash driver: code that is stored temporarily into the RAM of the ECU. It contains all the functions that
are necessary for erasing the flash memory and replacing the content of ECU flash memory.
o Diagnostic description: file that at least contains diagnostic services. The description file may also
contain the diagnostic data description of the ECU.
Flash Tool: In the development stage of an ECU typically PC based tools are used. The Flash Tool
performs the OEM-specific flash programming process that either is hard-coded (OEM specific tool) or
provided by an OEM-specific job description (script).
Picture 1: Flash Overview
1.1 Tool Overview
CANape is positioned as a measurement, calibration and diagnostic tool. CANdito is a subset of CANape with the
focus on diagnostics.
From a certain point of view, calibration and diagnostic purposes have many commonalities to flashing new content
into an ECU. Therefore CANape and CANdito were expanded to efficient flash tools for all kind of flash purposes:
•
•
•
Flashing data and software
Over KWP2000 and UDS on CAN with both tools and
Over CAN Calibration Protocol (CCP) and Universal Calibration Protocol (XCP) with CANape
Flashing over CCP and XCP is straightforward. Using KWP2000 or UDS allows for more freedom. So the
proposed solution is to use our script language to realize individual flash processes.
As mentioned before this document is focusing on the usage of scripts to use KWP2000 on CAN. As well as UDS
is handled in the same way.
The primary usage area of CANape is the optimal parameterization (calibration) of ECUs. For more details about
CANape please visit our homepage: www.vector-informatik.com.
2
Application Note AN-IMC-1-010
Script based flashing
CANdito is the diagnostic tester in Vector’s CANdela diagnostic tool chain. CANdito allows symbolic access to all
data and functions provided by the diagnostic protocol interface of an ECU. All services, data, and protocol
parameters are described in a comprehensive database (CDD- or ODX-format), which is generated by
CANdelaStudio. This database is used during all phases of the development process. This ensures that the
diagnostic tester’s data supply is up to date, consistent and specific to the ECU. CANdito is able to communicate
with electronic control units from all vehicle manufacturers. This means that ECU suppliers in the automotive
industry require only one diagnostic tester for different customers. In addition to its use as a diagnostic tester,
CANdito can also be used for acquiring and evaluating measurement data from CAN, LIN bus, or external analog
and digital measurement devices.
1.2 Development Environment and Script Language
The CANape / CANdito script language is very similar to C. The library functions are designed to allow efficient
development of flash scripts. Script functions like:
FlashParameterSet(), HexFileGetRegionInfo() and HexFileLoad()
XmlGetNodeString(), XmlGetNodeNumeric() and XmlGetNumberOfNodes()
In that case our flash scripts have the function of a so-called “Flashjob”.
Picture 2: The script defines the way to flash the binary file into the ECU
The script based on diagnostic services and data. To know what services and data are in the ECU, the solution is
based on a diagnostic description file. With this description file, the user has a comfortable access to the services
and data.
Picture 3: The script uses the described services
3
Application Note AN-IMC-1-010
Script based flashing
As an authoring system for diagnostic description files the Vector tool CANdelaStudio fits perfectly. To develop the
flash scripts CANape and CANdito have integrated debugging and protocol analyzing mechanism to simplify the
work.
1.3 ECU integrated Flash Boot Loader (FBL)
The tools CANape / CANdito can interact with nearly all flash boot loaders, which are based on KWP2000 on CAN
or UDS.
The Vector Flash Bootloader CANfbl is available for several vehicle manufacturers. CANfbl consists of the
Bootloader and the Flash Driver (Flash Algorithms). The Bootloader and the Flash Driver are separate software
modules.
The Flash Bootloader provides very flexible configuration options to adapt it to the customer’s requirements, e.g.
for creating mechanisms to guarantee that the flashed application is valid and to avoid starting a faulty flashed
application. The Flash Bootloader supports "flashing" in a networked vehicle. ECUs that are not affected by the
reloading process are shifted into a "silent mode", so that the entire bus bandwidth is available for the transmission
of flash data.
1.3.1
Bootloader
It contains a basic CAN communication layer, a transport protocol (TP) and diagnostics protocol, all optimized to
use minimum memory. The Bootloader resides in the protected memory of the controller. The application and the
Bootloader never run simultaneously.
1.3.2
Flash Driver
The Flash Driver is downloaded shortly before the actual application flashing. For technical reasons, this code
resides in RAM; it does not remain permanently in memory. The benefits are that the Flash Driver can easily be
changed, and that it is not possible to execute it by accident. The Flash Driver writes the downloaded application
into flash.
2.0 Introduction
In the context of this document, flashing means to transfer data over the CAN bus from a PC into the flash memory
of the electronic control unit (ECU).
2.1 Physical Basics
Flash memory is a form of EEPROM (Electrically-Erasable Programmable Read-Only Memory) that allows multiple
memory locations to be erased or written in one programming operation. In layman's terms, it is a form of
rewritable memory chip that, unlike a Random Access Memory chip, holds its content without the need of a power
supply. It is also an example of a Non-Volatile Read Write Memory (NVRWM).
Flash memory stores information in an array of floating gate transistors, called "cells", each of which traditionally
stores one bit of information. There are two main cell technologies: NAND or NOR.
Normally only NOR cells are used for automotive purposes. The main reason is, that this technology allows
reading information byte-per-byte. NAND structure can only be read block-wise.
In NOR flash, each cell looks similar to a standard MOSFET transistor, except that it has two gates instead of just
one. One gate is the control gate (CG) like in other MOS transistors, but the second is a floating gate (FG) that is
insulated all around by an oxide layer. The FG is between the CG and the substrate. Because its insulating oxide
layer isolates the FG, any electrons placed on it get trapped there and thus store the information. When electrons
are on the FG, they modify (partially cancel out) the electric field coming from the CG, which modifies the threshold
voltage (Vt) of the cell. Thus, when the cell is "read" by placing a specific voltage on the CG, electrical current will
4
Application Note AN-IMC-1-010
Script based flashing
either flow or not flow, depending on the Vt of the cell, which is controlled by the number of electrons on the FG.
This presence or absence of current is sensed and translated into 1's and 0's, reproducing the stored data. In a
multi-level cell device, which stores more than 1 bit of information per cell, the amount of current flow will be
sensed, rather than simply detecting presence or absence of current, in order to determine the number of electrons
stored on the FG.
A NOR flash cell is programmed (set to a specified data value) by starting up electrons flowing from the source to
the drain, then a large voltage placed on the CG provides a strong enough electric field to suck them up onto the
FG, a process called hot-electron injection. To erase (reset to all 1's, in preparation for reprogramming) a NOR
flash cell, a large voltage differential is placed between the CG and source, which pulls the electrons off through
quantum tunneling. In single-voltage devices (virtually all chips available today), this high voltage is generated by
an on-chip charge pump.
One limitation of flash memory is that although it can be read or programmed a byte or a word at a time in a
random access fashion, it must be erased a "block" at a time. Starting with a freshly erased block, any byte within
that block can be programmed. However, once a byte has been programmed, it cannot be changed again until the
entire block is erased. In other words, flash memory (specifically NOR flash) offers random-access read and
programming operations, but cannot offer random-access rewrite or erase operations.
Most modern NOR flash memory components are divided into erase segments, usually called either blocks or
sectors. All of the memory cells in a block must be erased at the same time. Erasing and flashing stresses the
insulating oxide layer. So the number of overwriting the content in ECUs is limited.
2.2 Flash concept
Flash concept describes the process of how to store information into the flash memory. We have to remember,
that:
•
•
•
•
•
•
•
•
Before storing a new content into the flash memory, the memory has to be erased.
Erasing is only possible in blocks of cells (so called segments).
The number of flash erasing is limited by the technology. How to handle the accounting?
How to flash on typical places? Are there some special circumstances that must be fulfilled, before flashing
is possible?
What happened if there is a breakdown of the communication during the flashing? The flash content is
corrupt and maybe no communication with the ECU is possible anymore.
How can we be sure, that only authorized people are able to flash a new application into the ECU?
How can we be sure, that only authorized software will be flashed into the ECU?
Even if the software is authorized, how can we be sure that the authorized people will only flash content
that fits into the ECU? Maybe the ECU hardware version does not fit to the software release, or the
application does not fit to the country- or equipment-variant of the car.
All these problems can be solved with the right tool chain selected.
5
Application Note AN-IMC-1-010
Script based flashing
Application
The Fla sh D r ive r r e- pr ogram m s
t he applicat ion via CAN in
connect ion wit h t he Flasht ool.
The Fla sht ool is an easy t o use PC
t ool and cont rols t he download of
your applicat ion ( as hex - file) .
Addit ionally you need a CAN card,
e.g. CANcardXL.
Interrupt Vector Table
Applikation
CANdit o
Random Access Memory
Protected Area
Flash Boot loader
Validation Area
CANape
Flash Driver
CAN
Bootloader
Transport Protocol,
KWP2000-Services,
CAN Driver
IsValid⏐Invalidate⏐Validate
Interrupt Vector Table
FBL
The Boot loa de r cont ains basic CAN
com m unicat ion, a Transport Prot ocol
and Diagnost ics ( KWP2000) , bot h
code opt im ized t o use m inim um
m em ory.
Picture 4: Basic flash tool chain: Bootloader, Flash Driver and Flash Tool
2.2.1
Usage of a Flash Boot Loader (FBL)
Question:
What happened if there is a breakdown of the communication during the flashing? The flash
content is corrupt and maybe no communication with the ECU is possible anymore.
Some ECU implementations are not able to deal with a communication breakdown. This could mean that the ECU
is damaged or that a controller specific debugging tool is needed to reprogram it.
The Vector Flash Bootloader is designed to recover from a communication breakdown. The FBL is stored in a
secure area of the flash memory. “Secure area” means, that nobody is able to erase this area anymore. The FBL is
a complete small application. The FBL and the “normal” ECU application will never run at the same time.
The FBL at the least contains a basic CAN communication driver, a transport protocol (e.g. ISOTP), a diagnostic
protocol like KWP2000 or UDS, and some diagnostic functions to diagnose the flash process. If the content of the
flash memory is corrupted, e.g. cause of a communication breakdown at the last flash process, the FBL will stay
active and it will wait for a communication partner that will try to download again an application.
2.2.2
Technical flash concept
Question:
Before storing a new content into the flash memory, the memory has to be erased.
Erasing is only possible in blocks of cells (so called segments).
The number of flash erasing is limited by the technology. How to handle the accounting?
There are special software functions to erase flash segments. The functions are only used to erase the flash. For a
couple of reasons, it’s not a good idea to store these functions permanently in the flash. On the one hand, these
6
Application Note AN-IMC-1-010
Script based flashing
functions need place in the memory, and on the other hand it’s dangerous. What would happen, if an application
error would call this function, while the ECU is working in a car? Normally no one is interested to store this
functionality permanently in the ECU.
The solution is simple. Prior to the download of the new flash data the flash tool downloads the routines for erasing
and reprogramming the flash memory (“Flash Driver”) to the ECU RAM (see picture 1). These routines are
removed from RAM as soon as the flash download is finished (at the ECU reset).
Pay attention: This will only work, if the controller of the ECU supports the usage of executable code from RAM.
There are some controllers on the market, which are not able to handle this.
To make sure that the number of flash cycles doesn’t exceed the limits given by the manufacturer of the flash
memory, the Vector Flash Boot Loader checks the number of cycles by storing it to EEPROM.
2.2.3
Different places to flash
Question:
How to flash on typical places? Are there some special circumstances that must be fulfilled, before
flashing is possible?
There are different places where a flash memory chip will be flashed in its lifetime:
Before a flash chip is integrated into an ECU, it gets the data typically over a debugging interface (e.g. JTAG).
In the ECU manufacturing, debugging interfaces and CAN bus is used.
In the development phase diagnostic protocols like KWP2000 on K-Line or KWP2000/UDS on CAN are used.
Flashing over CCP or XCP is also very common in this phase.
In the car manufacturing (end of line) flashing is done with the diagnostic protocols on K-Line or CAN.
In the garage only diagnostic protocols are in use.
Flashing in the car (regardless post-sales or development phase), is often done by diagnostic protocols. Please
pay attention, that flashing should only be allowed, when the speed of the car is zero.
2.2.4
Security
Question:
How can be assured, that only authorized people are able to flash a new application into the ECU?
That only authorized software will be flashed into the ECU? That the new flash data (ECU
application) is compatible to the software/hardware equipment and the car configuration?
It’s not about safety and reliability of the ECU application. It’s about the IT security. How can we prevent, that
anybody is able to manipulate the application?
There are many reasons, why it is so attractive to manipulate: A car with less number of miles on the mileage
counter has a higher resale value. So let’s decrease the mileage counter in the dashboard. The drive horsepower
of a motor is not only a question of the mechanical motor system. It’s also a question of the flashed application.
To prevent that the system will be manipulated, there are some security mechanisms like: seed & key for the
authorization of people, digital signatures to check the authorization of the software, and some more.
The FBL must be able to handle all this security purposes in combination with the flash tool and the other process
relevant tools. This extends the scope of the document.
Vector has long-term period experiences in the development of tool chains. Please talk to us.
7
Application Note AN-IMC-1-010
Script based flashing
3.0 Protocol Overview
KWP2000 on CAN is standardized as ISO 15765-3.
The diagnostic protocols KWP2000 and UDS are service oriented. Every service has its own identification number
and an individual number of bytes.
Example: Service “StartDiagnosticSession” into the Flash Programming Session
Request Service ID:
$10
First Byte:
$85, Flash Programming Session
Positive response from ECU:
Response Service ID:
$50
First Byte:
$85, first Byte from Service ID 10
Negative response from ECU:
Response Service ID:
$7F
First Byte:
$10, send the Request Service ID back to have a link between request and response
Second Byte:
$10: General reject, send back the Request Service ID means “total reject”
$78: Request correctly received, response pending
$80: Service not supported in active diagnostic mode
The following table shows an example of a flash sequence over KWP2000 on CAN. Content of the table is copied
from the trace window of CANape.
Direction TX: From CANape / CANdito to ECU
Direction RX: From ECU to CANape / CANdito
Time
3m 7.66918s
Dir
Tx
Len
2
Data
10 85
3m 7.67015s
Rx
2
50 85
3m 7.67071s
Tx
2
27 01
Description
LocalID: ($10) StartDiagnosticSession
Servicename: Process
SID-RQ: 0x10
Diagnostic Mode: ECUProgrammingMode
LocalID: ($10) StartDiagnosticSession
Servicename: Process
SID-PR: 0x50
Diagnostic Mode: ECUProgrammingMode
LocalID: ($27) SecurityAccess
Servicename: Process
SID-RQ: 0x27
AccessMode: requestSeed
Key:
Start Programming Mode
Start seed & key and request
the seed from ECU
8
Application Note AN-IMC-1-010
Script based flashing
Time
3m 7.67115s
Dir
Rx
Len
4
Data
67 01
cc dd
3m 7.67277s
Tx
4
27 02
33 22
3m 7.67316s
Rx
2
67 02
3m 7.67417s
Tx
2
31 01
3m 7.67524s
Rx
2
71 01
3m 7.676s
Tx
8
34 e0
00 00
00 00
05 c4
3m 7.67723s
Rx
3
74 01 ff
3m 7.68137s
Tx
511
36 a0
00 00
01 fa ..
3m 7.68726s
Rx
1
76
3m 7.71014s
Tx
1
37
3m 7.71134s
Rx
1
77
3m 7.71177s
Tx
3
31 03
7d
Description
LocalID: ($27) SecurityAccess
Servicename: Process
SID-PR: 0x67
AccessMode: requestSeed
Data: 0xCC 0xDD
LocalID: ($27) SecurityAccess
Servicename: Process
SID-RQ: 0x27
AccessMode: sendKey
Key: 0x33 0x22
LocalID: ($27) SecurityAccess
Servicename: Process
SID-PR: 0x67
AccessMode: sendKey
Data:
LocalID: ($31) StartRoutineByLocalIdentifier
Servicename: Process
SID-RQ: 0x31
Routine Local Identifier: 0x01
Routine Entry Option:
LocalID: ($31) StartRoutineByLocalIdentifier
Servicename: Process
SID-PR: 0x71
Routine Local Identifier: 0x01
Routine Entry Status:
LocalID: ($34) RequestDownload
Servicename: Process
SID-RQ: 0x34
Memory Address: 14680064
Data Format Identifier: 0x00
uncompressed Memory Size: 1476
LocalID: ($34) RequestDownload
Servicename: Process
SID-PR: 0x74
Transfer Response Parameter: 0x01FF
LocalID: ($36) TransferData
Servicename: Process
SID-RQ: 0x36
Transfer Request Parameter: 0xA0 0x00
0x00 0x01 0xFA ….
LocalID: ($36) TransferData
Servicename: Process
SID-PR: 0x76
Transfer Response Parameter:
LocalID: ($37) RequestTransferExit
Servicename: Process
SID-RQ: 0x37
Transfer Request Parameter
LocalID: ($37) RequestTransferExit
Servicename: Process
SID-PR: 0x77
Transfer Response Parameter
LocalID: ($31) StartRoutineByLocalIdentifier
Servicename: Process
SID-RQ: 0x31
Routine Local Identifier: 0x03
Routine Entry Option: 0x7D
Send back seed
Send key to ECU
Positive response from ECU
(key was correct)
Start flash driver download into
RAM
Ask the slave about the
maximum number of block
length
Return max. number of block
length
Transfer Flash Driver into RAM.
The necessary number of
TransferData depends on the
amount of data and the max.
block length.
End transfer flash driver into
RAM
Jump to the start of the flash
driver sequence. Now the further
steps, like to erase the flash
memory content, is done by the
flash driver.
9
Application Note AN-IMC-1-010
Script based flashing
Time
3m 7.71234s
Dir
Rx
Len
2
Data
71 03
3m 7.71296s
Tx
8
34 c0
80 00
01 00
1b 2e
3m 7.71335s
Rx
3
74 01 ff
3m 7.71641s
Tx
212
36 f7
03 8e ..
3m 7.71937s
Rx
1
76
…
3m 9.71645s
Tx
Tx
…
1
..
37
3m 9.71668s
Rx
1
77
3m 9.71775s
Tx
3
31 03
25
3m 9.71874s
Rx
2
71 03
3m 9.71917s
Tx
2
11 01
3m 9.71975s
Rx
2
51 01
Description
LocalID: ($31) StartRoutineByLocalIdentifier
Servicename: Process
SID-PR: 0x71
Routine Local Identifier: 0x03
Routine Entry Status:
LocalID: ($34) RequestDownload
Servicename: Process
SID-RQ: 0x34
Memory Address: 12615680
Data Format Identifier: 0x01
uncompressed Memory Size: 6958
LocalID: ($34) RequestDownload
Servicename: Process
SID-PR: 0x74
Transfer Response Parameter: 0x01FF
LocalID: ($36) TransferData
Servicename: Process
SID-RQ: 0x36
Transfer Request Parameter: 0xF7 0x03
0x8E …
LocalID: ($36) TransferData
Servicename: Process
SID-PR: 0x76
Transfer Response Parameter:
LocalID: ($36) TransferData
LocalID: ($37) RequestTransferExit
Servicename: Process
SID-RQ: 0x37
Transfer Request Parameter:
LocalID: ($37) RequestTransferExit
Servicename: Process
SID-PR: 0x77
Transfer Response Parameter:
LocalID: ($31) StartRoutineByLocalIdentifier
Servicename: Process
SID-RQ: 0x31
Routine Local Identifier: 0x03
Routine Entry Option: 0x25
LocalID: ($31) StartRoutineByLocalIdentifier
Servicename: Process
SID-PR: 0x71
Routine Local Identifier: 0x03
Routine Entry Status
LocalID: ($11) EcuReset
Servicename: Process
SID-RQ: 0x11
Reset Mode: 0x01
LocalID: ($11) EcuReset
Servicename: Process
SID-PR: 0x51
Reset Status: 0x01
Servicename: Process
SID-RQ: 0x31
Routine Local Identifier: 0x03
Routine Entry Option: 0x25
Ask the slave about the
maximum number of block
length
Return max. number of block
length
Start the download of the new
application into flash memory.
TransferData is used until all
data are send to the ECU.
..
End the download of the new
application into the flash
memory.
Checksum calculation
ECU reset
10
Application Note AN-IMC-1-010
Script based flashing
3.1 How to use the diagnostic services with CANape / CANdito
A description file in CDD or ODX format drives the ‘diagnostic engine’ of CANape/CANdito that performs the
diagnostic ECU communication. The Vector product CANdelaStudio is a dedicated authoring tool to create CDD
and ODX files respectively. If no ECU specific CDD/ODX file is available CANape/CANdito provide some generic
description files that allow developing flash scripts for KWP2000 and UDS based on native protocol service calls
and raw-hex service parameters.
In CANape / CANdito we support the access in two special diagnostic windows: The diagnostic window and the
fault memory window.
Picture 5: Fault Memory Window of CANape / CANdito
Picture 6: Diagnostic window of CANape / CANdito
11
Application Note AN-IMC-1-010
Script based flashing
The services can be selected and executed by mouse click. If there is a complete ECU-specific CDD, the services
and the data are completely defined and the results of the ECU are displayed clearly. When using a generic CDD,
the KWP2000- or UDS-specific services are defined, but not the data. This means, that the services can be
selected by symbol, but the data is in a raw format.
CANape / CANdito are offering two different ways to generate scripts: Record the diagnostic services, the user
select in the diagnostic window and a function editor with a comfortable access to the possible services and data.
3.1.1
Record the Diagnostic Services with Macro Recorder
With the integrated macro recorder in the diagnostic window, the selection and execution of services can be stored
as a script. (Right mouse click into diagnostic window, “Start macro recording”).
Example: Automatic generated code out of the diagnostic window for ($10) StartDiagnosticSession:
________________________________________________________________________________
// *** Script 'macro_CANdela_NAME2.scr' automatically generated on 2006/12/15, 14:16:21 ***
// TODO: - add appropriate error handling (communication, pos. / neg. response type, etc.)
//
- use appropriate (numeric) types and values for DiagSetParameter<Type>(..., ..., <value>);
//
- get needed (numeric) values with (<numeric value> =) DiagGetParameter<Type>(...);
//
- if necessary add handling to access e.g. collection parameters or multiple response messages
//
- for UDS positive response suppression use DiagSendRequest(request, true);
long request, response;
// message handles
//char strParamVal[256];
//int maxStrLen = 256;
OpenWriteWindow();
// open write window in case it's closed
DiagSetVerbose(1);
// verbose mode on
request = CANdela.DiagNewRequest("StartDiagnosticSession/StartDiagnosticSession/Process");
DiagSetParameterSymbolic(request, "diagnosticMode", "(reservedByDocument)");
response = CANdela.DiagSendRequest(request);
DiagDeleteMessage(request);
if (response <= 0) return;
// error
//DiagGetParameterString(response, "diagnosticMode", strParamVal, maxStrLen);
DiagDeleteMessage(response);
DiagSetVerbose(0);
// verbose mode off
_____________________________________________________________________________
request =
CANdela.DiagNewRequest ( " St art Diagnost icSession/ St art Diagnost icSe ssion/ Process " ) ;
Devicenam e
Qualifier out of t he CDD
in CANape
12
Application Note AN-IMC-1-010
Script based flashing
By using ‘qualifiers’ in your script, the script becomes CDD specific, i.e. the script may not work with other CDD
files.
A flash job should not be CDD dependant. So it is better to use the raw functions to address the services and not
the qualifiers.
Example:
#define Q_TRANSFER_DATA_SERVICE "TransferData/TransferData/Process"
SetCurrentDevice("CANdela");
//”CANdela” is the devicename used in CANdito / CANape
request= current_device.DiagNewRequest(Q_TRANSFER_DATA_SERVICE);
..
“TransferData/TransferData/Process” is the qualifier from the CDD. By using the definition of
“Q_TRANSFER_DATA_SERVICE “, it is simple to change different qualifiers out of different CDDs with one
command.
3.1.2
With function / script editor of CANape / CANdito
With the integrated function and script language of CANape / CANdito you can use the method of sending raw
diagnostic services and services referenced by qualifiers.
To start the editor select Tools | Functions and scripts …
The editor is divided into 4 sections:
Com piler st art
Overview
Over view t ree
- global variables
- funct ions
- scr ipt s
Edit or window
Com piler I nform at ion
Picture 7: Function and script editor
Scripts are defined in the Function Editor, reached via the menu command Tools | Functions and Scripts. Click with
the right mouse button on Scripts in the tree view on the left and select New from the popup menu. The Function
13
Application Note AN-IMC-1-010
Script based flashing
Editor now places a new script with the default name Script_1() in the tree view and opens the Properties dialog.
The default name Script1 in the Name field can be changed.
Picture 8: Set script name and path
After exiting this dialog with Ok, the user can now define the script in the Editor Window.
Former generated macro recorded scripts can be copied into the editor window as well. All scripts, which have not
yet been compiled, are flagged in the tree view with the
symbol. The script is compiled by clicking on the icon
in the toolbar or by choosing the menu command Object | Compile. Compiler error messages and compiler
progress reports are displayed in the Message Window, the bottom window of the Function Editor. The Function
Editor is exited with a click on the icon
in the toolbar
Running Scripts
After scripts have been defined in the Function Editor, there are several ways to execute them:
•
Usage of the Windows command line syntax “CANape32.exe – b <scriptname>” (or create a Windows
short cut) to start a script instantly after the CANape / CANdito is initialized.
• Usage of the menu command “Tools | Execute Script” to select and execute a script.
• Usage of the script as an AddOn via the menu item Tools | <Script Name>.
A script can be linked with an appropriate element on a panel and started by actuating this element. E.g. the start
button in the picture beneath.
Picture 9: Panel examples of the flash demo
The Task Manager can start several scripts. In each case the scripts are run in their own tasks, and CANape /
CANdito can run them parallel to a running measurement.
14
Application Note AN-IMC-1-010
Script based flashing
Use the menu command “Tools | Task Manager” to run several scripts in parallel and to assign scripts to particular
state transitions (start of measurement, after loading projects, etc.)
3.2 Flash Demo
Flash demos are part of each CANape and CANdito setup (regular version and demo version). Please use this
demo script to get more details about flash scripts. Use the ECU simulator and the demo project to check how the
script is controlled by a panel and how the Trace Window supports you to evaluate and analyze the flash process
on the level of the diagnostic protocol.
3.2.1
CANape 6.1 / CANdito 2.1 Flash Demo
After the installation of CANape / CANdito there is a “\Flash” subfolder.
Start “kwpsim.exe” and the CANape / CANdito project out of this folder. KWPsim.exe is the ECU that is flashed via
CANape / CANdito.
The complete flash demo is divided into 3 scripts: FlashVectorFblData, FlashVectorFblJob, FlashVectorFblMain;
And a couple of global parameters.
To use the script in a simple way, we integrated a flash panel into the project.
Picture 10: Flash project
By pressing the start button, CANape / CANdito will jump to the FlashVectorFblMain script. The checkboxes are
changing the values of the global parameters. As an “ECU” to flash, our KWP2000 simulator (“KWPsim”) is used.
15
Application Note AN-IMC-1-010
Script based flashing
With an activated “Compression” checkbox, the user can test the functionality of our new compression algorithm
that is available in the Vector Flash BootLoader.
3.2.2
CANape 6.1 / CANdito 2.1 Flash Demo via COM Interface and with ODX-F Files
In the installation phase of CANape / CANdito the user is asked, if the COM-examples should also be installed. In
these COM-examples there is also a flash demo using the COM-interface of CANape / CANdito. In the subfolder
“\COM\Flash” of CANape / CANdito
Start ”KWPsim.exe” and the “Example Flash.exe” out of the “\COM\Flash”-folder.
Picture 11: Flash Examples over COM with ODX-F Files
The Path in the Working Directory must be correct. By pressing the Start CANape-Button, CANape starts in the
ASAP3 mode. The available Sessions and Jobs have to be selected. With the “Start Flash script”-Button, the
KWPsim-ECU will be flashed. With “Stop-CANape” CANape will be closed.
4.0 Vector Tools Overview
4.1 CANfbl:
The Flash Bootloader is available for many hardware platforms and several car manufacturers.
4.2 CANdelaStudio:
Authoring tool for diagnostic description files (CDD- and ODX-format).
16
Application Note AN-IMC-1-010
Script based flashing
4.3 CANdelaFlash:
Authoring tool for flash container in ODX-F format.
4.4 CANdito:
Authoring tool for script development and test. Running environment for diagnostic test and flash.
4.5 CANape:
Same like CANdito plus measurement and calibration with CCP or XCP.
5.0 Additional Resources
WWW.CANFBL.COM
WWW.CAN-DIAGNOSTICS.COM
WWW.VECTOR-INFORMATIK.COM/VI_FLASHDATA_EN.HTML
WWW.CAN-BUS.COM
WWW.VECTOR-INFORMATIK.COM/VI_ECU_MEASUREMENT_EN.HTML
6.0 Contacts
Vector Informatik GmbH
Ingersheimer Straße 24
70499 Stuttgart
Germany
Tel.: +49 711-80670-0
Fax: +49 711-80670-111
Email: info@vector-informatik.de
Vector CANtech, Inc.
39500 Orchard Hill Pl., Ste 550
Novi, MI 48375
USA
Tel: +1-248-449-9290
Fax: +1-248-449-9704
Email: info@vector-cantech.com
Vector France SAS
168 Boulevard Camélinat
92240 Malakoff
France
Tel: +33 (0)1 42 31 40 00
Fax: +33 (0)1 42 31 40 09
Email: information@vector-france.fr
Vector Japan Co. Ltd.
Seafort Square Center Bld. 18F
2-3-12, Higashi-shinagawa,
Shinagawa-ku
J-140-0002 Tokyo
Tel.: +81 3 5769 6970
Fax: +81 3 5769 6975
Email: info@vector-japan.co.jp
VecScan AB
Lindholmspiren 5
402 78 Göteborg
Sweden
Tel: +46 (0)31 764 76 00
Fax: +46 (0)31 764 76 19
Email: info@vecscan.com
17
Application Note AN-IMC-1-010