Development of automotive OBD2 diagnostic program

1. Because TL718 has established the protocols of physical layer, data link layer and part of application layer for you, you only need the text of OBD2 standard application layer protocol, ISO15031-5 or SAE J1979 (the two protocols have the same content). 2. One set of TL718 diagnostic interface or self-built circuit using TL718 chip. 3. One home PC. 4. Install software: Accessport debugging software and VC++ (or VB, BC++, etc.) your favorite development software. 5. One computer (or one car) of car engine that symbolizes OBD2 standard. After preparing the above, you can start your OBD2 standard program development! ! ! TL718 basic information TL718 communicates with MCU, PDA or PC RS232 through a UART serial port. Some new PCs are not equipped with RS232 serial port. You can communicate with TL718 through virtual serial port, such as USB TO RS232, Ethernet TO RS232, or Bluetooth TO RS232, etc. ------- RS232 ------ OBD2 cable ---------- | PC |<----------->| TL718|<------------>| Car diagnostic port| ------- ------ ---------- Regardless of the physical connection, you can use HyperTerminal or serial debugging tools to send and receive characters directly from the keyboard. Before using the serial debugging software, you must first set the correct COM port number and the correct baud rate. Generally, it is 9600 baud rate (PIN6=0V), or 38400 baud rate (PIN6=VCC, PP OC setting default value). The serial port settings are: 8 data bits, parity bit: 0, stop bit 1 bit. If the settings are wrong, you will not be able to communicate with the TL718 normally. All responses from the TL718 end with a carriage return character (0x0D) and an optional line feed character (0x0A). After the connection is correct and the power is turned on. TL718 will drive the test LED light (flashes 3 times) and then send: TL718 starting 〉 If the above information is received correctly, it means the serial port and connection settings are correct. The “〉” symbol in the second line means that TL718 is in idle state and can immediately receive data from RS232. If data is sent to TL718 without receiving the “〉” symbol, data loss may occur. Incorrect response occurs. The command format sent from the PC to TL718 from the serial port: TL718 has 2 formats of commands 1. OBD connection command, which communicates with the vehicle. 2. Internal commands, all starting with AT, do not communicate with the vehicle .

l The ASCII characters sent must end with 0x0d (carriage return), and the characters after the carriage return are discarded by TL718. l The internal command of TL718 starts with "AT" and is followed by visible characters. Invisible characters and spaces are ignored. l OBD commands can only contain hexadecimal ASCII codes (0-9, af, AF), and spaces are ignored. l If the sent command cannot be effectively interpreted by TL718, TL718 will return a "?" to indicate that the sent command is invalid. l When TL718 processes OBD commands, TL718 continuously monitors the RTS pin and RS232 input. If any of these situations occurs, TL718 will interrupt the current OBD command and quickly return to the prompt "〉" to wait for new commands. l Both uppercase and lowercase characters can be received by TL718, and spaces are ignored. For example, the commands "ATZ", "atz", and "at z" are all the same. For example, if we send a reset command to TL718, we just need to send the ASCII characters "ATZ" + 0x0d (carriage return) to the RS232 serial port;

TL718 Starting
>ATZ
ELM327 v1.2
>

Note: The ATZ command returns ELM327 V1.2 in order to use the existing foreign OBD viewing software, so this return information is used.
The "ATI" command is used to return the chip information.

> AND
TL718 v1.0
>

Return the chip number using the "AT@S" command (this number is required for hardware upgrades and warranty services)

>AT@S
CodeNumb:98764323
>
TL718 OBD command If the command you send to TL718 starts with ASCII hexadecimal, TL718 will think it is an OBD command. After receiving it, TL718 will convert the paired ASCII hexadecimal numbers into single byte hexadecimal data and send it to the vehicle computer data bus. OBD commands are actually embedded in data message packets and sent to the data bus. Most standards require that each data message packet contains a three-byte header and a final data check byte. TL718 automatically adds these additional bytes. These default values ​​do not need to be changed for OBD2 diagnostic mode request commands, but if you want to change these header byte values, you can use the internal command "ATSH XXXXXX" to change them. Most OBD commands are only one byte or two bytes long. The maximum length allowed by TL718 is the byte specified by the corresponding standard, and the excess will be discarded. The OBD command sent cannot have a single number. The hexadecimal number must be sent in pairs. For example, it is impossible to send a single "0" for 0, but "00" must be sent. If a single number appears, TL718 thinks that the command format is wrong and will return a "?". Since OBD (automotive diagnostic standard) uses hexadecimal, the data received and sent by TL718 is also in hexadecimal. The decimal value represented by Example 15 is 21; after sending the OBD2 command, TL718 waits to receive the OBD message from the bus. If the address message is received and the address matches, TL718 sends the data from RS232 to the PC. If the message received by TL718 does not match the sent address, the message is ignored. However, the received message packet can also be viewed through the ATBD internal command. If no data matching the address is received until the waiting time (the setting value of the P2MAX ATST command, the default value is 100ms) ends, TL718 returns "NO DATA". If data is received and the address matches, the time is reset and the waiting time continues until the waiting time overflows. OBD2 standard diagnostic mode

To develop an OBD2 diagnostic program, you must master the nine diagnostic modes defined in ISO 15031-5 ( SAE J1979 ). For those who are not good at English, this site has a Chinese description: You can refer to: Modes/Services of OBD System Output Information

• Mode 1: Request current powertrain data
• Mode 2: Request to freeze frame data
• Mode 3: Request emissions related powertrain diagnostic trouble codes
• Mode 4: Clear/reset emission related diagnostic information
• Mode 5: Request oxygen sensor monitoring test results
• Mode 6: Request non-continuous monitoring system OBD test results
• Mode 7: Request continuous monitoring system OBD test results
• Mode 8: Request control of vehicle systems, tests or components
• Mode 9: Read vehicle and calibration identification numbers

Each mode is followed by a parameter identifier (PID) indicating what parameter follows. PID 00 of each mode is a dedicated parameter defined by ISO15 031. Every computer that complies with the standard must support this parameter identifier. It indicates whether the mode supports other PIDs. The format of the OBD2 command for communicating with vehicle data is 1.

The above picture shows the complete format of the OBD2 diagnostic command message packet (most of the manufacturer-specific functions are also in this format). TL718 can automatically set the Header/ID/PCI/CHECKSUM data. For the standard OBD2 diagnostic program, you almost don't need to care about modifying it. If you want to know the relevant content, they are defined in the texts defined in the ISO14230-2, J1850, IS9141-2 and ISO15765-2 data link layer.

TL718 automatically detects the physical connection of the data bus and can automatically search for the current vehicle's protocol between protocols 1-9, and automatically return data after searching. Of course, it can also be manually set to a specific protocol. TL718 does not search for AF protocols because AF protocols do not have a unified ISO15031 application layer protocol like OBD2, so automatic search becomes meaningless.

2. ISO15031 (SAE J1979) is an application layer protocol. Similarly, it does not care about what physical layer protocol is used (TL718 automatically connects). When programming, you only need to send data, receive and process the received data (calculate or display). Therefore, with so many physical connections, sending and receiving data packets specified by a unified standard, our programming and processing becomes relatively simple. Let's discuss OBD2 instructions.

3. Here we only need to care about the 7-byte data (data byte) part of the data message packet.

ISO15031-5 definition:

Byte meaning
1 MODE represents the type of requested data
2 PID parameter identifier
3-7 ISO15031-5 has detailed definitions according to different MODEs and PIDs

As shown in the figure above, connect the line and turn the key to ON, do not start the vehicle. No need to make any settings, as long as you send a command to TL718, TL718 will automatically return the data responded by the vehicle.


Example 1: As shown in the figure: "0100" represents the MODE 01 PID 00 command defined by ISO15031-5.

>01 00
41 00 BF 9F B9 90
The first byte 41 represents Mode 01 (01+40, standard definition)
The second byte 00 represents PID 00
Bytes 3-6 are the data sent back by the vehicle regarding the MODE 01 PID 00 request
Indicates the bit-defined data of other (PID01---PID32) identifiers supported by mode 00 1 represents support 0 represents non-support

Example 2: Request (read) engine water temperature MODE 01 PID 05

We simply send the vehicle 0105 command
>0105
41 05 7B

41 represents MODE 01
05 represents PID 05
7B is the water temperature value The decimal value is (7*16+11)123 The water temperature is 123-40=80 degrees

Example 3: Read engine speed rpm MODE 01 PID 0C

Similarly, just send to TL718: 010C

>01 0C
41 0C 1A F8
1AF8 is a 2-byte hexadecimal value, converted to decimal number is 6904, each grid 1/4 rpm
speed is 6904/4=1726 rpm

Note: The above data conversion and format are detailed in ISO15031-5 Read OBD2 fault code (DTCs Diagnostic Trouble Codes) Reading fault codes is the most commonly used function of the diagnostic instrument. Here is just a brief explanation. For details, please refer to the ISO15 031-5 text. In general, you can directly use MODE 03 to read the current fault code, but here we First use MODE 01 PID 01 to read how many fault codes are currently in the ECU >01 01 41 01 81 07 65 04 > 41 01 It has been explained above that it is a response code to MODE 01 PID 01. 81 represents the current number of fault codes. This decimal value is 129, which does not mean that there are 129 fault codes. 81 Its highest bit MSB represents whether the fault indicator is on, and the lower 7 bits represent the number of fault codes. The hexadecimal algorithm should be 0x81 & 0x7F = 0x01, so it is a fault code. You can also directly subtract 128 from the decimal value , that is, 129-128=1; so 81 means that the fault light is on and there is a fault code. For the data after 81, please refer to the standard text, which has nothing to do with reading the fault code.

In this example, TL718 only returns one line of data, but if another control module also meets the response conditions, it may return multiple lines of information.
For example, if the engine computer and the automatic transmission control computer return information at the same time, there will be 2 lines of information. To confirm which computer returns which line of
information, you must set the three-byte header of the returned OBD message (AT H1 internal command is turned on), and check the third byte (source address) in the message header byte to determine
which computer module returns the message packet. We will not discuss this here, but will discuss multiple message packet data in detail in another chapter.

Now that we have read how many fault codes there are, the next step is to read what the actual fault code is.

Read using OBD2 diagnostic mode MODE 03: Simply send 03

>03 to TL718.

Possible return information data is as follows:
43 01 33 00 00 00 00

Note: If the number of fault codes is more than 3 or multiple computer modules, multiple lines of message packets will be returned.

43 is the response to the MODE 03 request (03+40), and the other 6 bytes are the fault code. 2 bytes represent one fault code.
Here are 3 data representing the fault code: 0133 0000 0000. "0000" is the filler data returned by ISO15031 in this mode
. It is not the actual fault code.

Fault code meaning: ISO definition: The first number of the two-byte fault code (for example 0133) is shown in the following table. Now let's analyze the fault code 0133 above:

The first number "0" is replaced by "P0" according to the table above. 0133 represents the fault code P0133.
Similarly, if D016 is received, "D" is replaced by U1, and the fault code is U1016;
if 1131 is received, the fault code is P1131 after substitution.

Note: The information returned by ISO15765 CAN fault code message package is slightly different from that returned by J11850, ISO9141 and ISO14230.
When writing a program, please note that the second data returned by ISO 15765 represents how many fault codes (DTCs) the computer module has.
For details, please refer to the definition in ISO15031-5. Clear fault code OBD2 diagnostic mode MODE04 is a function to reset the ECU, and also clear the fault code; after execution, the ECU will: 1. Reset the number of fault codes to 0 2. Delete all fault codes 3. Delete the stored freeze frame data 4. Delete all O2 sensor listening test data 5. Delete the data information of mode MODE06 and MODE 07 After the reset, your car may cause abnormal operation for a short time due to the reset of some data. In order to prevent accidental resetting of the ECU, ISO15031-5 requires that all scan tools (diagnostic instruments) must add a "confirmation message" before sending the MODE 04 command. TL718 does not monitor whether the content of the sent information is a reset command. >04 44 > After sending the 04 command, the vehicle ECU receives the attack and will immediately reset the above content and send back a MODE 04 response message 44 (04+40). General process:

Conclusion

• • ISO14230 ISO9141 requires an initialization process before communication and a periodic handshake signal after connection. These are automatically completed by TL718, and the diagnostic procedures of the OBD2 standard do not need to be changed. How to change these parameters:

• • After reading this, you can start your OBD2 development. In fact, the manufacturer's dedicated diagnostic function program is almost as simple. The reason why it is called dedicated is that it does not disclose the application layer protocol. The development process is much more complicated than our OBD2 development. It is about how to use TL718 to read the dedicated diagnostic instructions (that is, the application layer protocol) from the dedicated device. This issue is discussed in the development of a diagnostic instrument with dedicated functions.
  • The other diagnostic modes of OBD2 are not described here, and the diagnostic methods are the same. For details, please refer to ISO15031-5 or SAE J1979.
  • Try it more and you will find that developing diagnostic programs is so easy.