KR20130050501A - In-vehicle debugging system for ecu and method thereof - Google Patents

Abstract

PURPOSE: A vehicle ECU debugging system and a method thereof are provided to accurately analyze software in detail by preventing the reset of an ECU even though the software of the ECU is debugged based on JTAG(Joint Test Action Group)/BDM(Background Debug Mode) protocols. CONSTITUTION: Debuggers(60,70) debug software of an ECU installed in a vehicle. A first converting module(40) is connected with the ECU and converts a first protocol used for communication with the ECU and a second protocol used for a vehicle network. A second converting module(50) is installed in the outside of the vehicle to be connected with the vehicle network, performs communication with the first converting module based on the second protocol, communicates with the debuggers based on the first protocol, and mutually converts the first and the second protocols. [Reference numerals] (40) First converting module; (50) Second converting module; (60) MCU debugger; (70) DSP debugger

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an ECU debugging system,

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a technology for debugging ECU software of a vehicle, and more particularly, to a vehicular ECU debugging system and method for analyzing software of an ECU using a JTAG / BDM protocol will be.

An electronic control unit (ECU) is an electronic control unit that controls the states of an automobile engine, an automatic transmission, a TCU (Transmission Control Unit), an EPS (Electric Power Steering), and an ABS (Anti-lock Brake System).

The ECU is used to increase the safety of the vehicle, so if there is an error or a bug in the ECU, the safety of the driver and the passenger may be deteriorated. Therefore, it is necessary to test the ECU to find out what kind of operation is indicated when an error code is received, whether the ECU outputs a desired output value, whether the desired network design is executed or the like. And, if the test results are not satisfactory, it is necessary to perform an update such as a change operation or reprogramming for the mounted application program.

These ECUs are connected to a PC for external program development and are debugged. Most of the ECUs currently in use support JTAG / BDM (Joint Test Action Group / Background Debug Mode) ports to access CPU internal resources have. However, JTAG / BDM ports can not be used in existing vehicle environments. This is because the engine room, which is the location where the ECU for the vehicle is mounted in the vehicle environment, is an environment with a lot of external noise, and the JTAG / BDM communication line has a reset function so that the ECU can be reset by the external noise.

Accordingly, in the development of ECU, communication resources such as CCP / XCP (Common Communication Protocol) are used to access CPU internal resources. When the CCP / XCP protocol is used instead of the communication protocol supported by the CPU, it may be difficult to develop an optimum program because it is difficult to provide an optimal environment for developing a program than using the JATG / BDM protocol .

In view of the above, it is an object of the present invention to provide an ECU debugging system for a vehicle and a method thereof, which enable debugging of an ECU using a JTAG / BDM protocol to enable accurate debugging, thereby facilitating optimum program development .

In order to achieve the above object, in one aspect, the present invention provides a debugging apparatus comprising: a debugger for debugging software of an ECU mounted on a vehicle;

A first conversion module connected to the ECU, for converting a first protocol used for communication with the ECU and a second protocol used for the vehicle network; And

Is installed outside the vehicle to be connected to the vehicle network, and communicates with the first conversion module using the second protocol, and communicates with the debugger using the first protocol, the second protocol and the first It provides a vehicle ECU debugging system comprising; a second conversion module for converting one protocol to each other.

In another aspect, the present invention includes the steps of: converting a protocol of data delivered from a vehicle-mounted ECU from a first protocol to a second protocol used in a vehicular network; Transferring the data out of the vehicle through the second protocol; Converting a protocol of the data from a second protocol to a first protocol; Debugging data communicated using the first protocol; Converting a protocol of update data generated as a result of the debugging from the first protocol to the second protocol; Transferring the update data to the interior of the vehicle using the second protocol; And converting the protocol of the update data from the second protocol to the first protocol and delivering the protocol to the ECU.

As described above, according to the present invention, it is possible to analyze the software in detail and precisely by preventing the ECU from being reset even if the software of the ECU is debugged using the JTAG / BDM protocol in an actual vehicle environment. In this way, accurate debugging is possible in an actual vehicle environment, so that optimal software development is possible and the development period of the software can be shortened.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a configuration diagram of a vehicle ECU debugging system according to an embodiment of the present invention;
2 is a flowchart illustrating a process of debugging software of an ECU in the vehicle ECU debugging system of FIG.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are used to refer to the same components as much as possible even if displayed on different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

In addition, in describing the component of this invention, terms, such as 1st, 2nd, A, B, (a), (b), can be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. When a component is described as being "connected", "coupled", or "connected" to another component, the component may be directly connected to or connected to the other component, It should be understood that an element may be "connected," "coupled," or "connected."

FIG. 1 is a configuration diagram showing a vehicle ECU debugging system according to an embodiment of the present invention.

The present invention relates to an ECU (10) debugging system for debugging software installed in an ECU (10), in which software installed in the ECU (10) can be executed and analyzed line by line, .

In general, the ECU 10 for a vehicle includes an MCU 20 (Micro Control Unit) and a DSP 30 (Dynamic Shift Program). Here, the MCU 20 is in charge of control and arithmetic operations in the ECU 10, and has a high-speed, high-performance processing capability and a sufficient capacity memory so as to reduce an accidental injury and prevent an accident.

The DSP 30 is a device that automatically adjusts the shift timing according to the driving preference of the driver or the road conditions, and is also referred to as DRP (Dynamic Ranging Program). The DSP 30 checks the vehicle speed, the engine speed, the accelerator opening degree, the pedaling speed, etc. to determine the driving preference of the driver, checks the road surface condition using the sensor, .

The ECU 10 including the MCU 20 and the DSP 30 is mounted inside the vehicle, for example, in an engine room or a bumper. The MCU 20 and the DSP 30 each have a JTAG / BDM (Joint Test Action Group / Background Debug Mode) port.

The JTAG / BDM protocol is generally used for embedded system development, testing the connection state between devices, and checking and controlling the inside of the chip. Accordingly, in the present invention, the internal resources of the MCU 20 and the DSP 30 can be accessed and tested using the JTAG / BDM protocol.

The ECU 10 debugging system according to the present invention includes a first conversion module 40 for connecting the ECU 10 mounted on the vehicle to a vehicle network, a debugger for debugging and updating the software of the ECU 10, And a second conversion module 50 connecting the first conversion module 40 and the debugger.

The first conversion module 40 connects the ECU 10 and the second conversion module 50 so that the ECU 10 is connected to the programming device. The first conversion module 40 has a first port connected to the JTAG / BDM port of the MCU 20 and a second port connected to the JTAG / BDM port of the DSP 30. Accordingly, the first port and the second port are both JTAG / BDM ports, and the MCU 20 and the DSP 30 can communicate with the first conversion module 40 using the JTAG / BDM protocol, respectively.

Also, the first conversion module 40 includes a third port connected to the second conversion module 50, and the third port is Ethernet or FlexRay. Accordingly, the first conversion module 40 and the second conversion module 50 can communicate using Ethernet or FlexRay, which is a high-speed communication line for a vehicle.

Here, Ethernet is a network protocol for supporting a LAN (Local Area Network), and FlexRay is a vehicle-only protocol.

FlexRay is based on a time-triggered communication system with an efficient and fast data transfer rate, and the amount of data exchanged between the control units mounted on the vehicle has increased, so that the time determina- tion of message transmission and the error tolerance as the demand related to error tolerance increased.

The first conversion module 40 includes a first port connected to the MCU 20, a second port connected to the DSP 30, and a third port connected to the second conversion module 50. The first port and the second port communicate with the MCU 20 and the DSP 30 using the JTAG / BDM protocol, and the third port can communicate using the Ethernet or Flexray protocol.

The first conversion module 40 may convert the JTAG / BDM protocol to the Ethernet or Flexray protocol or convert the Ethernet or Flexray protocol to the JTAG / BDM protocol according to the data transmission direction. When the data is transferred from the MCU 20 or the DSP 30 to the debugger, the first conversion module 40 converts the protocol of the data into the Ethernet or Flexray protocol of the JTAG / BDM protocol, and the data is transferred from the debugger to the MCU 20 or the DSP 30, the first conversion module 40 converts the Ethernet or Flexray protocol to the JTAG / BDM protocol.

The first conversion module 40 may be configured by an MCU 20 (Micro Controller Unit) or an FPGA (Field Programmable Gate Array). The detailed conversion logic is implemented by software or RTL (Register Transfer Level) Can be performed.

The first conversion module 40 is integrally mounted on the board of the ECU 10 installed in the vehicle and extends to the driver's seat where the communication line of Ethernet or Flexray connected to the first conversion module 40 is developed.

Accordingly, since the JTAG / BDM communication line connecting the MCU 20 and the DSP 30 and the first conversion module 40 is formed on the board of the ECU 10 in a short time, the JTAG / It is possible to prevent a reset phenomenon that occurs while passing through the room.

The second conversion module 50 includes a third port connected to the first conversion module 40 via an Ethernet or Flexray communication line and first and second ports connected to the debugger. The first port and the second port are connected to the MCU debugger 60 and the DSP debugger 70 respectively and can communicate with the MCU debugger 60 and the DSP debugger 70 using the JTAG / BDM protocol.

The second conversion module 50 is connected to a communication line using the JTAG / BDM protocol between the first port and the second port, and the third port is connected with the communication line using the Ethernet or Flexray protocol, 50) converts between Ethernet or Flexray protocol and JTAG / BDM protocol.

When the data is transferred from the MCU 20 or the DSP 30 to the debugger, the second conversion module 50 converts the protocol of the data from the Ethernet or Flexray protocol to the JTAG / BDM protocol and the data is transferred from the debugger to the MCU 20 or DSP 30, the second conversion module 50 converts the JTAG / BDM protocol to the Ethernet or Flexray protocol.

The JTAG / BDM communication line connecting the second conversion module 50 to the MCU debugger 60 and the DSP debugger 70 is exposed to the outside unlike the JTAG / BDM communication line of the first conversion module 40, It is installed far away from the room and does not have to be long, so there is no concern for resetting.

The debugger analyzes the software of the ECU 10 to analyze and correct the cause of the malfunction, and updates it. The debugger may comprise an MCU debugger 60 for debugging software associated with the MCU 20 and a DSP debugger 70 for debugging software associated with the DSP 30. [

The MCU debugger 60 and the DSP debugger 70 are connected to the terminal 80. The terminal 80 controls the operation of the MCU debugger 60 and the DSP debugger 70 and the MCU debugger 60 and the DSP debugger 70, The DSP debugger 70 can display the analyzed result.

The MCU debugger 60 and the DSP debugger 70 perform software reprogramming, data calibration, data measurement, and software flow control.

Software reprogramming refers to rewriting software installed in the MCU 20 and the DSP 30, and data calibration is a process of tuning software by modifying internal parameters of the software. The data measurement is a process of analyzing the operation of the software by monitoring the change of the internal variable values of the software in real time.

Software flow control may include flow control using breakpoints and code line unit flow control.

Flow control using breakpoints allows you to observe the internal situation by stopping the operation of the software when a breakpoint is reached when a breakpoint is set in a part where debugging is desired to be performed in hardware and software, respectively. When the breakpoint is used, breakpoints can be set in the exception processing vector that is desired to be debugged, so that the cause of the exception can be analyzed.

The code line unit flow control can be executed in the unit of the code line of the software, so that it can analyze in detail the code line unit how the software operates. Thus, the change of the memory value according to the code line unit of the software can be examined. More specifically, you can run and analyze software in assembly-level as well as code-line units.

The MCU debugger 60 and the DSP debugger 70 are connected to the MCU 20 and the DSP 30 by debugging the software installed in the MCU 20 and the DSP 30 in the MCU debugger 60 and the DSP debugger 70, And data required for updating such as modified parameters, internal variables or reprogrammed software are supplied to the MCU 20 and the DSP (DSP) 70 in accordance with the analysis results in the MCU debugger 60 and the DSP debugger 70. [ 30).

Accordingly, when the software from the MCU 20 and the DSP 30 is transferred to the MCU debugger 60 and the DSP debugger 70, the first conversion module 40 converts the protocol from JTAG / BDM protocol to Ethernet or Flexray Protocol, and the second conversion module 50 converts the protocol from the Ethernet or Flexray protocol to the JTAG / BDM protocol.

On the other hand, when data necessary for updating is transferred from the MCU debugger 60 and the DSP debugger 70 to the MCU 20 or the DSP 30, the second conversion module 50 converts the JTAG / BDM protocol to Ethernet or Flexray protocol And the first conversion module 40 converts the Ethernet or Flexray protocol into the JTAG / BDM protocol.

The MCU debugger 60 and the DSP debugger 70 each have a memory, and the memory of the MCU 20 and the DSP 30 is stored in each memory. Accordingly, the MCU debugger 60 and the DSP debugger 70 compare the data provided by the software development apparatus with the data stored in each memory when updating is required, such as when the software is reprogrammed or the internal parameters are modified, Memory can be updated.

The MCU debugger 60 and the DSP debugger 70 each have a USB port and the MCU debugger 60 and the DSP debugger 70 respectively have a USB port. Accordingly, the terminal 80 is connected to the MCU debugger 60 and the DSP debugger 70 via a USB communication line.

2 is a flowchart showing a process of debugging the ECU 10 for a vehicle in the ECU 10 program development system according to the present invention.

The operator or automatically instructs the operation of the MCU debugger 60 and the DSP debugger 70 via the terminal 80 and enters settings necessary for software reprogramming, data calibration, data measurement, and / or software flow control. For example, a break point is set through the terminal 80 or software is executed for each code line to be analyzed.

Data of the software is transmitted from the MCU 20 and the DSP 30 to the MCU debugger 60 and the DSP debugger 70. At this time, the first conversion module 40 receives the data from the MCU 20 and the DSP 30 The second conversion module 50 converts the JTAG / BDM protocol used in the communication with the JTAG / BDM protocol to Ethernet or Flexray protocol and transfers the data to the second conversion module 50 (S200) BDM protocol and transfers the data to the MCU debugger 60 and the DSP debugger 70 (S210).

The MCU debugger 60 and the DSP debugger 70 reprogram the software of the MCU 20 and the DSP 30 and modify the internal parameters or monitor the change of the internal variable values, Line or assembly level unit (S220). The MCU debugger 60 and the DSP debugger 70 compare the debugging result with the MCU 20 and DSP 30 software stored in each memory and when the software of the MCU 20 and the DSP 30 needs to be updated, And transfers the data necessary for the update to the MCU 20 and the DSP 30 through the second conversion module 50 and the first conversion module 40. [

That is, the MCU debugger 60 and the DSP debugger 70 transfer the data necessary for the update to the second conversion module 50, and the second conversion module 50 transfers the data required for the update to the MCU debugger 60 and the DSP debugger 70 The JTAG / BDM protocol used for communication is converted into Ethernet or Flexray protocol and transmitted to the first conversion module 40 (S240). Then, the first conversion module 40 converts the Ethernet or Flexray protocol to the JTAG / BDM protocol so that the data is transferred to the MCU 20 and the DSP 30 (S250). The software of the MCU 20 and the DSP 30 is updated using the update data transmitted to the MCU 20 and the DSP 30 (S260).

As described above, in the vehicle ECU 10 debugging system, the JTAG / BDM communication line is installed on the board of the ECU 10 so that the JTAG / BDM communication line does not pass through a place with a high noise such as an engine room, A communication line such as Ethernet and Flexray is used in a place where noise outside the board of the ECU 10 is severe by using the first conversion module 40 and the second conversion module 50. [ Accordingly, even if the software of the ECU 10 is debugged using the JTAG / BDM protocol in the actual vehicle environment, the ECU 10 can be prevented from being reset, thereby making it possible to analyze the software in detail and accurately. In this way, accurate debugging is possible in an actual vehicle environment, and the development period of the software can be shortened.

While the present invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. In other words, within the scope of the present invention, all of the components may be selectively operated in combination with one or more. In addition, although all of the components may be implemented as one independent hardware, some or all of the components may be selectively combined to perform a part or all of the functions in one or a plurality of hardware. As shown in FIG. Codes and code segments constituting the computer program may be easily inferred by those skilled in the art. Such a computer program may be stored in a computer readable storage medium and read and executed by a computer, thereby implementing embodiments of the present invention. As a storage medium of the computer program, a magnetic recording medium, an optical recording medium, or the like can be included.

It is also to be understood that the terms such as " comprises, "" comprising," or "having ", as used herein, mean that a component can be implanted unless specifically stated to the contrary. But should be construed as including other elements. All terms, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs, unless otherwise defined. Commonly used terms, such as predefined terms, should be interpreted to be consistent with the contextual meanings of the related art, and are not to be construed as ideal or overly formal, unless expressly defined to the contrary.

The above description is merely illustrative of the technical idea of the present invention, and those skilled in the art to which the present invention pertains may make various modifications and changes without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be construed according to the following claims, and all technical ideas falling within the scope of the same shall be construed as falling within the scope of the present invention.

Claims (9)

A debugger for debugging software of an ECU mounted on a vehicle;
A first conversion module connected to the ECU, for converting a first protocol used for communication with the ECU and a second protocol used for the vehicle network; And
Wherein the first protocol is communicated to the first conversion module using the second protocol and the debugger is communicated using the first protocol and the second protocol and the second protocol are communicated to the vehicle network, 1 protocol to the first conversion module. The method of claim 1,
Wherein the first protocol is a JTAG / BDM protocol and the second protocol is an Ethernet or FlexRay protocol. The method of claim 1,
The first conversion module is a vehicle ECU debugging system installed on the board of the ECU. The method of claim 2,
Wherein the first conversion module converts the JTAG / BDM protocol to the Ethernet or FlexRay protocol when data is transmitted from the ECU to the debugger, and the second conversion module converts the Ethernet or FlexRay protocol into the JTAG / BDM Vehicle ECU debugging system. The method of claim 2,
Wherein the second conversion module converts the JTAG / BDM protocol to the Ethernet or FlexRay protocol when data for software update is transmitted from the debugger to the ECU, and the first conversion module transmits the Ethernet or FlexRay protocol To the JTAG / BDM protocol. The method of claim 1,
In the debugger, software for reprogramming the software of the ECU, data calibration for modifying internal parameters, data measurement for monitoring internal variable values, and setting breakpoints to control the execution of the software or analyze the software on a code line basis. Automotive ECU debugging system for performing at least one of flow control. Converting a protocol of data transferred from an ECU mounted in the vehicle from a first protocol to a second protocol used in a car network;
Transferring the data out of the vehicle through the second protocol;
Converting a protocol of the data from a second protocol to a first protocol;
Debugging the data transferred using the first protocol;
Converting a protocol of update data generated as a result of the debugging from the first protocol to the second protocol;
Transferring the update data to the interior of the vehicle using the second protocol; And
And converting the protocol of the update data from the second protocol to the first protocol and delivering the protocol to the ECU. The method of claim 7, wherein
Wherein the first protocol is a JTAG / BDM protocol and the second protocol is an Ethernet or FlexRay protocol. The method of claim 7, wherein
The debugging may include reprogramming the software of the ECU, data calibration for modifying internal parameters, data measurement for monitoring internal variable values, and setting breakpoints to control the execution of the software or to execute software on a code line basis. And performing at least one of analyzing software flow control.

Images