KR102116025B1 - Apparatus and Method Debugging Software of Vehicle's ECU - Google Patents

Abstract

The present invention relates to a software debugging device and method for a vehicle ECU, and the software debugging device for a vehicle ECU according to the present invention is a memory that stores and transmits a debugging packet generated and transmitted during vehicle operation in real time and SPI or I2C communication with the memory. It includes a microcomputer that generates and transmits the debugging packet, and the S / W of the microcomputer is designed so that all functions have unique IDs, and a time count is provided so that each function can be executed while the vehicle is running. When, all types of errors that may occur in the S / W of the microcomputer are defined, the microcomputer includes an error frame storage unit, and the error frame storage unit is executed when all functions of the S / W are executed while the vehicle is running. Each time, the debugging packet is generated, the generated debugging packet is stored in a RAM buffer of a specific size, and when an error is found in the stored debugging packet, the debugging packets stored in the RAM buffer are copied to the memory.

Description

Apparatus and Method Debugging Software of Vehicle's ECU

The present invention relates to a software debugging apparatus and method for a vehicle ECU, and more particularly, to an apparatus and method for efficiently debugging S / W of an ECU mounted on a vehicle.

In the related art, a debugger is used to debug S / W of an ECU mounted on a vehicle, or UART communication is used.

First, the debugging method using a debugger is to connect a hardware device called a debugger (such as JTAG) to the vehicle ECU to monitor all execution processes of the source code by Line by Line, and the debugging method using UART communication is executed by S / W. When an error occurs by inserting a specific code (log) at the location where the error will occur, the error information is output to the UART connected outside the vehicle ECU.

However, the S / W debugging method through the debugger is different from the reality because the S / W is not executed at the actual execution speed in the finished vehicle state, and since the car is fully assembled, the debugger is not disassembled. It is impossible to connect, and most S / W errors that occur in vehicles that have been handed over to consumers occur very intermittently under certain circumstances, and are most often one-time, even if a problem-prone vehicle is arranged and the debugger is connected by disassembling the vehicle. There is a problem that debugging is difficult because the problem situation is not reproduced.

The S / W debugging method through UART communication is superior to the execution method through the debugger, but there is a limit in the amount of information. Also, it is difficult to analyze if the intermittent error is not reproduced by disassembling the car and connecting the UART port. There is a problem.

The present invention was created in view of the above problems, and a small capacity non-volatile memory and an ECU made of a low-performance microprocessor can be used to debug the S / W of the ECU without disassembly while mounted in the vehicle. The aim is to provide a software debugging apparatus and method for a vehicle ECU.

In order to achieve the above object, the software debugging apparatus of the vehicle ECU according to an aspect of the present invention generates the debugging packet through SPI or I2C communication with the memory and the memory for storing the debugging packet generated and transmitted in real time during vehicle operation. The microcomputer S / W of the microcomputer is designed to have a unique ID, and is designed to have a time count to know the time each function is executed while the vehicle is running. All kinds of errors that may occur in S / W are predefined, and the microcomputer includes an error frame storage unit, and the error frame storage unit transmits the debugging packet whenever all functions of the S / W are executed while the vehicle is running. It is characterized in that it generates, stores the generated debugging packet in a RAM buffer of a specific size, and when an error is found in the stored debugging packet, the debugging packets stored in the RAM buffer are copied to the memory.
According to another aspect of the present invention, a software debugging method for a vehicle ECU includes generating a debugging packet when a microcomputer software function included in the vehicle ECU is executed during vehicle driving, and storing the debugging packet generated during vehicle driving in a RAM buffer. When the RAM buffer is FULL, clearing the RAM buffer and sequentially storing debugging packets generated from the first position of the RAM buffer again. Whether there are errors in the debugging packets currently stored in the RAM buffer? Check, and if there is an error, in the step of sequentially copying all debugging packets stored in the RAM buffer to the ROM (E2PROM) included in the vehicle ECU, and when the ROM (E2PROM) is FULL, the ROM ( E2PROM) sequentially overwriting from the first position, and clearing the RAM buffer, and the debugging packet is information about a time count that enables to know the time each function is executed while the vehicle is running. And information on the type of error that has occurred.

delete

According to the present invention, it is possible to efficiently debug the software of the vehicle ECU, and to improve the reliability of the debugging results.

In particular, it is possible to use existing debugging equipment as it is, and has the advantage of improving customer satisfaction through rapid cause analysis.

1 is a block diagram illustrating a software debugging apparatus of a vehicle ECU according to an embodiment of the present invention.
2 is a view for explaining that a packet is stored in the E2PROM.
3 is a flowchart illustrating error frame storage in a software debugging method of a vehicle ECU according to an embodiment of the present invention.
4 is a flow chart for explaining data transmission stored in E2PROM.

Advantages and features of the present invention, and methods for achieving them will be clarified with reference to embodiments described below in detail together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but will be implemented in various different forms, and only the embodiments allow the disclosure of the present invention to be complete, and the ordinary knowledge in the technical field to which the present invention pertains. The scope of the invention is provided to a person having ease so that the invention can be easily understood, and the invention is defined by the description of the claims. Meanwhile, the terms used in the present specification are for explaining the embodiments and are not intended to limit the present invention. In the present specification, the singular form also includes the plural form unless otherwise specified in the phrase. As used herein, "comprises" or "comprising" means the presence of one or more other components, steps, operations and / or elements other than the components, steps, operations and / or elements mentioned, or Addition is not excluded.

The present invention relates to a method for debugging the software of the ECU without separate disassembly while the ECU made of a small capacity non-volatile memory and a low-performance microprocessor is mounted on a vehicle (assembled as a complete vehicle).

On the other hand, in the case of a multimedia system including a high-performance microprocessor and a large memory, a large amount of log information can be stored in a solid state drive (SSD) or NAND flash, and then the log stored through USB can be acquired. In the case of an ECU mounted in a vehicle, since the performance of the microprocessor is not excellent and the non-volatile memory is not embedded in most cases, it is difficult to store information on an error, so the present invention is minimized in consideration of the above. It is created to store information when an error occurs due to the use of memory, to disassemble the vehicle to output the stored information, and to avoid affecting the software execution speed of the ECU when debugging the error.

Hereinafter, a software debugging apparatus for a vehicle ECU according to an embodiment of the present invention will be described with reference to FIGS. 1 and 2. 1 is a block diagram for explaining a software debugging apparatus for a vehicle ECU according to an embodiment of the present invention, and FIG. 2 is a diagram for explaining that a packet is stored in an E2PROM.

As shown in FIG. 1, the software debugging device for the vehicle ECU of the present invention includes a microcomputer 100, an E2PROM (or FRAM, 200), an OBD connector 300, and a CAN device 400.

The E2PROM 200 or FRAM is a non-volatile memory, performs SPI or I2C communication with the low performance microcomputer 100, and stores debugging packets transmitted from the microcomputer 100 in real time.

The maximum capacity of the E2PROM 200 or FRAM does not exceed 1 Mbytes, and the rest of the capacity is used for debugging packet storage, except for the part used for information storage for restoring the final state before and after power removal.

The debugging packet consists of 10 bytes in total as shown in Table 1.

TIMER COUNT (4bytes) Function ID (4 bytes) Status ID (2 bytes)

The S / W of the microcomputer 100 is designed so that every function has a unique 32-bit (32 powers of 2) ID (function ID), and TIMER COUNT or OS TICK COUNT is used so that each function can know the execution time. It is designed to have.

Here, the TIMER COUNT or OS TICK COUNT is composed of a free run timer with an interval of 1 to 5 ms using the hardware TIMER of the microcomputer 100, and the COUNT value is designed to have a 32-bit value (5 ms × 2 of 32 in the 5 ms interval) You can count time as many as ms.)

All states and types of errors (state ID) that may occur in S / W of the microcomputer 100 are defined as follows.

        #define ALL_OK 0

        #define MEMORY_OVERFLOW 1

        #define I2C_ACK_ERROR 2

        #define TIME_OUT 3

Meanwhile, the microcomputer 100 includes an error frame storage unit 110 and a data transmission unit 120.

The error frame storage unit 110 generates the debugging packet when the end of all functions or an error is met (the debugging packet is unconditionally generated whenever an error or non-occurring function is executed).

The error frame storage unit 110 may store a debugging packet in a 10kbytes RAM buffer primarily to prevent this, since a significant speed drop may occur when the generated debugging packet is stored in the E2PROM 200 or FRAM each time the function is executed. do.

Here, although the storage of the generated debugging packet is specified to be stored in a 10kbytes RAM buffer, the storage size of the debugging packet can be adjusted according to hardware resources without being limited thereto.

The error frame storage unit 110 clears the RAM buffer in which debugging packets are stored when the error does not occur while the 10 kbytes of RAM buffer is FULL, and sequentially stores the debugging packets in the RAM buffer from the first position, and the currently stored debugging When an error is found in the packet, all debugging packets stored in the RAM buffer are copied to the E2PROM 200 or FRAM (if 10 kbytes, the sequence of up to 1000 or more functions executed before the time of the error can be determined).

For example, after storing the generated debugging packet in the RAM buffer, the error frame storage unit 110 checks the status ID value of the currently stored debugging packet, and the RAM buffer when the result shows that the status ID value is one of the predefined error values. Copy all debugging packets stored in E2PROM (200) or FRAM.

As shown in FIG. 2, the E2PROM 200 or FRAM is divided into blocks in units of 10 kbytes to sequentially copy (save) debugging packets transmitted from the error frame storage unit 110, thereby generating previously generated debugging packets based on the copied debugging packets. The error condition can also be identified, and if the maximum number of blocks is exceeded, the first block is overwritten.

The data transmission unit 120 extracts data stored in the E2PROM 200 or the FRAM by the error frame storage unit 100, which is not erased even when the power is removed in the following manner so as to be able to grasp the problem during the operation. .

One side of the OBD connector 300 is connected to the CAN network in the vehicle, that is, the CAN equipment 400, and the other side is connected to the microcomputer 100 to support CAN communication of the microcomputer 100.

For example, the OBD connector 300 is connected to the CAN equipment 400, or in the case of a single set, the CAN equipment 400 is directly connected to the CAN LINE of the corresponding set, and a specific command is transmitted from the computer 500 via CAN. If it does, it is transferred to the microcomputer 100.

The data transmission unit 120 transmits all data stored in the E2PROM 200 or FRAM according to a specific command transmitted from the OBD connector 300 using a TP message.

As described above, according to the present invention, by analyzing the data extracted from the E2PROM or FRAM, it is possible to efficiently debug the software of the vehicle ECU by determining the time of the error and by what process the error occurred, and the debugging result. Reliability can be improved. In particular, existing debugging equipment can be used as it is, and customer satisfaction can be improved through rapid cause analysis.

The software debugging apparatus of the vehicle ECU according to an embodiment of the present invention has been described above with reference to FIGS. 1 and 2, and the software of the vehicle ECU according to an embodiment of the present invention will be described below with reference to FIGS. 3 and 4. Describes how to debug. 3 is a flowchart illustrating error frame storage in a software debugging method of a vehicle ECU according to an embodiment of the present invention, and FIG. 4 is a flowchart illustrating data transmission stored in the E2PROM.

As shown in FIG. 3, when the software of the microcomputer 100, that is, the function is executed, a debugging packet is generated (S300).

The generated debugging packet is stored in the RAM buffer, and when the RAM buffer is FULL, the RAM buffer is cleared and sequentially stored from the first position of the RAM buffer (S301).

If there is an error in the debugging packet currently stored in the RAM buffer (S302), and if there is an error as a result of verification, all debugging packets stored in the RAM buffer are sequentially copied to the E2PROM 200, and when the E2PROM is FULL , Sequentially overwrite from the first position (S303), and clear the RAM buffer (S304).

As shown in FIG. 4, it is checked whether or not transmission commands for debugging packets stored in the E2PROM 200 are received (S401), and when a transmission command is received as a result of the verification, all debugging packets stored in the E2PROM 200 Read them and transmit them through a CAN TP message (S402).

The configuration of the present invention has been described in detail with reference to the preferred embodiments and the accompanying drawings, but this is only an example and various modifications are possible within the scope without departing from the technical spirit of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined not only by the scope of the claims described below, but also by the scope and equivalents of the claims.

100: micom 110: error frame storage
120: data transmission unit 200: E2PROM
300: OBD connector 400: CAN equipment

Claims (6)

In the software debugging device of the vehicle ECU,
A memory for storing in real time the debugging packets generated and transmitted during vehicle operation; And
And a microcomputer that generates and transmits the debugging packet through SPI or I2C communication with the memory,
The S / W of the micom is designed so that all functions have a unique ID, and is designed to have a time count to know the time each function is executed while the vehicle is running, and all that can occur in the S / W of the micom. The type of error is predefined,
The microcomputer includes an error frame storage unit,
The error frame storage unit generates the debugging packet whenever all functions of the S / W are executed while the vehicle is running, stores the generated debugging packet in a RAM buffer of a specific size, and an error is found in the stored debugging packet In case, the software debugging device of the vehicle ECU is to copy the debugging packets stored in the RAM buffer to the memory. According to claim 1,
If no error occurs while the RAM buffer is full, the error frame storage unit clears the RAM buffer, stores debugging packets sequentially generated from the beginning, and when an error is found in the stored debugging packet Copying debugging packets currently stored in RAM buffer to the memory
In-vehicle software debugging device. According to claim 1,
The error frame storage unit stores the debugging packet generated in the RAM buffer and checks the status ID value of the stored debugging packet, and when the result of the verification is that the status ID value is one of the predefined errors, all debugging stored in the RAM buffer Copying packets into the memory
In-vehicle software debugging device. According to claim 1,
The micom further includes a data transmission unit,
The data transmission unit transmits all debugging packets stored in the memory using a TP message according to a specific command transmitted through CAN communication.
In-vehicle software debugging device. In the vehicle ECU software debugging method,
Generating a debugging packet when a software function of the microcomputer included in the vehicle ECU is executed while the vehicle is running;
Storing the debugging packet generated while the vehicle is running in a RAM buffer, and when the RAM buffer is FULL, clearing the RAM buffer and sequentially storing the debugging packet generated from the first position of the RAM buffer;
It is checked whether an error exists in the debugging packet currently stored in the RAM buffer, and if an error exists as a result of verification, all debugging packets stored in the RAM buffer are sequentially copied to the ROM (E2PROM) included in the vehicle ECU. To do; And
When the ROM (E2PROM) is FULL, sequentially overwriting from the first position of the ROM (E2PROM), and clearing the RAM buffer,
The debugging packet is a software debugging method of a vehicle ECU that includes information on a time count and information on a type of an error that enables each function to know when the vehicle is running. ◈ Claim 6 was abandoned when payment of the set registration fee was made.◈ The method of claim 5,
Checking whether a transmission command for debugging packets stored in the ROM (E2PROM) has been received; And
As a result of checking, when the transmission command is received, reading all the debugging packets stored in the ROM (E2PROM) and transmitting them through a CAN TP message
Software debugging method of a vehicle ECU further comprising a.

Images