KR20140140790A

KR20140140790A - Target agent method for monitoring embedded system software based on rtos

Info

Publication number: KR20140140790A
Application number: KR1020130061604A
Authority: KR
Inventors: 하대연; 황성연
Original assignee: 엠디에스테크놀로지 주식회사
Priority date: 2013-05-30
Filing date: 2013-05-30
Publication date: 2014-12-10

Abstract

The present invention relates to an operating method of a target agent for monitoring embedded system software based on RTOS. More specifically, in the present invention, an operating method of a target agent for monitoring embedded system software based on RTOS performs services like a remote debugging service which performs a source level debugging of programs in a host system wherein the programs are performed in the target system; a remote shell service which loads and performs programs; and a remote resource monitor service which collects and has data and delivers the data to the host system.

Description

{TARGET AGENT METHOD FOR MONITORING EMBEDDED SYSTEM SOFTWARE BASED ON RTOS}

The present invention relates to a method of operating a target agent for RTOS-based embedded system software monitoring, and more particularly, to a remote agent debugging service for processing a remote debugging service of a host not dependent on a real- The present invention relates to a method for operating a target agent for debugging an embedded system software based on a real-time operating system that provides a host system with a remote resource monitor service that collects data and transmits the collected data to a host system.

Recently, the prominent phenomenon with the explosion of the Internet has been that not only computers but also various information devices have started to be directly connected to the Internet. Internet access of household appliances such as a refrigerator and a microwave oven as well as a telephone, a TV, a PDA and a machine tool are being discussed. A feature of these devices is that it implements several real-time applications with a built-in microprocessor.

The development of real-time application programs in the past developed entirely from the device control to the user interface using the assembly language, without the support of the operating system (OS) (ROM) and a host - target serial / Ethernet (Ethernet) loaded on the target system.

However, as the functions required for applications such as the Internet access function become more complicated and diverse, it becomes impossible to develop them without the support of the real-time operating system. In addition, it is common to write an application program using a high - level language. Embedded system is mainly developed in a host computer because resources such as memory and disk are limited, A cross development method is often used in which an execution code of a program is generated. Support for various development tools running on the host computer is essential for cross-development of real-time applications using high-level languages. This includes the debugger, the interactive shell, and the resource monitor.

Debugger is one of the most important tools. In order to realize remote debugging that performs source-level debugging of a program executed in the target system, there must be a task in the target system to support it. (Debug Agent).

A protocol for remote debugging exists between a symbolic debugger executed on the host system and a debug agent on the target system, and is used to exchange debugging commands and various debugging information.

FIG. 1 is a schematic diagram showing a debugging environment according to the related art, which will be described in detail as follows.

In the conventional technology, a remote debugger 101 exists on the host OS 102, and a monitor program 103 stored in a ROM or a flash memory of the target system is loaded. These monitor programs 103 are stored in the host system 102 via a serial or Ethernet 105 Handles the remote debugging service. Conventional technology is a technique required to develop a real-time embedded software 104 of a target without the help of a real-time operating system. Therefore, the protocol between them is mainly a simple message for debugging, and the debug agent itself is also loaded on the ROM or monitor 103 of the target board, so that it is dependent on the target board. In addition, since the internal code is often written in assembly language because it implements only a simple function, there is a problem that a new board must be newly transferred on a target board when a new board is created.

Since a conventional debug agent device having a general client / server type debugging environment is limited to a case where the client is mainly a remote debugger, a client can not only use a debugger but also a service for clients having other functions such as a remote shell or a remote resource monitor Could not support.

SUMMARY OF THE INVENTION The present invention has been made in view of the above problems, and it is an object of the present invention to provide a remote shell service for processing a remote debugging service of a host not dependent on a real-time operating system loaded on a target system, And a remote resource monitor service for delivering collected data to a host system. The object of the present invention is to provide a method of operating a target agent for monitoring an RTOS-based embedded system software that performs a service according to a type of a service requested by the host.

According to an aspect of the present invention, there is provided a remote debugging service for performing a source level debugging of a program executed in a target system in a host system, a remote debugging service for loading and executing a program, The present invention relates to a method of operating a target agent for monitoring an RTOS-based embedded system software, the method comprising the steps of: (a) providing a remote shell service for collecting data and transmitting collected data to a host system, Receiving a service request of the cross development tools and determining whether the service is a type of service request; (b) performing a corresponding service according to the type of service determined in the step (a); And (c) transmitting the service result obtained in the step (b) to the host system. Wherein the step (b) comprises the steps of: (b-1) processing the request when the request determined in the step (a) relates to setting and canceling of a breakpoint, A breakpoint management step of managing the breakpoints as a double linked list to process the breakpoints; (b-2) if the request determined in the step (a) is a function call in the real-time operating system of the target system, generating a function to perform a function requested by the tool of the host system, Management step; (b-3) if the request determined in the step (a) is a function call in the context of the debug agent, calling a function on the target system, but not creating a task, step; (b-4) If the request determined in the step (a) relates to a virtual input / output, data is written to a virtual input / output channel of the target system, and an output value from the target system is transmitted to a virtual terminal A virtual input / output management step of performing a function of transmitting the input / And (b-5) an end notification step of informing the host system of the end of the context when an event notifying of termination of the task occurs in the real-time operating system when processing the request determined in step (a); And a control unit.

If a kernel function call is made from the debug agent, a kernel function pointer in the debug agent is initialized, a connection library is initialized so that a remote debugger of the host system can access the debug agent, And activating the kernel task as one kernel task of the operating system, and then performing the step (a).

The step (b) includes the steps of: (b-6) managing the context on the target system, such as creating, destroying, resuming, and stopping the context if the request determined in step (a) A context management step; (b-7) a register management function for obtaining a register value of the target system and setting a new value if the request determined in the step (a) relates to reading and writing the value of the register, ; (b-8) If the request determined in the step (a) is related to memory processing, it performs functions such as a checksum calculation, a memory read / write, a memory fill, a memory protection, A memory management step; (b-9) an event management step of adding and deleting an event point if the request determined in step (a) is an event setting and cancellation; And (b-10) an exceptional state notification step of notifying the host system of an exceptional state when an exception occurs in the real-time operating system when processing the request determined in the step (a); Is further included.

According to the present invention, only a service for a remote debugger of a host system is provided in comparison with a ROM monitor. According to the present invention, an interactive shell of a host system, a remote debugger, a resource monitor It is possible to minimize the overhead of the target system by minimizing the communication protocol with the host system, and to provide a real-time operating system that resides in the target system By using a system-independent interface, it is independent of the operating system of the target system, so that it can be easily ported to a real-time operating system.

1 is a schematic diagram showing a debugging environment according to the prior art;
2 is a schematic diagram showing a remote debugging environment of a real-time operating system-based embedded system software using a debug agent according to the present invention;
3 is a block diagram of an internal module of the debug agent shown in FIG.
FIG. 4 is a flowchart illustrating a process in which a debug agent of a target system processes a request service sent through a remote procedure call by tools of a host system according to the present invention.
5 is a flowchart illustrating a process in which each device of the debug agent processes requests sent from the main device to each service processing device shown in FIG.
FIG. 6 is a flowchart illustrating a process in which the debug agent shown in FIG. 3 is initialized as a kernel task of a real-time operating system on a target board.
FIG. 7 is an exemplary view of a table structure showing a protocol for debugging between the host system shown in FIG. 2 and the debug agent of the target system; FIG.

Specific features and advantages of the present invention will become more apparent from the following detailed description based on the accompanying drawings. It is to be noted that the detailed description of known functions and constructions related to the present invention is omitted when it is determined that the gist of the present invention may be unnecessarily blurred.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will now be described in detail with reference to the accompanying drawings.

A method of operating a target agent for monitoring RTOS-based embedded system software according to the present invention will now be described with reference to FIG. 2 to FIG.

FIG. 2 is a schematic diagram showing a remote debugging environment of a real-time operating system-based embedded system software using a debug agent according to the present invention.

The tasks performed by the debug agent 204 include, but are not limited to, setting / canceling of breakpoints, memory of the target system, inquiry and modification of contents of registers, remote debugging function for controlling execution of the target program, Event notification to the host system (exception status, task termination), and virtual I / O functions.

Since the remote debugger 201 in the host system operates on a general-purpose operating system and can perform application-level remote procedure calls (RPC), host system tools such as the debugger 201 can perform a remote procedure call When calling the function, make sure that the name of the protocol you want to request, the desired function call, and the input / output data required for the function call are called as parameters. Tools such as the debugger 201 communicate with the debug agent 204 through a remote procedure call interface provided by the host system to perform a desired function, and receive the result from the target.

A protocol may be defined for the interface between the debugger 201 and the debug agent 204. The debugger 201 and the debug agent 204 communicate using a debug protocol, It is an application level protocol that is designed to be independent of the target system and the operating system of the host system and minimizes the resource usage of the target system.

3 is an internal module configuration diagram of the debug agent shown in FIG. 2 for supporting cross-over development of embedded system software executed on a real-time operating system of a target system.

This debug agent processes the protocol messages requested from the host, including requests from development tools (debuggers, interactive shells, resource monitors) in the host, create / destroy / restart contexts on the target system where the host is located Request from the target system, execution / termination of the object module loaded in the event / target memory, function call in the object code loaded on the target system, state information of the target memory / register requested by the tools on the host, And a request for output to the virtual input / output so that the output value can be output to the terminal on the host when the console is not present. The debug agent includes a main module 301, a context manager 302, a function call manager 303, a direct call manager 304, A virtual I / O manager 306, a breakpoint manager 307, an exception notification device 308, an end notification device 309, an exit notification device 309, Notifier, a memory manager 310, a register manager 311, and a back-end management device 312. [

This will be described in detail as follows.

First, the main device 301 accepts a service request from the host system, determines the type of the request, and manages the device.

The stop point management device 307 processes the request when the determined request is related to the setting and release of the stop point and controls the stop point of the host system to process the stop point set by the debugger 201 of the host system. Are managed as a Doubly Linked List.

In addition, the context management device 302 processes a request when the determined request is a request related to a context, and manages a context on a target system such as creating, destroying, resuming, and stopping a new context to provide.

The register management unit 311 processes the request when the determined request relates to reading and writing the value of the register, and acquires a register value of the target system and sets a new value. Lt; / RTI >

When the determined request is a memory process, the memory management device 310 processes the request and performs a checksum calculation on the memory value, a memory read / write, a memory fill, a memory protection, .

When the determined request is a function call in the real-time operating system of the target system, the function call management device 303 processes the request, generates and executes a task that performs a function requested by the tool of the host system Function.

In addition, the direct call management device 304 processes the request when the determined request is a function call in the context of the debug agent, calls a function on the target system but does not create a task, Lt; / RTI > context.

In addition, when the determined request is event setting and cancellation, the event management device 305 processes the request and adds and deletes event points.

The virtual I / O manager 306 also writes data in the virtual I / O channel of the target system to process the request when the determined request is for virtual I / O, To the virtual terminal provided by the host system tool.

In addition, the exception notification notifying unit 308 processes an exception situation in the real-time operating system when processing the determined request, and notifies the host system of the exception.

In addition, the end notifying device 309 processes an event notifying the end of the task in the real-time operating system when processing the determined request, and notifies the host system of the end of the context.

Also, the back-end device 312 is composed of a packet driver and an interpreter so that a remote procedure function call can be made in the host system, and packets are exchanged through a physical network. Since the target system has limited available resources, the present embodiment is designed to minimize the memory requirement of the target system by using a light packet analyzer.

FIG. 4 is a flowchart illustrating a process in which the debug agent 204 of the target system processes a request service sent through a remote procedure call by the tools of the host system according to the present invention.

First, in step S401, the initialized main device 301 waits for a service request from the host system, and then, in step S402, determines whether or not there is a service request from the host system.

As a result of the determination in step S402, if there is a service request, after recognizing the request from the host system in step S403, the type of the service request is determined in step S404. In step S405, , And in step S406, it is determined whether or not an exception condition has occurred in the target system.

As a result of the determination in step S406, if an exception occurs, in step S407, it is instructed to notify the exceptional state notification device 308 to the host system, and the process returns to step S401.

As a result of the determination in step S406, if no exception occurs, it is determined in step S408 if the job is completed.

As a result of the determination in step S408, if the job is not completed, the process returns to step S401. If the job is completed, in step S409, after instructing the end notification device 409 to inform the host system, The process returns to S401.

FIG. 5 is a flowchart illustrating a process in which each device of the debug agent processes requests sent from the main device 301 shown in FIG. 3 to each service processing device.

First, in step S501, after a request message is received from the main device 301, necessary internal processing is performed in step S502. In step S503, a kernel in the real-time operating system loaded on the target system during the internal processing (Kernel) function call is present.

As a result of the determination in step S503, if there is a kernel function call, the kernel function call is made in step S504, the remaining task for processing the requested service is processed in step S505, Whether or not it exists.

As a result of the determination in step S506, if there is an exception condition, the exception condition notification device 308 is notified of the exception condition in step S507, and then the process returns to the waiting condition.

If it is determined in step S506 that no exception condition exists, it is determined in step S508 whether or not the task is in an end state.

As a result of the determination in step S508, if it is determined to be the end state, in step S509, the end of the task is notified to the task end notification device 309 and then returns to the standby state. To the main device 301, and then ends the process.

If it is determined in step S503 that there is no kernel function call, the flow advances to step S506.

FIG. 6 is a flowchart illustrating a process in which the debug agent 204 shown in FIG. 3 is initialized as a kernel task of a real-time operating system on a target system board.

First, in step S601, the kernel function pointer in the debug agent 204 is initialized to interface with the kernel. In step S602, the service is initialized. In step S603, the remote debugger 201 of the host system And initializes a connection library so that the debug agent 204 can access the target system.

Subsequently, in step S604, the memory library for memory reference is initialized. After the initialization process in the debug agent 204 ends in step S605, the devices are initialized so that the defined device can be used. In step S606, Initialize the debug agent.

Subsequently, in step S607, the debug agent 204 is activated as one kernel task of the lower real-time operating system. Then, in step S608, control is passed to the main device 301 at the start of the service, do.

FIG. 7 illustrates an example of a table structure showing a protocol for debugging between the host system shown in FIG. 2 and the debug agent 204 of the target system, which will be described in detail as follows.

In this embodiment, the protocol between the host system and the target system is composed of a total of 25 protocols, namely, seven types of context processing, event processing, memory processing, register processing, virtual input / output, kernel function invocation and direct invocation in the context of the debug agent , Each of which is designed from 0 to 24 so that it can be passed as an argument when calling a function on the host.

The protocol is used to determine the type of protocol in the main device 302 shown in FIG. 3, and recognizes the corresponding device to be monitored and transmits the recognized value to the corresponding device.

While the present invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. It will be appreciated by those skilled in the art that numerous changes and modifications may be made without departing from the invention. Accordingly, all such appropriate modifications and changes, and equivalents thereof, should be regarded as within the scope of the present invention.

Claims

Remote Debugging Service for Source Level Debugging in the Host System, Remote Shell Service for Loading and Executing the Program, Data Collecting and Loading And transferring the collected data to the host system. In the method of operating the target agent for monitoring the RTOS-based embedded system software,
(a) receiving a service request of cross development tools in the host system, and determining whether the service is a type of service request;
(b) performing a corresponding service according to the type of service determined in the step (a); And
(c) transmitting the service result obtained in the step (b) to the host system; , &Lt; / RTI &
The step (b)
(b-1) when the request determined in the step (a) is related to setting and canceling of a stop point, processing the request, and in order to process the stop point set by the debugger of the host system, A stop point management step managed by a list (Doubly Linked List);
(b-2) if the request determined in the step (a) is a function call in the real-time operating system of the target system, generating a function to perform a function requested by the tool of the host system, Management step;
(b-3) if the request determined in the step (a) is a function call in the context of the debug agent, calling a function on the target system, but not creating a task, step;
(b-4) If the request determined in the step (a) relates to a virtual input / output, data is written to a virtual input / output channel of the target system, and an output value from the target system is transmitted to a virtual terminal A virtual input / output management step of performing a function of transmitting the input / And
(b-5) an end notifying step of informing the host system of the end of the context when an event notifying the end of the task occurs in the real-time operating system when processing the request determined in the step (a); Wherein the RTOS-based embedded system software monitoring method comprises the steps of:

The method according to claim 1,
Initializing a kernel function pointer in the debug agent if a corresponding kernel function call is received from the debug agent, initializing a connection library so that a remote debugger of the host system can access the debug agent, The method comprising the steps of: (a) activating the kernel task as one kernel task of the RTOS-based embedded system software monitoring apparatus.

The method according to claim 1,
The step (b)
(b-6) managing a context on the target system, such as creating, destroying, resuming, and stopping the context if the request determined in step (a) is a request relating to the context;
(b-7) a register management function for obtaining a register value of the target system and setting a new value if the request determined in the step (a) relates to reading and writing the value of the register, ;
(b-8) If the request determined in the step (a) is related to memory processing, it performs functions such as a checksum calculation, a memory read / write, a memory fill, a memory protection, A memory management step;
(b-9) an event management step of adding and deleting an event point if the request determined in step (a) is an event setting and cancellation; And
(b-10) an exceptional state notification step of notifying the host system of an exceptional state when an exception occurs in the real-time operating system when processing the request determined in the step (a); Wherein the RTOS-based embedded system software monitoring method further comprises: