Sharing | CAN UDS Diagnostic Operation Guide for TSMaster - 1

TSMaster can complete the diagnostic process development with less code or even zero code. Diagnostic developers only need to be familiar with the diagnostic process, and then they can get through the whole chain of R&D, production line and after-sales.

TSMaster's UDS diagnostic function not only supports CAN, LIN, but also supports Ethernet DoIP diagnostic function. TSMaster's CAN UDS diagnostic operation guide (above) mainly focuses on the creation of UDS diagnostic module, CAN UDS diagnostic transport layer configuration, and TSMaster basic diagnostic configuration.

Keywords in this paper: uds, basic diagnostics, diagnostic system variables

Table of Contents for this article

1、Creation of UDS Diagnostic Module of TSMaster

The process of creating the UDS Diagnostics module for TSMaster is as follows:

Step1:Diagnostic module is located in the main menu [Application] -> [Diagnostic Module], as shown in Figure 1-1 below.

Step2: [Add Basic Diagnostics] module, you can add more than one CAN basic diagnostic module, as shown in Figure 1-2.

TSMaster supports the creation of multiple diagnostic modules, and through the multi-channel TOSUN CAN card binding, can simultaneously connect and diagnostic interaction with multiple UDS diagnostic ECUs, and further can realize the synchronous diagnostic brushing and writing functions of multiple ECUs.

2、CAN UDS Diagnostic Transport Layer Configuration

TSMaster provides diagnostic transport layer configuration function, which allows users to configure the appropriate transport layer configuration according to their needs, such as bus type, request and response ID, FD variable baud rate, security algorithm and a series of configurations.

1.Diagnostic Transport Layer

The CAN diagnostic transport layer, ISO TP, contains the diagnostic transport layer and diagnostic service layer parameters as shown in Figure 2-1.

The specific parameters of one of the diagnostic transport layers, ISO TP, are described in the following categories:

● Bus type: Diagnostic transport layer type
Using the UDS on CAN/CANFD function, you can select the bus type as [CAN] or [CAN FD], which can be selected through the drop-down list, as shown in Figure 2-2:

● Channels: Logical channels used by the diagnostic module
TSMaster supports multiple diagnostic modules to work online at the same time. Here is used to select the current diagnostic module's application logic channel, which is selected through the drop-down list, as shown in Figure 2-3:

● Request ID: Sets the diagnostic request ID of the PC tool side of the diagnostic module.
● Request ID type: Set the diagnostic request ID type of the PC tool side of the diagnostic module, 0 is the standard frame (11 bits), 1 is the extended frame (29 bits), as shown in Figure 2-4.

● Answer ID: Set the diagnostic answer ID of the PC tool side of the diagnostic module.
● Response ID type: set the diagnostic response ID type of the PC tool side of the diagnostic module, 0 is the standard frame (11 bits), 1 is the extended frame (29 bits).

● Function ID: Set the diagnostic function ID of the PC tool of the diagnostic module.
● Function ID type: set the diagnostic function ID type of the PC tool side of the diagnostic module, 0 is standard frame (11 bits), 1 is extended frame (29 bits).

● Send padding bytes: During transmission, if the actual valid bytes are less than one CAN message data end, the remaining data segments are padded with bytes. For example, if a CAN telegram frame consists of 8 bytes and the valid transmission bytes are [0x02, 0x10, 0x02] and the padding byte is 0xAA, the actual telegram is [0x02, 0x10, 0x02].
The text section is [0x02, 0x10, 0x02, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA].

● Receive frame interval: the minimum frame interval (ms) for receiving consecutive frames. the minimum time interval between diagnostic frames that the TSMaster Diagnostics module, as a receiver, can support when receiving consecutive frames, this parameter is replied to the diagnostic client. This parameter is set to 0 to support the shortest time interval between diagnostic frames when receiving consecutive frame messages.

● User-defined Transmit Frame Interval: The minimum interval for transmitting consecutive frames is determined by the user, and the specific interval time is set by the value of [Transmit Frame Interval].

● Transmit Frame Interval: Minimum interval for transmitting consecutive frames.
● Transmit block size: The size of the data block that the TSMaster Diagnostics module, as a transmitter, can send at one time when sending a continuous frame message. Setting it to 0 means that the TSMaster Diagnostics module can send any size of data block at one time.

● FC Post-frame interval: Indicates the maximum time interval between sending a flow control frame and sending the first consecutive frame.

● FD Maximum DLC: The maximum DLC value of the FD frame, this parameter is only valid when there is [Bus Type] for CAN FD mode. This parameter is valid only when there is [Bus Type] in CAN FD mode:

● FD Variable Baud Rate: you can select whether to enable the variable baud rate mode.
● Maximum length: the maximum length of the service layer packet. This parameter is meaningless for normal CAN/LIN.

For example, for multi-frame transmission, DLC length = 8 bytes, the first frame (First Frame) uses the lower four bits of byte 0 plus 8 bits of the first byte, a total of 12Bit to indicate the size of the packet to be transmitted at one time, that is, a maximum of 4095 bytes, as shown in the table below:

When using the CANFD protocol, setting the DLC length > 8 bytes allows more Bits to be used to transmit information. Therefore, the transmission layer of CANFD supports the use of the 2nd, 3rd, 4th, and 5th bytes totaling 32 bits to transmit the length of a data block, in other words, the transmission layer of CANFD supports the transmission of up to 4 G's of data at a time. In other words, the transmission layer of CANFD supports the transmission of up to 4 Gs of data at a time.

Note: The high four bits of the first byte Byte0 = 1, indicating that the frame is the First Frame, both for the CAN and Classical CAN transport layers.

2.Diagnostic Service Layer

The Diagnostic Service Layer parameters mainly contain route activation, S3, P2 time parameters, and secure access for loading SeedKey. This is shown in Figure 2-6:

2.1 P2 time parameters

[P2 timeout]: Indicates the minimum time interval for the ECU to reply after receiving a diagnostic request frame. For the diagnostic tool, this parameter can be used as a timeout judgment parameter for waiting for a reply after sending a request. For example, if the diagnostic tool sends a diagnostic message and does not receive a reply within the P2 timeout period, the request is considered to have failed and the timeout period exits.

[P2 extension time]When the diagnostic tool sends out a diagnostic message, the ECU under test is too late to respond within the P2 timeout period, then it replies with a 7F XX 78 message to tell the diagnostic tool that it is too late to respond and needs to extend the waiting time before replying, and then the ECU sends out a delayed waiting message, then it switches the waiting time parameter to the P2 extended time. After the ECU sends a delayed wait message, it switches the wait time parameter to P2 extended time.

The above two parameters can be tapped on the [Details] button to view the graphical description as shown in Figure 2-7:

2.2 Diagnostics online

Diagnostics Online includes S3 Server Time and S3 Client Time parameters.

[S3 server time]: Indicates the timeout period after the ECU has been switched from the Default Session to another session, and how long it will automatically switch back to the Default Session.

[S3 Client Time]: Indicates the time interval for sending TesterPresent frames as the diagnostic tester side.

For the schematic diagrams of the above two parameters, you can tap the [Details] button to view the graphical description, as shown in Figure 2-8:

Diagnostics Online]: In the TSMaster Break module, you can choose to configure and enable the Diagnostics Online command, as shown in Figure 2-9:

When [Diagnoser Online] is enabled, the switch to activate [Diagnoser Online] appears above the diagnostic module. Setting Diagnoser Online to [On] will send the message at the set S3 client interval.

The send byte for Diagnostics Online is optional. Three types are supported:

[Default Diagnostics Online Service]: 0x3E 0x80 for the most commonly used.
[Select from base configuration]: Select the configured 3E command from the basic diagnostic configuration.
[user-defined]: Bytes for customization

2.3 Seed Keys

TSMaster provides two methods for handling SeedKey seed keys. The first one is the commonly used DLL library that loads the mainstream SeedKey; the second one provides a built-in SeedKey interpreter, which allows you to write SeedKey source code directly and save the generated DLL library.

2.3.1 Loading Dynamic Link Library

TSMaster not only supports DLL files encapsulated in C/C++, Delphi and other languages, but also supports DLL libraries based on Dot Net platforms such as C#, VB.Net and other languages, which is efficiently compatible with DLLs generated by different platforms for secure access, bringing engineers a more convenient experience.

Load the dynamic link library loading screen, as shown in Figure 2-10:

The icons are in order from left to right:

[1] Load DLL
[2] Delete DLL
[3] Open DLL verifier, through DLL verifier, user can judge whether the loaded DLL interface is correct or not, and whether the algorithm meets the design requirements or not. For example, after the user selects the Level of Seed, input the Seed value and click GenKey to judge. If the interface of the DLL is unified with the interface defined in the template, a prompt message will be output: Generate Key Success, and then the user can further confirm whether the algorithm in the DLL meets the design requirements according to the comparison between the key value and the target value. As shown in Figure 2-11.

[4] You can open the file path where the Seed&Key interface project is located in the TSMaster installation directory.

In the TSMaster installation directory, there are template projects that encapsulate the Seed&Key algorithm. TSMaster supports SeedKey function interfaces by default as follows:

Function Interface 1:
unsigned int GenerateKeyEx(
const unsigned char* ipSeedArray, /* Array for the seed [in] */
unsigned int iSeedArraySize,
/* Length of the array for the seed [in] */
const unsigned int iSecurityLevel,/* Security level [in] */
const char* ipVariant,
/* Name of the active variant [in] */
unsigned char* iopKeyArray,
/* Array for the key [in, out] */
unsigned int iMaxKeyArraySize, /* Maximum length of the array for the key
[in] */
unsigned int& oActualKeyArraySize);
/* Length of the key [out] */

Function Interface 2:
unsigned int GenerateKeyExOpt(
const unsigned char* ipSeedArray, /* Array for the seed [in] */
unsigned int iSeedArraySize, /* Length of the array for the seed [in] */
const unsigned int iSecurityLevel, /* Security level [in] */
const char* ipVariant, /* Name of the active variant [in] */
const char* iPara, /* */
unsigned char* iopKeyArray, /* Array for the key [in, out] */
unsigned int iMaxKeyArraySize, /* Maximum length of the array for the key [in]
*/
unsigned int& oActualKeyArraySize) /* Length of the key [out] */

Function Interface 3:
bool ASAP1A_CCP_ComputeKeyFromSeed(
const unsigned char* ipSeedArray, /* Array for the seed [in] */
unsigned short iSeedArraySize, /* Length of the array for the seed [in] */
unsigned char* iopKeyArray, /* Array for the key [in, out] */
unsigned short iMaxKeyArraySize, /* Maximum length of the array for the key
[in] */
unsigned short* opSizeKey) /* Length of the key [out] */

How to be compatible with other function interfaces
In daily use, it often happens that the user has already developed a SeedKey DLL, but the interface of this DLL is not any of the three mentioned above, so it can't be directly loaded into the diagnostic module of TSMaster. In this case, the existing SeedKey algorithm library can be packaged in the form of secondary packaging to generate a DLL that can be directly loaded into the TSMaster diagnostic module.

A practical example to explain how to be compatible with the DLL files of other interface functions, the schematic diagram of the secondary encapsulation process, as shown in Figure 2-12.

Step one.View the current DLL with the name UserSeedKey.DLL. the API functions inside this function are:

The function void GetKeyFromSeed01(byte* ASeed, byte*AKey) is called when the Seed level is 1.
When the Seed level is 3, call the function void GetKeyFromSeed03(byte* ASeed, byte*AKey).
The function void GetKeyFromSeed11(byte* ASeed, byte*AKey) is called when the Seed level is 11.

Then we know that the current DLL does not support the above three function interfaces, and we need to package them twice.

Step two.Select the GenerateKeyEx template project provided in the TSMaster installation directory, and use the function interface of the above DLL in that project. The basic idea is:

1. Use Loadlibrary to dynamically user existing DLLs.
2. According to the incoming Level parameter, use the GetProcAddress function to dynamically obtain the actual function pointer used to calculate the Key.
3. If the function pointer is successfully obtained, the function pointer is used to transfer the Seed value and calculate the corresponding Key value.GenerateKeyEx project secondary package example, as shown in Figure 2-13.

Step 3, , , After the GenerateKeyEx program has been developed, TSMaster loads the DLL where GenerateKeyEx is hosted directly. Note that the user needs to remove the existing UserSeedKey.DLL from the GenerateKeyEx program.
Copy it to the root directory of TSMaster or the directory where GenerateKeyEx.DLL is located. If you don't copy it, GenerateKeyEx.DLL will fail to find the corresponding dependency DLL when executing, and the unlocking will fail.

2.3.2 Writing SeedKey Code

The operation flow in the built-in algorithm editor of TSMaster is shown in Figure 2-14.

[1] Select the function for the SeedKey algorithm.

[2] Open the algorithm checker, which can be used to check whether the algorithm results are correct.

[3] Open the window for writing code.

[4] can be used to export the written code as a DLL file; [4] can be used to export the written code as a DLL file.

[5] Select a desired SeedKey function interface, and support the extension of custom function interfaces.

[6] SeedKey source code editing workspace for decryption algorithm code input and editing.

It is worth noting that TSMaster currently provides the most commonly used algorithmic functions in the form of interfaces, if you use your own special function interface form, you can contact Shanghai TOSUN support, the corresponding interface can be added to the options.

In addition, all interface functions define a return value of type s32. This constraint is added to increase the rigor of the function. In particular, a return value of 0 indicates success, while a return value of any other value has a corresponding error code. Therefore, when editing the code, you need to add the return value in the last line, as shown in Figure 2-15, otherwise the system will consider that the algorithm fails after executing the function and will not execute it later.

3、TSMaster basic diagnostic configuration

The Basic Diagnostics module contains the Basic Diagnostics Service and the Combined Service. For commands executed independently during the diagnostic process, they are in the Basic Diagnostic Service; $34, $36, and $37, which are used for file downloads, are placed in the Combined Service. As shown in Figure 3-1:

1.Add Remove Service command

Mouse over the service command that needs to be added and removed, right-click to expand it, and select whether the service needs to be added and removed, as shown in the following figure:

2.Configure basic diagnostic parameters

Take diagnostic session control as an example, it mainly includes the configuration of the following parameters, as shown in Figure 3-3:

[1] Configure service name: Users can configure a service name that is easy to understand and manage.
[2] Functional identifier or not: Whether or not this diagnostic service uses a functional identifier to send a diagnostic request.
[3] Whether or not there is a reply: Users can configure whether or not to check the contents of the reply for this service.
[4] Select the sub-service type: For example, DiagnosticSessionType in Session Control contains the session type as shown above.
[5] Byte order of parameter list: Motorola and Intel byte order are supported.
[6] Parameter list: Diagnostic service can be sent to the ECU under test with parameters in addition to the diagnostic ID and sub-service type ID, the parameter list contains the parameter list of request and answer frames, and you can choose to add/delete various types of parameters. The parameter list contains a list of parameters for request and answer frames, and you can choose to add/delete various types of parameters.

Among them, different ID parameters can be set according to different service instructions. For example, the diagnostic session type parameter in the diagnostic request session is a mandatory setting, while the parameter list is optional. After modifying the configuration, the sample message of the actual diagnosis message will be displayed at the top of the interface in real time, for example, the request protocol packet is: [10 01 xx xx]: xx means that the parameter is variable, determined according to the actual data filled in by the user; and the answer protocol packet that the diagnostic instrument will receive is [50 01 xx]. As shown in Figure 3-5.

3.Diagnostic service parameters

The Diagnostics module parameters support seven data types. These include: UInt, Int, Single, Double, HexArray, Ascii, and SystemVar. as shown in Figure 3-6.

UInt: Unsigned integer, its data length must be less than 32bits, and is a multiple of 8, can be 8,16,24,32bits.
[2] Int: signed plastic, its data length must be less than 32bits, and is a multiple of 8, can be 8,16,24,32bits.
【3】 Single: Single precision floating point number, data length is fixed 32bits. user input and output floating point data directly.
【4】 Double: Single precision floating point number, data length is fixed 64bits. user input and output floating point data directly.
[5] Hex Array: Hexadecimal array, the length of the data is a multiple of 8. The input data satisfies the 16 prohibited data types.
[6] ASCII: ASCII string, data length is a multiple of 8. The input data is an array of ASCII characters, which is converted to hexadecimal and sent.
【7】 SystemVar: system variable, the data length is a multiple of 8. TSMaster system variable can support various data types such as Uint, Int, Single, Double, UintArray, DoubleArray, HexArray, String, etc. The specific data type is determined by the definition of the system variable. The specific data type is determined by the definition of the system variable itself.

4.Configuring Portfolio Services

The Diagnostic Combo Service ($343637 download file) contains a total of General Configurations, Erase Flash Configurations, Request and Transfer Data Configurations, Transfer Exit Configurations, and Extended and Auxiliary Configurations. Each configuration is described in detail below.

4.1 Generic configuration

The general configuration supports loading the download file format as hex/bin/s19/mot/srec/vdf and so on. You can modify the starting address and data length bytes, adjust the checksum byte order and custom CRC checksum algorithm import and modification, and can download the file contents through the download file viewer. Such as Figure 3-7.

[1] Service name: Configure the name of the service.
[2] File name: load executable file, support hex\bin\s19\mot\srec\vdf...
[3] hex viewer: TSMaster has built-in executable file viewer editor TSHexViewer, users can use this tool to view the details of the loaded Hex file, as shown in Figure 3-8.

[4] Address and length identifiers. Bytes that modify the starting address and data length.
[5] Checksum related configuration. Checksum and byte order support Intel and Motorola. In the process of program download, in order to ensure the integrity of the data, it is necessary to introduce the Checksum algorithm to check the integrity and validity of the data.TSMaster diagnostic module of the conformity service, the introduction of the mainstream CRC algorithm for checking. In the TSMaster diagnostic module, the mainstream CRC algorithm is introduced to check. The selection box is shown in the figure below, and the customized CRC check algorithm can be imported and modified, and the customized algorithm can only be in the form of a DLL file, as shown in Figure 3-9.

After loading the downloaded file and selecting the specified algorithm, the diagnostic module calculates the checksums for the executable file, including the checksums for each data block of the executable file and the checksums for the file as a whole, as shown in Figure 3-10.

The diagnostic module of TSMaster is able to directly parameterize the system variables, and after calculating the checksum value of each data block and file, it will be further converted into system variables automatically, as shown in Figure 3-11.

The generated checks and system variables can be added to the service parameters by the type of system variables. Take the commonly used checking the validity of executable files as an example, configure the following $31 routine control service command, you can realize the checking of the validity of the file, as in Figure 3-12:

4.2 Erasing Flash Configuration

Erase Flash Configuration, which allows you to configure no auto erase, erase Hex address range, and erase the corresponding block before downloading each data block. The Desired Response value is filled in with the actual ECU response. As shown in Figure 3-13.

4.3 Request and Transfer Data Configuration

The data format of the Request Transmit Data command can be modified, for example, from 00 to AA. you can customize the length of the maximum transmit data block, which is 0x202 by default, and the actual transmit layer packet is 514 bytes. As in Figure 3-14.

4.4 Transmission Exit Configuration

Transmission Exit Configuration, you can set the following configuration, as in Figure 3-15:

uncalibrated
Checksum at ECU side ($37 + block checksum)
User-defined
Checksum at PC ($37 + block checksum)
Checksum type selects no checksum or checksum per data block

4.5 Extensions

Extended configuration can add signature files, special CRC algorithms, compared with the custom CRC algorithm import in the General Configuration - Checksum and Related Configurations, this is more flexible to support any format of the file, as shown in Figure 3-16.

4.6 Auxiliary

In the auxiliary, you can divide the downloaded file by the size of the consecutive addresses, for example, divide the data block by 0x1000. This is shown in Figure 3-17.