JPH10301801A - Debug device and information storage medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a debug device and an information storage medium for providing information for allowing a user to easily understand the executed content or execution position or the like of a program executed for debug based on the output information of the program executed for debug. SOLUTION: This debug device operates debug by connecting a card PC (personal computer) being the object of debug(a target equipment 100) through a communication line 30 with a host device 200 being a debug device. A program 300 for debug is executed in the target equipment 100. In the target equipment 100, the output information of the program 300 for debug is transmitted to the host equipment 200, a waiting state for a command from the host device 200 is obtained, and when the command is transmitted, the processing of the command is operated. In the host device 200, a POD(power-on diagnostic) the inverse of ID, line number, source file, and comment or the like executed by the target equipment are outputted to a display part 670.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a debugging device and an information storage medium for debugging at least one of hardware and software of a target information processing device.

[0002]

2. Description of the Related Art When a personal computer is newly designed and manufactured, the flow is "circuit design → board design → sample manufacture → evaluation → mass production”. Here, when there are many parts to be newly designed or when manufacturing a sample for which a manufacturing process has not been established, the completed sample has many obstacles. When debugging such a sample, BIOS (Basic) which is software which is often written and provided in a built-in ROM of a personal computer is provided.
Initialization of Input / Output System and function diagnosis routine (hereinafter referred to as POD (Power On)
Diagnostics) are often incorporated. The BIOS is software for controlling hardware, and the POD is a program executed first after the power is turned on. Thus, hardware debugging of the first example begins with the CPU fetching instructions from the ROM and enabling it, ie, enabling the POD to operate.

Such a sample contains a lot of hardware bugs and software bugs such as incorrect connection of signal lines, crosstalk and defective soldering, and the debugging work is difficult. .

Here, a general debugging method using sample hardware and POD will be described.

When power is supplied to the sample, the POD
Is executed. Since the POD diagnoses the function of the peripheral device, it is possible to identify a hardware failure to some extent by checking the operation of the POD. In addition, it is possible to check whether the software setting is correctly performed.

[0006] The POD is used at a position important for debugging.
_ID is converted to a predetermined I / O port (M
FG port). The POD is designed to hang up by itself when a device necessary for operating the system has a failure. Therefore, P
If a value output to the MFG port during execution of the OD is taken using a logic analyzer or the like, it is possible to know which routine the POD has executed. Also, by looking at the last value output to the MFG port, it is possible to know which routine executed when the POD hangs up, resulting in the hang-up. Also, since the POD_ID is a number that is incremented by one, by examining the POD_ID,
The execution position of can be known.

[0007] However, POD_ID is merely a number output as a serial number. Therefore, the POD_ID
It is not easy for the user to understand the execution contents and which part of the POD source code corresponds just by looking at it, and this is one of the causes that makes the debugging work difficult.

SUMMARY OF THE INVENTION An object of the present invention is to provide a debugging apparatus which can provide information that allows a user to easily understand the execution contents and execution position of a program executed for debugging based on output information of the program executed for debugging. And an information storage medium.

[0009]

According to the present invention, there is provided a debugging apparatus for debugging at least one of hardware and software of a target information processing apparatus, comprising the steps of: outputting an output of the debugging program executed in the target machine; User debug information creating means for creating user debug information including information representing at least one of an execution position and an execution content of the debug program based on data and a source code of the debug program; and User debug information output means for outputting debug information to a given output means.

The target machine is an information processing device to be debugged.

According to the present invention, user debug information including at least one of an execution position and an execution content of the debug program created based on output data of the debug program executed on the target machine and the source code of the bag program. Is output. Therefore, compared to a case where the output data is simply output,
It is easy to understand the execution contents and the execution position of the debugging program. Therefore, it is possible to provide a debugging device that facilitates debugging work and improves debugging efficiency.

Further, the user debug information creating means of the present invention creates comment information included in the source code of the debug program based on output data of the debug program to create debug information for the user. , The user debug information output means,
Outputting debug information for a user including comment information included in a source code of the debug program.

Generally, a comment describes information corresponding to an instruction code or the like described in a source code so that the contents of execution of the portion can be understood. Therefore, in many cases, the contents of execution of the debugging program can be easily understood from the comments.

According to the present invention, user debug information including comment information included in the source code of the bag program corresponding to the output data of the debug program executed in the target machine is output.

Therefore, it is possible to provide a debugging device that can facilitate a debugging operation and improve debugging efficiency by using the comment information. Here, it is preferable that a comment is written in the debugging program so that the debugging operation can be performed efficiently.

Further, the output data of the debug program of the present invention includes execution position data indicating an execution position of the debug program, and the user debug information creating means includes an execution position output from the debug program. It is characterized in that user debug information is created based on data.

Here, the execution position data indicating the execution position is data having a one-to-one or many-to-one correspondence with the execution position indicated by the source code of the debugging program.

According to the present invention, a corresponding source code of the debugging program can be detected based on the correspondence relationship of the execution position data.
User debug information corresponding to the source code can be efficiently provided.

According to the present invention, source information including information indicating at least one of an execution position and an execution content of the debug program created based on a source code of the debug program is output to the output data of the debug program. A source information storage unit for storing the source information stored in the source information storage unit based on output data output from the debugging program; It is characterized by creating debug information for the application.

According to the present invention, the source information storage means comprises:
It stores source information including information indicating at least one of an execution position and an execution content of the debugging program created based on the source code of the debugging program, and reads the source information to obtain debugging information for a user. Create Accordingly, user debug information corresponding to the source code is provided more efficiently than in a case where information representing at least one of the execution position and the execution content of the debug program is created from the source code of the debug program each time the program is executed. can do.

Further, the source information storage means of the present invention comprises:
Comment information included in the source code of the debugging program is stored in association with output data of the debugging program.

According to the present invention, the source information storage means comprises:
It stores comment information included in the source code of the debugging program. Therefore, user debug information including comment information corresponding to the source code can be provided more efficiently than when comment information included in the source code of the debug program is extracted each time the program is executed.

Further, the user debug information output means of the present invention outputs the user debug information to a given display means.

According to the present invention, since debugging information for a user is output to a given display means, it is possible to provide a debugging device capable of easily confirming debugging information for a user.

The output data of the debugging program of the present invention is output data of a BIOS initialization and function diagnosis routine stored in a read-only memory of a target machine.

Here, BIOS refers to Basic.
Abbreviation of Input / Output System, usually refers to software provided in an information processing device such as a personal computer by being written in a built-in ROM. BIOS functions related to the present invention include hardware initialization and function diagnosis.

The BIOS initialization and function diagnosis routine is a program executed first after the power is turned on. The routine is started in a state where it is not known whether a peripheral device normally provided in an information processing device such as a personal computer such as a memory, a video, a communication port, and a keyboard works properly. That is, the routine is made on the assumption that only the CPU and the ROM in which the routine is stored operate normally. The routine checks the function of the peripheral device and initializes the peripheral device.

According to the present invention, it is possible to provide a debugging apparatus capable of efficiently performing a debugging process by using such a BIOS initialization and function diagnosis routine as the debugging program.

[0029]

Embodiments of the present invention will be described.

FIG. 1 is an external view showing the use of the debug device of the present embodiment to debug a sample of a credit-size card-shaped personal computer (hereinafter referred to as a card PC). Since the card PC 10 is very small, it is difficult to attach a logic analyzer probe during sample debugging. The card P
Since C10 is directly attached to the board, C10 is
PU cannot be replaced with ICE probe. For this reason, the logic analyzer and I
I can't use CE.

Therefore, the present debugging apparatus is configured to connect the card PC 10 as a debugging target (target machine) to a personal computer 20 as a host machine via a communication line 30 to perform debugging.

(Hardware Configuration of the Present Embodiment) FIG.
The hardware configuration in the case where the debugging device of the present embodiment is connected to a sample target device via a communication line is shown. Here, the debugging device is referred to as a host device 200.

The target machine 100 includes a CPU 110, an R
It includes an OM 120, a RAM 130, and an I / O port 140. In the ROM 120, a debugging program is written. The CPU reads and executes the debugging program stored in the ROM. The debugging program includes a communication routine 330 as shown in FIG.

Since the card PC as the target machine is a sample to be debugged, the POD is turned on after the power is turned on.
This is a stage where hardware is faulty to the extent that it hangs up when dozens of steps are performed. However, in order for this debug device to function effectively, at least the CPU
Reads and executes a debugging program stored in the ROM, and operates a function capable of transmitting an output from the I / O port to the host device through the communication line 30.

The host device 200 includes a CPU 210 and a ROM.
220, a RAM 230, and an I / O port 240. The RAM 230 stores the host program 6 shown in FIG.
00 and a comment file 720 are stored. When the display module 640 or the like stored in the host program 600 is executed, it functions as a user debug information creation unit and a user debug information output unit. The comment file 720 functions as a source information storage unit.

The host machine 200 and the target machine 10
0 is connected by a bidirectional communication line. The communication line includes a first communication line 31 for performing communication from the target device 100 to the host device 200, and a communication line from the host device 200 to the target device 1
A second communication line 32 and a signal ground 33 for performing communication to 00 are included. The communication lines 31, 32, and 33 need only be bidirectional, and may be a serial cable or a parallel cable. This is because a communication routine corresponding to each communication line may be prepared by software.

In the target machine, any I / O for transmission
1 bit of port is set to 1 of any I / O port for reception.
Bits are allocated. Both are another two on the same port
Bits may be used, and Read Only / Write
Only the same bit may be used. For example, a handshake line of a serial port can be assigned, or input / output bits can be prepared one by one in external hardware. The communication line 30 is bidirectional, and a half-duplex communication line is used. Although it is meaningless to be half-duplex in itself, hardware support cannot be obtained due to communication through a simple I / O port, a communication program cannot use RAM, and communication speed is secured. Is preferably not half-duplex but half-duplex.

(Software Configuration of the Present Embodiment) The software configuration of the target device 100 and the host device 200 when the execution result of the target device is received and debugged in real time by the host device will be described.

In the target machine 100, a debugging program is executed. Although details of the debug program will be described later, the debug program includes a POD as shown in FIG. The POD has about 10 times more POD_
It is configured to output an ID. The debugging program is configured to transmit the POD_ID, which has been output by a simple output command to a board in which the conventional POD is determined, to the host device 200 using the bidirectional communication line 30. After the transmission, it is checked whether any command is transmitted from the host device 200. If not sent, POD is continued, and if sent, the command is processed.

In the host device 200, a host program is executed. The host program sends a command such as a memory read to the target device 100, receives and displays the execution result, and sends the program to the target device 100 to be executed.

Next, each function required for debugging of each software will be described.

(Host detection function in target machine)
The debugging program of the target device 100 detects the host device as soon as possible after the processing is started, and sets whether or not the host device 200 is present by storing the host presence flag. The reason why the host presence flag is set in this manner is that if a host device is detected every time the POD_ID is sent, the operation of the POD becomes slow when the host device 200 does not exist.

In this manner, the debugging program operates as a normal POD except that there is no host except during debugging. For this reason, there is no need to remove the debugging program even when the product is shipped. Therefore, it can be used for debugging when a defect occurs after product shipment.

(POD_ID Transmission Function in Target Machine) POD_ID is assigned to each part of the POD of the debugging program so that the operation can be sufficiently followed. POD_ID is assigned when P
This means that a subroutine call for calling a routine for sending OD_ID is incorporated. FIG.
(A) shows a state in which a subroutine call for calling a routine for sending POD_ID to POD is incorporated. Here, send_id (360-1, 360-2, 360-3) corresponds to a subroutine call for calling a routine for transmitting POD_ID.

In the routine for transmitting the POD_ID, first, the POD_ID is output to the I / O port. This is a simple output instruction. Then, it is determined based on the host presence flag whether or not the host machine exists. If there is no host machine, the process immediately returns to the caller (see step 50 in FIG. 5A).
If the host machine is present, the POD_ID is sent to the host machine (see step 60 in FIG. 5A), and thereafter, it waits for a while to check whether a command is sent from the host machine (step in FIG. 5A). 70). If no command is received, the process returns to the calling source (see 500 in FIG. 5A). When a command arrives, it processes the command and returns to the calling source (step 10 in FIG. 5A).
0, 110, 120, 140). It is preferable that the transmitted command and associated parameters are stored in a register of the CPU and processed so that command processing can be performed even when the RAM cannot be used.

(Output Information Receiving Function in Host Machine) In order to make the debug program detect the host machine, the host program starts execution before the debug program, always monitors the communication line 30, and the POD is POD_I.
Each time D is sent out, it is received and stored in memory (see steps 160, 170, 180 in FIG. 5B). POD_ID of about 30,000 steps can be stored in the memory of the host machine. This is about ten times the capacity of a logic analyzer, and the use of a temporary file can make the storage amount virtually unlimited.

(Output Information Display Function in Host Device) The accumulated POD_ID is displayed on the screen of the host device between communication processes. POD_ID is just 1 as it is
Since it is difficult to understand with a 6-bit numerical value, it is preferable to take out comments from the corresponding POD source code and display them in order.

(Function for Stopping Operation of Target Device from Host Program) The operation of the target device is stopped from the host device by using a breakpoint function, a one-step function, or other user operation. be able to.

The break point function is a function for stopping POD processing when a predetermined POD_ID is sent. This function is realized by sending a command to suspend the POD operation to the target device immediately after receiving the POD_ID. (See steps 190 and 210 in FIG. 5B) POD serving as a breakpoint
The _ID may be set as a standard in the system, or may be set as appropriate by the user according to the debugging situation. For example, when the debug program stops operating when the serial port is initialized and sends the serial port test program to the target machine to check the operation of the serial port, the output is performed when the initialization is completed. POD
_ID may be set as a breakpoint.

After stopping the processing of the POD at the break point, the user can perform various operations through the host program. That is, comment information corresponding to the execution position is displayed on the screen of the host machine to indicate the progress of the debugging program. The user determines a debugging process to be executed on the target device at the break point while watching the screen display, and inputs an execution of a command or the like corresponding to the debugging process from the keyboard of the host device (FIG. 5B). Step 22 of
0, 230, 240).

When it is desired to stop the operation of the target machine other than at a break point, a one-step function is used or a user operation is performed.

The one-step function is a function that causes the target machine to execute up to the next call of the send_id routine. That is, the user operates the host machine,
The execution of the target device can be stopped at the first POD_ID that comes after the instruction to execute the one-step function is issued.

The one-step function is executed by the PO of the target machine.
This is realized by sending a command instructing continuation of D, and sending a stop command to the first POD_ID that comes after that. In addition, the user can operate the host machine to specify a temporary breakpoint, and stop the target machine at the temporary breakpoint.

Hereinafter, an example of the configuration and operation of the target machine and the host machine of the debugging apparatus will be described in detail.

(Configuration of Debugging Program) FIG.
3 shows a configuration of a debugging program 300 stored in a ROM of a target machine. The debugging program 300 is a program necessary for realizing the POD 310 and the debugging function of the present debugging apparatus.
It includes an ID update routine 320, a communication routine 330, and a command processing routine 340.

The POD 310 is a program that is executed first after the power is turned on and performs hardware initialization and function diagnosis. That is, the POD 310 is a memory video
Multiple initializations to check and initialize the functions of peripheral devices normally equipped on the PC, such as communication ports and keyboards
.. Includes a function diagnosis routine 312, 314.

The POD 310 is executed first after the power is turned on, and has been conventionally used as a program used for debugging a sample in order to diagnose the function of a peripheral device. However, conventionally, POD_
They simply output a code called ID and stored it in the logic analyzer. For this reason, various problems have occurred such that debugging cannot be performed with a sample without a logic analyzer, the number of POD_IDs that can be recorded is limited, and various operations cannot be performed after POD execution is stopped. .

In order to solve the above-mentioned problem, the target machine of this embodiment transmits the output information of the debugging program including the POD_ID to the host machine 2 via the communication line 30.
00, a command from the host device, and the like, and a process corresponding to the command.

In the target machine 100, the PO
The D_ID update routine 320, the communication routine 330, and the command processing routine 340 are included in a debugging program, thereby realizing the above functions in software.

The POD_ID update routine 320
This is a routine for performing a process of updating POD_ID and passing it to the communication routine. The POD 310 is configured to call the POD_ID update routine 320 at a location important for debugging. Since a RAM cannot be used, a special technique such as passing a return address to a register is required for calling a subroutine.

The communication routine 330 is a routine for performing communication processing between the target machine and the host machine.
Called from the update routine and started. The communication routine is configured to confirm the presence of the host device, to transmit POD_ID when the host device exists, and to receive a command from the host device. Then, a command processing routine 340 for processing the received command is called.

The command processing routine 340 includes a program for performing various processes corresponding to a command sent from the host machine. From the host machine, a command for instructing the continuation of the stopped POD 310, a command for instructing to stop the execution of the POD, a command for instructing to read the contents of the memory of the target machine, and a given content in the memory of the target machine. Command to write the data, I / O of target machine
A command to read the contents of the port, a command to write the given contents to the I / O port of the target device, a command to execute the program transmitted from the host, and the like are sent.

In response, the command processing routine 340
The continuation command routine 341, the stop command routine 342, the memory read command processing routine 343, the memory write processing routine 344, the I / O port read information 345, I / O port write routine 346, program execution command processing routine 3
47 are provided.

Here, the POD 310 and POD_ID update routine 320 will be described.

FIGS. 4A and 4B are diagrams showing a state in which a POD_ID update routine call is inserted into a main part of the POD 310 and an outline of the processing of the POD_ID update routine 320. FIG.

The POD 310 in FIG. 4A is a routine for testing the DMA page register, and performs a process for checking the DMA page register 80h to 8Eh one bit at a time to confirm that each bit can be read and written correctly. ing. In this example, when the test of the DMA page register is started (360-1), when an error occurs during the test (360-2), and when the test is terminated (36-1).
The POD_ID is sent to the host device at three locations 0-3). The call of the POD_ID update routine is performed by a macro. In this example, the macro name of the POD_ID update routine is send_id. As described above, when a POD is created, a macro of a POD_ID update routine is inserted in advance at a debug-like important position.

FIG. 4B shows an outline of the macro processing of the POD_ID update routine 320. The redefinition of the POD_ID in the macro (370) is for increasing the POD_ID each time the macro is called. As a result, POD_ID is incremented by one among the macros, and each send_id macro has a different POD_I
D can be sent. POD_ID is BIOS
About 1000 files are assigned to each source code file.

In the macro of the POD_ID update routine 320, in order to send the updated POD_ID to the host machine,
A call (380) of the communication routine 330 is made.

Next, the communication routine 330 and the confirmation of the existence of the host machine performed by the communication routine 330 will be described.

The communication routine 330 is executed by the target machine 10
0 is a routine for performing communication processing between the host device 200 and the host device 200.
It is called from the POD_ID update routine 320 and started. The communication routine 330 first checks whether or not a host machine is present.
Return to the caller without transmitting _ID.

If the host device 200 exists, the PO
D_ID is transmitted to the host device 200, and the process waits until a command from the host device 200 is received. In this embodiment,
This is because when the target device 100 transmits the POD_ID to the host device 200, the host device 200 is configured to return any command as long as it exists. When a command is received from the host device 200,
Call the command processing routine.

Upon transmitting the POD_ID, the target device 100 is configured to process a command transmitted from the host device unless a continuation command is received from the host device. Therefore, except for the case of the continuation command, the process waits until a command from the host machine is received again.

It should be noted that the presence / absence of the host machine is confirmed by referring to the host presence flag. That is, immediately after the start of the process, the POD calls the communication routine. At this time, the communication routine transmits the data determined for host device confirmation, and detects the presence or absence of the host device in response to the determined data response to the data. If there is a response, the host presence flag is set to ON assuming that the host device is present, and if there is no response, the host presence flag is set to OFF as no host device is present. After setting the host presence flag, the presence / absence of the host device is confirmed with reference to the host presence flag. However, since the host presence flag was ON, the POD_ID was transmitted. However, if no command is sent from the host device even after a predetermined time, the host presence flag is turned OFF and the process returns to the caller. In this way, if communication with the host machine cannot be performed on the way for some reason, the processing can be continued assuming that the host machine does not exist.

Also, since the RAM cannot be used,
The host presence flag may be set to any port on the peripheral device (some devices have a scratchpad register), or one of the registers of the CPU may not be used in the POD. In this embodiment, the upper 16 bits of one 32-bit register (for example, ECX register) of the target machine are not used in POD, and the host presence flag is set there. The reason why the host presence flag is set beforehand is to prevent the POD operation from delaying when the host device is not detected when the host device is detected each time the POD_ID is transmitted.

(Explanation of Operation of Target Machine) The card PC as the target machine operates based on the debugging program and information transmitted from the host machine. Less than,
The operation of the target machine by the debugging program will be described.

FIGS. 5A and 5B are flow charts for explaining the operation of the debugging device. FIG. 5 (A)
FIG. 4 is a flowchart for explaining the operation in the target machine.

First, when the power is turned on, the execution of the POD of the debug program is started, and a host presence flag is set (step 5). And POD
Hangs up in the middle or is executed to the end and ends (step 10).

During the execution of POD, send_id (P
When there is a macro call of (OD_ID update routine),
When the process goes to the POD_ID update routine 320, P
OD_ID update processing is performed (steps 30 and 40). Then, the processing is transferred to the communication routine 330, and first, the existence check of the host machine is performed. That is, the host presence flag is referred to, and if the host presence flag is OFF, the POD_ID is not transmitted to the host device, and the process immediately returns to the calling POD. If the host presence flag is not OFF, a process of transmitting the POD_ID to the host device is performed (Step 60). Then, a command is received from the host machine, and the execution of the POD is stopped (step 70).

Here, if there is no response from the host machine for a predetermined time, the host presence flag is turned off, and processing for returning to the POD of the caller is performed (step 80,
Step 90). Timeout processing (500)
That.

When a command is received from the host machine within a predetermined time, a command processing routine 3 corresponding to the command is received.
40 is started, and the process specified by the command is performed (step 140). If the command is a continuation command, the process returns to the POD of the calling source, and the execution of the stopped debugging program is resumed (step 110).

The command received from the host machine is
If the command is a stop command, the timeout process is prohibited, and the system waits for a command from the host machine again (steps 120, 130, 70).

(Explanation of the Operation of the Host Machine) Next, the operation of the host machine will be described with an example of sending various debug commands to the target machine using the breakpoint function.

The host program starts execution before the debug program to make the debug program detect the host machine, always monitors the communication line, and waits for the POD_ID to be sent from the target machine ( Step 160). And the target machine is POD_I
Each time D is sent out, it is received and stored in the memory (step 170, step 180).

Then, it is determined whether or not the received POD_ID corresponds to a break point (step 19).
0). If the POD_ID does not correspond to a breakpoint, a continuation command is sent to the target device (step 1).
90, step 200) and, if applicable, send a stop command to the target machine (step 190, step 21)
0).

When the break point is reached, the user waits for an input (step 220), and when there is an input from the user (step 230), a command transmission process corresponding to the input content is performed (step 240). If the input command is a continuation command, the process returns to a state of waiting for a POD_ID to be sent from a normal target device (steps 250 and 160). If the input command is not a continuation command, the process returns to the state of waiting for the user's input again (steps 250 and 220).

(Configuration of Host Program) FIG. 6 is a diagram showing the configuration of the host program and its input / output devices.

The host program 600 includes a reception module 610, a transmission module 620, and a storage module 63
0, a display module 640 and an operation module 650.

The receiving module 610 receives the communication line 30 from the target device and the receiving port 690 of the I / O port 240.
Has a function of transmitting data received via the storage module 630 to the storage module 630. The data received from the target machine
Output data of a debug program such as POD_ID and a response to a debug command, and output data of a program transmitted from the host.

The transmission module 620 transmits data passed from another module to the I / O port transmission port 700,
It has the function of sending out to the target machine via the communication line 30.

The storage module 630 has the following functions.

(1) The data passed from the receiving module 610 is stored in the memory 710.

(2) The operation module 650 is notified that the data has been passed from the receiving module 610.

(3) The data read from the file 660 is stored in the memory 710.

(4) Write the data stored in the memory 710 to the file 660.

(5) The stored data is passed in response to a request from the display module 640.

Since the storage module 630 does not distinguish between the data received from the receiving module 610 and the data read from the file 660, the record of the POD_ID can be once written in the file 660 and referenced later.

Hereinafter, each module will be described in detail.

(Receiving Module) First, the receiving operation performed by the receiving module 610 will be described.

The receiving module 610 receives the data sent from the target device by a two-wire communication system.
The two-wire communication method uses boring and software handshaking to communicate without using interrupts. Therefore, the receiving module 610 is called repeatedly at appropriate time intervals, and checks a receiving request from the target device. If there is no reception request, the reception module 610 does nothing.

If there is a receiving request, the receiving module 610
Receives the data and passes the received data to the storage module 630. The receiving module 610 does not distinguish between data types. That is, it does not distinguish whether the data sent from the target device is the POD_ID or, for example, the data of the read memory.

(Transmission Module) Next, the transmission operation performed by the transmission module 620 will be described.

The transmission module 620 transmits data passed from another module to the target device using a two-wire communication system. The transmitted data is a debug command, memory write data, or the like. Transmission module 620
Also, like the receiving module 610, the type of data is not distinguished.

(Storage Module) Storage Module 630
Has two sub-modules, a data storage sub-module 632 and a file operation sub-module 634. The data storage sub-module 632 secures a temporary file on the memory 710 or a disk as a data storage location.

This module has the following functions.

(1) Data passed from another module or sub-module is stored in a data storage location.

(2) Perform simple interpretation of data stored in the data storage location.

(3) The operation module 650 is notified that data has been received from the reception module 610.

(4) Data requested from another module or sub-module is read from the data storage location and passed.

(5) The data storage location is emptied according to an instruction from another module or sub-module.

Here, the data storage sub-module 632
One of the functions described above, "simple interpretation of stored data", will be described.

The receiving module 610 passes the data sent from the target device as it is to the data storage sub-module 632 in 1-byte units, but it is difficult to handle the data as it is. That is, since the received data is simply a byte string as it is, POD_I
There is no distinction between D and a response to a command sent from the host machine. Further, for example, the POD_ID is transmitted as 3-byte data, but there is no distinction between the first byte and the second byte. In this way, if the data is simply byte data, the data storage sub-module 632
It is necessary for the operation module 650 and the display module 640 that obtain data from the respective modules to interpret the data.
In this case, if the data is interpreted by two or more modules, there is a high possibility that an error will occur in the interpretation logic. Therefore, it is desirable that the data storage sub-module 632 perform basic data interpretation. Therefore, in the present debugging device, the storage module 630 interprets the data.

The data interpretation performed by the data storage sub-module 632 includes determining data delimiters and detecting data errors and making appropriate corrections. The function of determining the data delimiter is a function for interpreting POD_ID and other data sent in a combination of a plurality of bytes as a set of data. Data error detection and correction is intended to minimize the effects of data interpretation confusion caused by incorrectly received data. Typically, insertion, deletion, and modification of bytes are performed so that a reasonable data delimiter can be obtained.

The data reception notification to the operation module 650 is performed after the data interpretation is completed.

The file operation sub-module 634 writes data stored in the data storage sub-module 632 to the file 660 or reads data from the file 660 and stores the data in the data storage sub-module 632 in accordance with an instruction from another module. Or

The storage module 630 performs a storage operation, a data providing operation, and a file operation. That is, the storage module 630 stores the data passed from the reception module 610 by using the data storage sub-module 632. The storage module 630 stores the data requested by another module in the data storage sub-module 63.
Take out from 2 and provide. The storage module 63
0 writes the data stored in the data storage sub-module 632 to the file 660 or reads the data from the file 660 and stores the data in the data storage sub-module 632 in accordance with the instruction of the operation module 650.

(Display Module) Display Module 640
Acquires the data instructed from the operation module 650 from the storage module 630 and displays it on the screen (display unit) 670 of the host device. Here, the data received from the storage module 630 may be data transmitted from the target device or data stored in the file 660. Also, comment information about each POD_ID is obtained from the comment file 720,
Used to display data.

The format of the display can be changed by an instruction from the operation module 650. Items that can be displayed are “PO
D_ID, source code name, line number, comment, detailed comment ".

(Operation Module) Operation Module 650
Has an automatic response sub-module 652 and a command processing sub-module 654.

The automatic response sub-module 652 receives the received data from the storage module 630, and automatically sends a corresponding response to the target device via the transmission module 620.

Normally, the data sent to the target machine is
This is a continuation command for causing the target device to continue POD processing. When the POD_ID of the breakpoint is sent, a stop command for interrupting the operation of the POD is sent.

Further complicated processing can be performed. For example, when a certain POD_ID is received, a program prepared in advance is sent to the target machine to be executed, and processing such as resuming the operation of the POD after the execution is completed may be reserved in advance. .

The command processing sub-module 654 interprets a keyboard operation or a menu operation performed by the user from the input unit 680, and issues an appropriate instruction to each module. Operations that can be performed by the user include changing the display position, searching for data, setting breakpoints, reserving automatic responses, reserving one-step functions, editing memory on the target machine, and I / O
There are instructions for program execution, POD restart, instructions for writing / reading stored data to a file, instructions for terminating a host program, and the like.

(In the case where the data received by the host machine is once written to a file for processing) FIG. 7 (A)
FIG. 3B is a diagram for describing a case where the host device writes data received once into a file and performs processing.

FIG. 7A is a diagram for explaining the operation when writing the stored data to the file 660 in the host machine. The stored data refers to data in which the data received by the host device is stored in the data storage location by the data storage sub-module 632 of the storage module 630. When the host machine processes the data sent from the target machine in real time, it is not necessary to write the data accumulated in the accumulation module 630 to the file 660 as described in the above-described example.
However, the storage module 630 does not
Since the data received from 0 and the data read from the file 660 are not distinguished, the record of the POD_ID can be once written to a file and referenced later. In such a case, the processing described in FIGS. 7A and 7B is required.

When the user operates the input unit 680 to write the stored data to the file 660 (step 910), the operation module 650 instructs the storage module 630 to write the stored data to the file 660 (step 920). The file operation sub-module 634 of the storage module 630 writes the stored data to the file 660 (Step 930). When the writing is completed, the end of the writing is notified to the operation module 650 (step 940). The operation module 650 notifies the user of the end of writing (step 950).

FIG. 7B is a diagram for explaining the operation when reading data from a file. the user,
The input unit 68 reads data from the file 660.
When the operation is started from 0 (step 960), the operation module 650 instructs the storage module 630 to read data from the file 660 (step 970). Then, the file operation sub-module 634 of the storage module 630 reads data from the file 660. At this time, the data storage sub-module 632 interprets the read data in the same manner as when receiving data from the receiving module 610 (step 980). When the reading is completed, the operation module 650 is notified of the completion of the reading (step 990). Operation module 650
Displays the first page on the display module 640 in the display unit 670
To display. (Step 1000). The display module 640 displays data necessary for displaying the first page from the storage module 630 on a screen.

As described above, the debugging device can perform the debugging operation by treating the data read from the file in the same manner as the received stored data.

(Host Data Creation Program and Comment File) In this debugging apparatus, the output information sent from the target machine is displayed on the display unit 670 of the host machine. A desired debugging operation can be performed flexibly according to the progress of the POD of the device.

When the power is turned on in the target machine, POD3 of the debug program 300 shown in FIG.
Execution of 10 is started. The POD 310 is a program for initializing peripheral devices and diagnosing functions, and initializes and diagnoses the functions of the peripheral devices (A, B,...) 312, 312.
14, ... is included. When the power is turned on, POD3
.. Sequentially execute the initialization and function diagnosis routines 312, 314,... Of the peripheral devices (A, B,...), And hang up if there is a problem in operating the system.

Here, the POD 310 is configured to transmit POD_ID data to the host device at a position important for debugging. Since the POD_ID is a number that is incremented by one, the execution position of the POD 310 can be known by checking the POD_ID. For example, in the case of a hang-up, in order to know at which point the
It is preferable to insert a macro that calls the _ID update routine. However, when all PODs are executed, 30000
Since about POD_IDs are output, the POD_I
It is difficult for the user to understand the execution contents and which part of the POD source code corresponds only to D.

For example, when the user wants to stop the execution of the POD and perform a desired debugging operation such as reading out of the memory on the way, the user stops the execution of the POD while watching the position of the POD on the screen. To determine where to do. In such a case, it is very difficult for the user to determine the position of the POD only by looking at the POD_ID.

Therefore, in the present debugging apparatus, the POD execution position can be displayed by any of POD_ID value, line number, comment, detailed comment, or a combination thereof. In addition, a label or the like of a portion including send_id may be displayed. That is, for example, when the value of the POD_ID based on the send_id 1210 in FIG. 8A is displayed, the label SR_VALUE_IOOP of the portion including the send_id is displayed.

FIG. 8A shows the POD source code 12.
00 shows an example. For example, in the host machine, 1
When the POD_ID transmitted with the send_id 210 is received, and when the source code name is displayed, the source code near the send_id 1210 shown in FIG. The name (for example, 1240) is displayed. When displaying a line number, a line number 1010 corresponding to send_id of 1210 is displayed. When a comment is displayed, a comment 1220 corresponding to send_id of 1210 is displayed. Further, as a detailed comment, a comment indicating the details of the process near send_id of 1210 is displayed.

Here, POD_ID is information obtained by receiving from the target device, and the source code name, line number, and comment are information obtained by analyzing the POD source code based on the POD_ID.
Therefore, the POD source code is stored in the memory of the host program, and each time the POD_ID is received,
The information can be obtained by analyzing the source code of the OD. However, this requires a long time for processing, and the same processing is repeated each time the processing is executed, which is inefficient. For this reason, in this debugging device, FIG.
, A comment file 720 storing a line number, a comment, and the like corresponding to the POD_ID is prepared. Then, the display module 640 displays the received PO
Based on D_ID, a line number, a comment, and the like are read from the comment file 720 and displayed on the display unit 670.

FIG. 8B is a diagram showing an example of data stored in the comment file 720. As shown in FIG. FIG.
As shown in (B), the comment file 720 contains P
OD_ID 720, line number 1260, comment 1270
Etc. are stored.

As for the display of the detailed comment, the content written in the form of a special comment on the source code may be displayed. That is, in the Microsoft assembler, since the part from “;” to the end of the line is regarded as a comment, in this embodiment, a character string written after one “;” following the macro (send_id) is displayed as a comment, When ";", that is, ";;", which follows two lines next to the line where (send_id) appears, up to the end of the line is displayed as a detailed comment.

It is to be noted that the information is not directly obtained from the POD source program, but is set in advance by the user.
For each comment or for each content of the comment, a content defining the content may be output. For example, a format may be used in which a comment or the like corresponding to the processing content is included in the comment information of the source code, and the content corresponding to the symbol is defined.

If the comment file 720 is created in advance in this way, information that is easy for the user to understand can be displayed on the screen with a simple configuration in which various information corresponding to the POD_ID is read from the comment file.

(Screen Display Example) FIGS. 9 to 11 are diagrams for explaining the display screen of the debugging device. FIG.
FIG. 10 and FIG. 11 show screen states when execution information is not displayed. FIGS. 10 and 11 show the POD source code 12 shown in FIG.
13 is a display example of a screen when 00 is executed.

FIG. 8A shows a source code 1200 of a portion for testing the DMA register in the POD. Specifically, DMA page registers 80h to 8E
For h, a source code 1200 for confirming bit by bit that each bit can be read and written correctly is shown. At the beginning of execution of this part, a send_id of 1212 is executed, and if the test fails, a send_id of 1210 is executed.
id is executed and if the test succeeds, 1214
send_id is executed.

FIG. 10 is a display example of a screen when the test has failed, and FIG. 11 is a display example of a screen when the test has succeeded.

In FIG. 10, reference numerals 502 204 and 504 205 displayed below the ID 500 indicate the POD_ID output from the target device. If the test fails on the target machine, 121
The send_id of 2 and the send_id of 1210 are executed. Accordingly, the corresponding POD_IDs 204 and 205 are read from the comment file 720 of FIG. 8B, and the POD_IDs 204 and 205 are displayed as shown in FIG. The user can check the execution status of the POD by following the POD_ID.

The source file 510 in FIG.
DMACHKC of 512 or 514 displayed under
K. ASM is the name of the source file of the POD including the send_id that outputs the POD_ID of 502 or 504. In this embodiment, the POD source code is divided into a plurality of source files and stored. Therefore, by referring to the source file name, the name of the source file in which the source code being executed is stored can be determined.

The line number 520 in FIG.
1000 of 522 and 10 of 524 displayed under
Reference numeral 10 denotes a line number of the send_id that outputs the POD_ID (204 of 502 or 205 of 504). FIG.
As shown in (A), send_id of 1212 and 1210
The row numbers of send_id of the POD_ID20 are 1000 and 1010, and the row numbers of the POD_ID20 are as shown in FIG.
4 and 205 are stored in the comment file 720 (1260 in FIG. 8B). Therefore, the line numbers 1000 and 1010 are read from the comment file and displayed as shown in FIG.

The comments 532 and 534 displayed below the comment 530 in FIG.
The POD_ID (50) of the source file shown in FIG.
2 are the comments 1216 and 1220 described in the send_id line that has output 204 and 504 205). As shown in FIG. 8A, send_id of 1212 and 121
The comment of send_id of No. 4 is “Start-” of 1216 and “DMA-failed” of 1222, and such a comment is stored in the comment file 720 corresponding to the POD_ID as shown in FIG. 12 of 8 (B)
72 and 1274). Therefore, the comments 532 and 534 are read out from the comment file and read as shown in FIG.
Is displayed. The user can see that the test failed without having to follow the source code by looking at the comment.

If the test is successful on the target machine, the send_id of 1212 and the
14 send_id are executed. Therefore, the corresponding POD_IDs 204 and 206 are read from the comment file 720 of FIG.
204 and 206 are displayed as D_ID. The user can check the execution status of the POD by following the POD_ID.

Source file 510 in FIG.
Of 516 DMACHCKCK. Displayed below. AS
M is also the name of the source file of the POD including the send_id that outputs the POD_ID of 506.

The line number 520 in FIG.
1022 of 526 displayed below the POD
_ID (206 of 506) is the line number of send_id that has output. As shown in FIG. 8A, send_id of 1214
Of the comment file 7 corresponding to the POD_ID as shown in FIG.
20 (1260 in FIG. 8B). Therefore, the line number 1022 is read from the comment file and displayed as shown in FIG.

The comment 536 displayed under the comment 530 in FIG. 10 is a comment 1214 described in the send_id line that outputs the POD_ID (206 in 506) of the source file shown in FIG. It is. As shown in FIG. 8A, the comment of send_id of 1214 is “DMA to OK” of 1222. Such a comment is stored in the comment file 720 corresponding to the POD_ID 206 as shown in FIG. 8B (1276 in FIG. 8B). Therefore, the comment 536 is read from the comment file and displayed as shown in FIG.

(Program for Creating a Comment File) In addition, when creating the comment file, the host program inputs a POD and
A comment file creation program for creating the file 20 is prepared. Each time the comment file creation program detects a macro (send_id) that calls the POD_ID update routine in the POD source code, the POD_I
Increment the value of D. Where POD_I
The D number is assigned to each POD source code file. Therefore, in the source code, POD_
Each time a macro (send_id) that calls the ID update routine is detected, the value incremented by one from the initial value determined for each file becomes the POD_ID transmitted there.

The manner in which a comment file is created from the POD source code will be described with reference to FIGS. The comment file creation program 1290 in which the POD source code shown in FIG.
When the send_id of 212 is detected, POD_ID (1250) 0204h incremented by 1 is output.
Then, the corresponding line number 1000 and the comment 1216 described in the line are output. And the next send
When the _id (1210) is detected, the POD_ID (1250) 0205h which is incremented by one from the previous time is output. Then, the corresponding line number 1010 and the comment 1220 described in the line are output. In this way, the comment file creation program 1290
Is a comment file 72 storing information such as POD_ID, line number, and comments from the POD source code.
Create 0.

The debugging device of the present invention is not limited to the one described in the above embodiment, but can be variously modified.

For example, in the above embodiment, the case where the output information sent from the target device is displayed in real time on the display unit 670 of the host device has been described as an example, but the output information may be temporarily stored in a file. Good. In such a case, it is preferable that the process input by the user at the break point is executed with an automatic response. When outputting the output information later, the output information may be output to a printer or the like instead of the screen.

In the above embodiment, the case where the target device and the host device perform bidirectional communication has been described as an example. However, the target device unilaterally transmits POD_ID to the host device, and the host device executes the execution. The trajectory may be stored and output.

In this embodiment, a comment file is created in advance and the screen display content is output based on the content of the comment file. However, the POD source code is directly read and the screen is displayed based on the source code. The display contents may be output.

[0156]

[Brief description of the drawings]

FIG. 1 is an external view of a debug device of the present embodiment when a sample of a credit-size card-shaped personal computer is debugged.

FIG. 2 shows a hardware configuration of a host machine and a target machine of the present embodiment.

FIG. 3 shows a configuration of a debugging program stored in a ROM of a target machine.

FIGS. 4A and 4B show PODs at main parts of a POD.
FIG. 14 is a diagram illustrating a state in which a D_ID update routine call is inserted and an outline of processing of a POD_ID update routine.

FIGS. 5A and 5B are flowcharts for explaining the operation of a host machine and a target machine.

FIG. 6 is a diagram showing a configuration of a host program and its input / output devices.

FIGS. 7A and 7B are diagrams for explaining a case where data received by a host device is temporarily written to a file and processing is performed;

FIGS. 8A and 8B are diagrams for explaining an operation of creating a comment file from a POD source code.

FIG. 9 is a diagram for explaining a display screen of the debugging device, and shows a state of the screen when execution information is not displayed.

FIG. 10 is a diagram for explaining a display screen of the debugging device, and is a display example of a screen when a test fails.

FIG. 11 is a diagram for explaining a display screen of the debugging device, and is a display example of a screen when a test is successful.

[Explanation of symbols]

 REFERENCE SIGNS LIST 30 communication line 31 first communication line 32 second communication line 33 signal ground 100 target machine 120 ROM 130 RAM 140 I / O port 300 debugging program 310 POD 320 POD_ID update routine 330 communication routine 340 command processing routine 600 host program 610 reception module 620 transmission module 630 storage module 640 display module 650 operation module 660 file 670 display section 680 input section 720 comment file

Claims (9)

[Claims] 1. A debugging device for debugging at least one of hardware and software of a target information processing device, comprising: output data of a debugging program executed in the target machine; and source code of the debugging program. User debug information creating means for creating user debug information including information representing at least one of the execution position and execution content of the debug program, and the user debug information to a given output means A debugging information output unit for outputting the user debugging information. 2. The debugging information for a user according to claim 1, wherein the user debugging information creating means extracts comment information included in a source code of the debugging program based on output data of the debugging program. Wherein the user debug information output means outputs user debug information including comment information included in a source code of the debug program. 3. The debugger according to claim 1, wherein the output data of the debug program includes execution position data indicating an execution position of the debug program. A debug device for creating user debug information based on execution position data output from a program for use. 4. The method according to claim 1, wherein the source information including information indicating at least one of an execution position and an execution content of the debugging program created based on a source code of the debugging program is stored. Source information storage means for storing the output data of the debug program in association with the output data, wherein the user debug information creation means is stored in the source information storage means based on output data output from the debug program. A debug device for reading out the source information and creating debug information for a user. 5. The debugging device according to claim 4, wherein the source information storage unit stores comment information included in a source code of the debugging program in association with output data of the debugging program. . 6. The debugging device according to claim 1, wherein the user debug information output unit outputs the user debug information to a given display unit. 7. The program according to claim 1, wherein the output data of the debugging program is output data of a BIOS initialization and function diagnosis routine stored in a read-only memory of a target machine. Characteristic debugging device. 8. An information storage medium used for a debugging device for debugging at least one of hardware and software of a target information processing device, wherein the output data of the debugging program executed on the target machine and An information storage, comprising: information for creating debug information for a user based on a source code of a debug program; and information for outputting the debug information for the user to a given output unit. Medium. 9. The information according to claim 8, wherein the information for creating the user debug information includes: extracting comment information included in a source code of the debug program based on output data of the debug program; Information for generating debug information for the user, and information for outputting the debug information for the user to a given output means, for the user including comment information included in the source code of the program for debugging. An information storage medium including information for outputting debug information.