JPH10326203A - Debugging devices capable of taking over operation from each other between hardware environments while running programs therein - Google Patents

Abstract

PROBLEM TO BE SOLVED: To complement advantages and disadvantages of hardware environments having mutually different functions with each other and to enable supervisory control by specifying a switching source and a switching destination and reading operation state information from a switching source operation-verified object, and converting and setting a form in a switching destination operation-verified object. SOLUTION: A built-in program developed for a trial machine 30 is run on trial by either of its emulator machine (host computer) or software simulator (host computer 1) to verify the operation. If a specific indication by an operator is detected here, a stored operation-verified object is specified as a switching source operation-verified object and an operation-verified object different from it is specified as a switching destination operation-verified object. The operation state information is read out of the switching source and converted to the format of the switching destination. Then the operation information which is converted in format is set in the switching destination operation-verified object and the operation of the built-in program is restarted at the switching destination operation-verified object.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a debugging device for debugging an embedded application program.

[0002]

2. Description of the Related Art A microcomputer system is indispensable for today's home electric appliances. Developing programs for home appliances requires quality that can withstand mass production, so thorough debugging is required. The debugging work here refers to the work of running a program on a hardware environment, pursuing the cause of a defect (bug) that appeared during the operation, and correcting it.

[0003] The operation modes of a program (referred to as a program to be debugged, which is referred to as a program to be debugged) include the following. Runs the program to be debugged on the evaluation board. A program that simulates a program to be debugged using a simulator on the host computer.

[0004] The form of the hardware environment as described above is mainly for monitoring a program. A hardware environment whose main purpose is to monitor a program is referred to by an abbreviation “monitor type”. When a prototype of a target microcomputer or microprocessor is completed, the monitor-type hardware environment is used exclusively for checking its operation and for simple debugging.

[0005] Such a hardware environment mode enables an advanced debugging operation using an in-circuit emulator and various debugging tools. Such a hardware environment is called ICE (In-Circuit Emulator)
Type ". Such a form of the hardware environment is called a simulator type. There are two types of simulators, one at the instruction level and one at the logic level. An instruction-level software simulator is a software system that simulates the execution state of a microcomputer or microprocessor on another host by simulating the instructions of the microcomputer or microprocessor with software on the host operating system. .

The logic level software simulator is usually used for designing a microcomputer or a chip of a microprocessor, and simulates the same operation as hardware on another host by software.

[0007]

However, the above three types of hardware environments have a limit in their operation verification capability. The limitation of the operation verification capability of the monitor-type hardware environment is the hardware environment that presupposes monitoring, so even if a bug is found during operation verification, the ability to analyze the cause is insufficient, and It is a point that cannot be dealt with as expected. In the ICE type hardware environment, it is possible to take measures such as checking the history of program execution using the trace function, but in the monitor type hardware environment,
In many cases, a trace function or the like that uses a lot of memory cannot be used, and the operator must pursue the cause by making use of poor functions. Further, it cannot be underestimated that the operation check assuming various cases when the target machine is used is insufficient. Representative examples of "various cases when using the target machine" include those related to the occurrence of interrupts, such as when a program generates multiple interrupts or when an interrupt occurs at a specified time. To implement these on the target machine, some modification of the hardware is necessary, but as a practical matter, such modification is not so easy and the contents that can be confirmed on the target machine are limited. Would.

The limitation of the operation verification capability of the ICE type hardware environment is that the circuit configuration is different from that of the target machine. In other words, even if it appears to operate completely on the evaluation board, it is not possible to make a final decision as to whether or not the shipment is OK by the operation. In addition, since the target machine is not in a proper form, operation verification including peripheral devices may be insufficient. This is because the wiring length of the evaluation board may be longer than that of the actual prototype, and there is often a time lag in the control of peripheral devices due to this length. Due to such a time lag, the operation verification including peripheral devices in the ICE type hardware environment is not strict.

The limitation of the software simulator type hardware environment is that the simulator itself is a host computer.
The operation of the program is much slower than that of the monitor or ICE type. For example, in an ICE-type or monitor-type hardware environment, processing that takes one second to complete takes several minutes to several tens of minutes.

[0010] If the investigation of the cause of the bug is not progressed due to the limitation of the operation verification ability of the individual hardware environment, the developer wants to reproduce the situation at the time when the bug occurred in another hardware environment. However, in order to reproduce it in another hardware environment, it is necessary to set the value of the register and memory held at the time of the bug occurrence on the other hardware environment, or to re-execute the microcomputer or microprocessor program from the beginning It is necessary to repeat mistakes.
Repeating trial and error to reproduce the situation at the time of the bug occurrence wastes a lot of development time.

It is an object of the present invention to provide a debugging device which can be controlled in an integrated manner so that the advantages and disadvantages of hardware environments having different functions can be complemented with each other. Another object of the present invention is to provide a debugging device that can reproduce a situation closer to a hardware environment at the time of occurrence of a bug on another hardware environment without bothering a developer.

[0012]

A debugging apparatus for achieving the above object is a program for executing a built-in program developed for a predetermined target machine by using the target machine, the emulator machine of the target machine, or the software simulator of the target machine. A target device, an emulator machine, and a software simulator having operation state information indicating an operation state of an embedded program, and inputting the operation state information. Operation verification target storage means for performing output in a specific format and storing any one of a target machine, an emulator machine of the target machine, and a software simulator of the target machine as a target of operation verification; Receiving means for receiving an input, detecting means for detecting a predetermined instruction included in a command received by the receiving means, if detected, and an operation stored in the operation verification target storage means when the predetermined instruction is detected The verification target is designated as the switching source operation verification target, and the target machine, the emulator machine of the target machine, and the software simulator of the target machine which are different from the switching source operation verification target are switched based on the command received by the receiving unit. Designation means for designating the first operation verification target, reading means for reading the operation state information from the switching source operation verification target when the switching source and the switching destination are specified, and reading the operation state information for the switching destination operation verification A conversion means for converting to the target format; and, if the operation status information is converted to the switching destination format, the operation status for which the format has been converted. Setting means for setting information as a switching destination operation verification target, and operation resuming means for controlling operation of the embedded program to be restarted in the switching destination operation verification target when the operation state information is set. .

[0013]

DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of a debugging device will be described below. The hardware configuration of the debugging apparatus is configured by connecting an ICE control board 22 and a serial transfer port 31 to a general-purpose computer. FIG. 1 is an external view of the debugging device. The home electric appliance prototype 30 constructs a monitor-type hardware environment. Since it is a monitor type, it has a ROM in which a program for embedded use is stored, and the program to be debugged can be operated on the prototype 30. The program to be debugged in the prototype 30 is under the jurisdiction of the host computer 1, and the operation of the program to be debugged and the operation end are performed only when instructed by the host computer 1 via the serial line 40. . The host computer 1 also has access rights to storage resources such as memories and registers on the prototype 30 and can read the contents of the storage resources of the prototype 30 as storage resource status information at a desired timing.

The evaluation board 20 can operate a program to be debugged. The program to be debugged on the evaluation board 20 is also under the jurisdiction of the host computer 1.
This is performed in accordance with an instruction from the host computer 1 via the parallel line 28. Host computer 1 is evaluation board 2
It also has access rights to storage resources such as memories and registers on 0, and can read the contents of the storage resources of the evaluation board 20 at desired timings as storage resource status information.

FIG. 2 is a hardware configuration diagram of the debugging device. As shown in FIG. 2, the host computer 1 is a general-purpose computer having a CPU, a display, a memory, a hard disk, and a keyboard. I c
The E control board 22 and the serial transfer port 31 are connected to the evaluation board 20 and the prototype 30, respectively.

FIG. 3 shows a hardware configuration of the microcomputer system on the prototype 30. In FIG. 3, the prototype 30
Processor 33, memory 34, peripheral I / O register group 35
Has been implemented. The processor 33 includes: an instruction reading circuit that reads out machine language instructions constituting the program to be debugged one by one; a decoder that decodes the read machine language instructions; And an arithmetic unit for performing the operation of the specific operation instruction, a register group, and a program counter for instructing the instruction reading circuit to read the instruction. The processor 33 has a dedicated terminal 39, and when a predetermined instruction signal is output to the dedicated terminal 39, the processor 33 reads out operation state information indicating the operation state of the prototype 30, and outputs the host computer via the dedicated terminal 39. To the data 1.

In the memory 34, a monitoring program 36, a program to be debugged 37, and a work area 38 in the target used by the debugged program 37 for work inside the prototype 30 are arranged in the user space. The program to be debugged 37 is an embedded application program to be debugged, and is executed by the processor 33 when the prototype 30 is started. Since the debugged program 37 is to be monitored, a monitoring instruction is incorporated. The monitoring instruction is an instruction for instructing the processor 33 to branch from the debugged program 37 to the monitoring program 36 when the processor 33 receives data via the dedicated terminal 39.

The monitoring program 36 causes the processor 33 to wait for input of data from the dedicated terminal 39. If data is input to the dedicated terminal 39, the processor 33 performs an operation according to the data. Peripheral I /
The O register [i] (i = 1, 2, 3,..., N) 35 is a register for holding the value of the peripheral I / O. Here, the peripheral I / O is a serial interface, a parallel interface, an interrupt controller, an A / D converter, a D / A converter, a timer counter, and the like. These values are individually stored in a peripheral I / O register. By doing so, the processor 33 can extract an arbitrary peripheral I / O value.

FIG. 4 shows a hardware configuration of the microcomputer system on the evaluation board 20. In FIG. 4, the evaluation board 20 is provided with a memory 24 and a peripheral I / O register group 25, in which an ICE chip 23 is attached instead of the processor 33. The memory 24 has a supervisor space and a user space. The supervisor space is provided with a supervisor program 26 and a debug information area 27, and the user space is provided with a program 37 to be debugged and a work area 38 in a target.

The peripheral I / O register group 25 is a register that is a peripheral I / O and that holds a value that can be operated on the evaluation board 20. The supervisor program 26
A breakpoint setting tool for setting a breakpoint, a trace tool for storing the address of the executed instruction each time the ICE chip 23 executes an instruction, and monitoring whether a predetermined condition set by the operator is satisfied or not, And an interrupt setting tool for generating an interrupt signal when the condition is satisfied.

The debug information area 27 is a memory area used by the supervisor program 26 as a work area. The debug information area 27 stores the address to which the break point is set, the break point information regarding the validity / invalidity of the operation of the break point, and the like. In addition, trace data including a plurality of instruction addresses and interrupt signal generation requirement information indicating predetermined conditions for generating an interrupt signal determined by an operator are stored.

FIG. 27A shows an example of a breakpoint setting destination address. "BREAK_POINT" in the figure
[1] = 0x0020 ”indicates that the first breakpoint is set in an area of a predetermined size starting from 0x0020, and“ BREAK
K_POINT [2] = 0x0250 ”sets the second breakpoint to 0x0
This indicates that the area is set to a predetermined size starting from 250. “BREAK_POINT [3] = 0x0300” indicates that the third breakpoint is set in an area of a predetermined size starting from 0x0300. These breakpoint setting destination addresses are the same as those in the previous supervisor program 2.
When the debugger 37 debugs the program 37 to be debugged, the operator sets a breakpoint using a command, and the processor 33 executes the breakpoint setting tool in the supervisor program 26, so that the data is written in the memory 24.

FIG. 27B shows an example of an interrupt signal generation requirement. "CONDITION [1] = 20cycle, Int"
"3" indicates that the third interrupt signal is generated after the instruction execution is repeated 20 times the unit length of the execution time, and "CONDITION [2] = 150cycle, Int5" This indicates that the fifth interrupt signal is generated after being repeated by 150 times the length. The requirements for generating these interrupt signals are as follows.
At the time of debugging, the operator performs an interrupt generation setting operation, and the program to be debugged 37 executes the interrupt signal generation tool in the supervisor program 26, so that the program is written in the memory 24.

FIG. 27C shows an example of trace data. `` 0x0000,0x0001,0x0002,0x0003,
0x0004,0x0005, ”indicates that the ICE chip 23 executes the machine language instruction at the address x0000 in the program 37 to be debugged,
This indicates that the machine instruction at x0001, the machine instruction at address 0x0002, and the machine instruction at address 0x0003 have already been executed. These trace data are written to the memory 24 because the operator has input a TRACE command and the processor 33 has executed the trace tool in the supervisor program 26 at the time of debugging the program 37 to be debugged by the ICE type hardware environment. Have been.

The target work area 38 is a work area used by the program to be debugged. FIG. 6 is an internal hierarchical diagram of the host computer 1 shown in FIG.
The internal layers of the host computer 1 include an application layer 11, an operating system layer 12, and a BIOS layer 1.
3. It is composed of the physical layer 14 and is no different from the hierarchical structure of a general-purpose computer. In such a general-purpose hierarchical configuration, the simulator 10 exists in the application layer 11. The simulator 10 is an application layer 11
Existing above means that the simulator 10 is a kind of application program started on the operating system. It can be seen that the ICE control board 22 and the serial transfer port 31 are located on the physical layer 14. For the ICE control board 22, a dedicated device driver exists in the BIOS layer 13 (see the ICE device driver 21).

The simulator 10 is the application layer 1
Therefore, the window of the simulator type hardware environment is the application layer 11. Since the device driver 21 exists on the BIOS layer 13, the window of the ICE type hardware environment is the BIOS layer 13. Since the serial transfer port 31 exists on the physical layer 14, the window of the monitor-type hardware environment is the physical layer 14.

Since the windows exist at different levels,
When passing parameters to each hardware environment, the parameters must be changed in a format suitable for each layer.
When parameters are transferred between hardware environments, a format conversion is required. Specifically, the simulator 10 is an application that exists on the application layer 11.
Since it is a type of application program, it is necessary to transfer parameters in an argument format. Device driver 2
1 is a device driver existing in the BIOS layer 13, so it is necessary to transfer parameters in a BIOS command format. Since the serial transfer port 31 exists in the physical layer 14, it is necessary to transfer parameters using an I / O port.

In order to manage three hardware environments of an ICE type, a monitor type, and a simulator type, this device uses an IC
TARGET1, T for E type, monitor type and simulator type respectively
The identifiers ARGET2 and TARGET3 are given, and the identifiers of the hardware environments that are currently set to be debugged are registered in a master table (not shown). FIG. 7 is a diagram showing a hierarchy formed for integrating the ICE type, the monitor type, and the simulator 10 type hardware environment inside the application layer 11.

The target dependent layer 53 is a layer for unifying the data format used between the ICE type, monitor type, and simulator type hardware environments into an argument type. The target interconnect layer 52 is a layer for sharing data unified in a common format by the ICE type, the monitor type, and the simulator 10 type, and includes a work area for sharing.

The debug core layer 51 is a layer having a function corresponding to an application section of a so-called symbol debugger. The user interface layer 50 is a layer that provides a user interface to an operator using a standard input / output library of the operating system layer 12. That is, the user interface layer 50 uses the standard input / output library of the operating system layer 12 to display a message asking for an instruction from the operator on the display 2. When a command is input, interpretation and execution of the command are entrusted to the debug kernel layer 51 and lower layers. When the command in which the layers below the debug kernel layer 51 are input is executed, the user interface layer 50 displays the execution result of the command on the display 2 using the standard input / output library of the operating system layer 12.

FIG. 8 is a diagram showing what modules are present in the respective layers of the debug kernel layer 51, the target interconnect layer 52, and the target dependent layer 53. In the figure, it can be seen that a symbol-address map 71, a command interpreter 72, and a command conversion routine 73 exist in the debug kernel layer 51. The symbol-address map 71 is information indicating a correspondence between a symbol and an address. Here, the symbol means a variable name, a library, and the like used in the source program, and the symbol-address map 71 indicates which address in the memory area corresponds to the variable name indicated by the symbol. More specifically, the symbol-address map 71 includes a memory size, a type of a variable, line information that associates a line number of a line where one sentence of a source code exists with an address of an execution code corresponding to the line, and the like. You.

The command interpreter 72 analyzes a command input by the program developer to the user interface layer 50, and notifies the command conversion routine 73 of an instruction according to the content of the analysis. Here, the command interpreter 72 determines that the command input by the key type is
The analysis is performed assuming that it corresponds to any of the system diagrams shown in.

Of the commands described in FIG.
The n command, stop command, step command, setBP command, clrBP command, SetINT command, readMEM command, readREG command, writeMEM command, writeREG command, and TRACE command are commands for general debugging devices. The run command is a command for instructing the hardware environment designated as the command issue destination to start the operation of the debugged program, and can specify the operation start address of the debugged program in its operand.

The stop command is a command for instructing the hardware environment designated as the command issue destination to stop the operation of the program to be debugged. The step command is
In the hardware environment specified as the command destination,
This command indicates that the instructions of the debugged program are to be executed one instruction at a time, and the operand thereof can specify the operation start address of the debugged program.

The setBP command is a command for instructing the hardware environment designated as the command issue destination to set a breakpoint at the address in the debugged program designated by the operand. Here, "breakpoint setting" refers to writing an instruction for generating a predetermined interrupt signal in the debugged program or registering an address in the debugged program to be stopped in a predetermined register in the processor. However, in the present embodiment, the write destination address of the interrupt signal generation instruction is also written to the memory in the hardware environment along with these operations.

The clrBP command uses the operand "breakNO"
And a command for deleting an interrupt signal generation instruction for generating a breakpoint of the number indicated by the instruction and a write destination address of the instruction. The SetINT command causes the hardware environment to monitor whether instruction execution has been repeated for the execution time specified by the operand “CycleNumber” (note that this execution time is expressed as an integral multiple of the execution cycle). The command instructs the hardware environment to generate an interrupt signal of the number indicated by the operand "intNO." If repeated for the execution time.

The readMEM command is executed by the operands "s_address" and "e" in the hardware environment designated by "TARGET".
_address ”is instructed to the hardware environment to read the contents of the area specified. The readREG command instructs the hardware environment to read the contents of the register indicated by the operand “register”.

The writeMEM command instructs the hardware environment to write the content specified by "value1" to the memory area specified by the operand "address" in the hardware environment specified by "TARGET". The writeREG command instructs the hardware environment to write the content indicated by “value2” to the register of the number indicated by the operand “register”.

The readMEM command, readREG command, wr
The iteMEM command and writeREG command can also designate operands by variables. When indicated by a variable, the command interpreter 72 refers to information registered in the symbol-address map 71. By referring to such information, it is possible to specify the address or register type and the size of the register where the variable exists in the memory. After obtaining the variable information, the command for referring to the variable is replaced by the command interpreter 72 with a command for obtaining information corresponding to the size from a certain address from the memory or obtaining / setting the value of a certain register. Simulator 10, monitor control layer 6
1. Notification to any of the ICE control layers 62.

The TRACE command instructs the hardware environment to store the address of an instruction executed in the hardware environment. The selectTARGET command is an instruction to transfer the operation status of the storage resource of the hardware environment specified as the command issue destination to another hardware environment, and a command to switch the debug command issue destination to another hardware environment. Command. To transfer the operating state of the storage resource to another hardware environment, the work area 38 in the target of the hardware environment is used.
Contents, register contents, breakpoints, interrupt signal generation requirement information, peripheral I / O register contents, and trace data must be individually transferred. In order to realize the individual transfer, the command interpreter 72 executes the subcommand copyME
M command, copyREG command, copyBP command, copyIN
Issue T command, copyI / O command, and copyTRACE_DATA command.

The copyMEM command causes the target interconnect layer 52 to transfer the contents of the in-target work area 38 of the memory contents in the hardware environment currently used for debugging to the switching destination specified by the selectTARGET command. To instruct. The copyMEM command can specify the transfer of an arbitrary area by describing the start address-end address of the transfer range in the operand, and by setting a switch that specifies the transfer of the entire memory space, , Can be specified to transfer the values of all memories.

The copyREG command sets the value of a register group in the hardware environment currently used for debugging to sele.
This is a command for instructing transfer to the switching destination specified by the ctTARGET command. The copyBP command is
Of the memory contents in the hardware environment currently used for debugging, set the breakpoint setting address
This command instructs transfer to the switching destination specified by the selectTARGET command.

The copyINT command selects information indicating the interrupt signal generation requirement of the interrupt signal from the memory contents in the hardware environment currently used for debugging.
This is a command for instructing transfer to the switching destination specified by the ET command. The copyI / O command is a command for instructing that all peripheral I / O registers in the hardware environment currently used for debugging be transferred to the switching destination specified by the selectTARGET command.

The copyTRACE_DATA command is used to transfer the trace data of the memory contents in the hardware environment currently used for debugging to the switching destination specified by the selectTARGET command.
To instruct. The description of the components of the debug core layer 51 will be continued. The command conversion routine 73 converts commands interpreted by the command interpreter 72 and commands automatically issued by the command interpreter 72 to lower levels. Here, the conversion to a lower level refers to converting a command into a function call code.

When the command interpreter 72 interprets the input command as a read command for status information such as a readMEM command, the function call code TCI_get_mem (adr, lengt
(h, unit, image) etc. 『TCI_g
“TCI” in “et_mem” is an abbreviation of “Target Core Interface” and means that this function call code is used between the debug kernel layer 51 and the target interconnect layer 52. That is, this function call code is a function call code used only in a local section between the debug kernel layer 51 and the target interconnect layer 52. 『TCI_get_mem』
“Get_mem” means “get the value held in memory”. "Adr, length, unit, image" is an argument. adr indicates the start address, and length indicates the acquisition length. The unit indicates an acquisition unit such as a byte, a word, or a double word, and the image indicates a storage destination of memory contents.

It can be understood from these meanings that when the command interpreter 72 interprets an input command as a readMEM command, the debug kernel layer 51 sends the target interconnect layer 5
2, the instruction using the function call code is issued. The reading destination is the prototype 30, the evaluation board 20,
Since the hardware environment of the simulator 10 is not specified, it is understood that the function call is defined by the abstract level.

When the command interpreter 72 interprets the input command as a write command of status information such as a writeREG command, the function call code TCI_set_REG (regs, mask)
And so on. "S" of "TCI_set_REG"
“et_REG” means “set an immediate value of a register”. "Regs, mask" is an argument. reg
s is the array name of an array variable that individually stores the values of various registers such as general-purpose registers, program counters, status registers, data registers, and address registers in the shared work area, and mask is specified by the argument regs. This is a mask bit pattern that indicates which of the elements (register holding values) of the array variable to be set are set in the processor in the hardware environment and which are not set in the hardware environment.

Similarly, the command interpreter 72 converts the command input by the operator into “run”, “stop”, “step”, “set”.
BP, clrBP, SetINT, readREG, writeMEM, TR
ACE ”, the command conversion routine 73 executes“ TCI
_run, TCI_stop, TCI_step, TCI_setBP, TCI_c
lrBP, TCI_SetINT, TCI_read_REG, TCI_write_ME
M ”and converted to a function call code“ TCI_TRACE ”and transmitted to the target interconnect layer 52.

Automatically issued when the command interpreter 72 interprets an input command as a selectTARGET command.
The function call codes converted from the copyMEM command to the copyTRACE_DATA command will be described. copyMEM
The transfer of state information by the command to the copyTRACE_DATA command is performed by a two-stage function call code. The first stage is to instruct the switching source to read out the status information of the storage resource by the function call code “TCI_get ~”, and the second stage is to switch the state by the function call code “TCI_set ~”. This is to instruct the destination to write the status information of the storage resource.

FIG. 13 shows the copyMEM command to cop before conversion.
yTRACE_DATA command and converted function call code TCI_g
et_mem (adr, length, unit, image)-TCI_set_TD (adr, leng
FIG. 6 is a diagram showing a correspondence relationship of (th, unit, image). Referring to the figure, the subcommand CopyMEM is executed by TCI_get_mem (adr, len
gth, unit, image) and TCI_set_mem
It can be seen that it is converted to a function call code of (adr, length, unit, image).

Function call code TCI_get_mem (adr, length, u
nit, image) indicates that the contents of the in-target work area 38 among the storage resources of the switching source are to be read from the switching source, and the function call code TCI_set_mem (adr, length, unit, imag
e) indicates that status information is to be set in the work area 38 within the target among the storage resources at the switching destination. What should be noted in FIG. 13 is the number of arguments of the function call code.

Function call codes “TCI_get_reg (regs, mask)” and “TCI_set_reg (regs, m) converted from“ CopyReg ”
ask) only has two arguments, and the other function call codes have four arguments like (adr, length, unit, image). Although this is different in content,
M, “CopyBP”, “CopyINT”, and “CopyI / O” command all transfer commands related to memory among the storage resources (peripheral I / O register group 25, peripheral I / O register group). This is because the contents of 35 can be accessed via a memory.) And (adr, length, unit, image) can be used to express the access contents.

The argument in “CopyBP” will be described. Although the form of the breakpoint may be different in each hardware environment, the majority is of a type in which the address of a machine instruction in the program to be debugged is individually indicated. To specify instruction addresses individually, use the argument (a
“length, unit” in dr, length, unit, image) is unnecessary. However, some hardware environments can use a so-called area break in which a breakpoint can be specified in an area. Because it is premised on the connection of the hardware environment where such an area break can be used, this device uses the arguments (adr, length, unit, image)
The breakpoint size and access length specification are incorporated into the function call code arguments.

The argument (cycle, cycle,
intkind) will be described. The argument cycle indicates an integral multiple of the unit length of the execution time of instruction execution, and intkind indicates a signal number of an interrupt signal to be generated. In FIG. 8, the target interconnection layer 52 includes a format conversion routine 74, a work area content analysis module 75, and a shared work area 77. Here, the style conversion routine 74
The shared work area 77 will be described, and the work area content analysis module 75 will be described later.

The format conversion routine 74 converts the function call code converted by the command conversion routine 73 into a format depending on the hardware environment. Here, the “format dependent on the hardware environment” means that the name of the callee function included in the function call code is rewritten to a function name indicating the hardware environment. Where the subcommand Co
pyMem converts the command conversion routine 73 to TCI_get_mem (adr, l
ength, unit, image), TCI_set_mem (adr, length, unit, ima
ge). In this case, the format conversion routine 74 rewrites the function names included in these function call codes.

First, the format conversion routine 74 executes TCI_get_me
The function name “TCI_get_mem” in m (adr, length, unit, image) is rewritten to a function name that clearly indicates the switching source. For example, when the switching source is the monitor type and the switching destination is the simulator type, the function call code TCI_get_mem (adr, leng
th, unit, image) has been generated. Since the hardware environment of the switching source is of the monitor type, the function call code is rewritten to a function name "MON_get_mem" specifying the monitor type, and MON_get_mem (adr, length, unit, image) is obtained.

Subsequently, the format conversion routine 74 executes TCI_set_
"TCI_set_mem" in mem (adr, length, unit, image)
Is rewritten to a function name that clearly indicates the switching destination.
Since the hardware environment of the switching destination is a simulator type, the function name "SIM_set_mem" that explicitly specifies the simulator type
Is rewritten as The rewrite result is SIM_set_mem (adr,
length, unit, image). After rewriting the function name, the format conversion routine 74 calls the function using the rewritten function call code.

The format conversion routine 74 performs the same rewriting for all the function call codes shown in FIG. FIG. 14 is a diagram showing how all the function call codes shown in FIG. 13 have been rewritten. When rewriting the function name, the format conversion routine 74 identifies whether the switching source and the switching destination are the ICE type, the monitor type, and the simulator type. Since the switching source is the hardware environment currently set as the debug target, the identifier registered in this file is identified as the switching source hardware environment by referring to the master table. The switching destination is selectTARG
Since the hardware environment is set in the operand of the ET command, the format conversion routine 74 receives the selectTARGET command from the command interpreter 72, and
The identifier indicated in the operand of the lectTARGET command is interpreted as indicating the hardware environment of the switching destination. When the switching source and the switching destination are determined in this way, the function name of the function call code is rewritten.

The shared work area 77 is a work area shared by a monitor-type, ICE-type, and simulator-type hardware environment, such as an area Image specified by the argument Image. The target dependent layer 53 includes the simulator 10,
It comprises a monitor control layer 61 and an ICE control layer 62.

The simulator 10 is an application program having the configuration shown in FIG. As shown in FIG. 5, the simulator 10 includes a processor simulation routine 9
5, a memory simulation routine 96 and an I / O register simulation routine 97. Processor simulation routine 95
Simulates the function of the processor 33. The memory simulation routine 96, like the memory 24, stores the supervisor program 26, the debug information area 27, the program to be debugged 37, and the in-target work area 38. Since these are stored, the bug analysis ability of the simulator type hardware environment is almost equal to that of the ICE type.

The I / O register simulation routine 97 includes a peripheral I / O
The function of the register group 35 is simulated. The processor simulation routine 95, the memory simulation routine 96, and the I / O register simulation routine 97 are activated by a function call code specifying a simulator type. Function call code SIM_get_mem (adr, le
(ngth, unit, image) using the format conversion routine 74, the processor simulation routine 95 converts the data stored in the start address adr in the memory simulation routine 96 by the size specified in the acquisition length length. Read for each unit specified in the acquisition unit. When read, the processor simulation routine 95 stores the data in the area specified by the argument image in the shared work area 77.

Function call code SIM_set_mem (adr, length, u
nit, image), the processor simulation routine 95 transfers the data of the area specified by the argument image in the shared work area 77 to the area after the start address adr in the memory simulation routine 96. Write. The writing operation is performed by the size specified by the argument length in the unit specified by the argument unit.

The monitor control layer 61 also has jurisdiction over the program to be debugged in the prototype 30 and access to storage resources such as memories and registers on the prototype 30. The monitor control layer 61 operates the program to be debugged at a desired timing. The contents of the storage resources of the prototype 30 are read and written. This read / write control is performed by the serial transfer port 31, the serial line 40,
This is performed by the monitor control layer 61 performing a predetermined communication sequence with the monitoring program 36 via the dedicated terminal 39. The execution conditions for these communication sequences are:
A function call by the format conversion routine 74 is performed.

For example, the communication sequence for reading the contents of the memory is performed by transmitting and receiving the packet shown in FIG. 15 (2) according to the protocol of (1). The communication sequence is performed when the monitor control layer 61 calls a function using the function call code MON_get_mem (adr, length, unit, image). Each of the three types of packets shown in (2) of FIG. 15, that is, the MEMREAD packet, the ACK packet, and the DATA1 / n to n / n packets has an 8-byte length field.

The 0th byte of the MEMREAD packet is a CMD field in which a command code indicating the type of command is written. The first byte is a UIT field, which indicates to the processor the unit of reading from the memory (byte, word, double word). The second and third bytes are an ADRS field in which the size of memory data to be read is written. The read destination address of the memory is written in the fourth to seventh bytes.

In the ACK packet, a type code indicating the type of error that has occurred in the monitoring program 36 is written in the 0th byte. FIG. 17 is a flowchart showing the processing content of the monitor control layer 61 when executing the memory content reading sequence. The format conversion routine 74 executes the function call code MON_get_mem (adr, length, unit, im
age), the monitor control layer 61 determines in step S1 that the CMD field, size field, ADR
Set the S field and UIT field and create a transmission packet. At this time, what content is written in each field, but MEMREAD
Write a code indicating For the size field,
Write the read size indicated by the argument length,
In the ADRS field, the read destination address indicated by the argument adr is written. In the UIT field, the read destination address indicated in the argument unit is written. When a MEMREAD packet is created in this way,
In step S2, the created packet is transmitted to the monitoring program 36 via the serial line 40. After the transmission, the monitor control layer 61 waits for reception of an ACK packet in step S3. If the ACK packet is transmitted, step S3 becomes Yes and the process moves to step S4. In step S4, the monitor control layer 61 checks the ERR field of the ACK packet. If abnormal, the process proceeds to step S2 to reissue the MEMREAD packet. If normal, the variable i is set to 1 in step S5.
, And the leng specified in the argument in step S6
variable n to the number obtained by dividing th by the DATA packet size (8 bytes)
Set. The variable i indicates a number individually assigned to each DATA packet, and the variable n indicates the total number of DATA packets.

When initial values are set to these variables, the monitor control layer 61 in step S7 sets the received packet i (i =
Wait for reception of 1,2,3,4 ... n). If a DATA packet is transmitted while waiting for reception in this way, the monitor control layer 61 receives this. Then, in step S8, the 8-byte data described in the DATA field of i of the received DATA packet is stored in the area specified by the argument image in the shared work area 77. After storing, in step S9, the variable i is compared with the variable n, and if
If i is different from the variable n, the variable i is determined in step S10.
Is incremented, and the routine goes to Step S7.

Thereafter, step S9 returns Yes, ie, the variable i =
The reception of the DATA packet in step S7 and the storage of the 8-byte data in the shared work area 77 in step S8 are repeated until the variable n is reached. By repeating steps S7 to S10, the data of the prototype 30 is transferred to the serial transfer port 31-serial line 40-
The data is transferred to the monitor control layer 61 through the dedicated terminal 39 in units of 8 bytes. The transferred 8-byte data is accumulated in the area image in the shared work area 77. When such repetition is performed n times, data of the size specified by the argument length in the function call code is stored in the image area of the shared work area 77.

When the data in the memory 34 is read out to the shared work area 77, it can be transferred to the simulator 10 and the ICE control layer 62. As described above, the data in the memory 34 is stored in the shared work area 7.
7, the format conversion routine 74 executes the function call code SIM_set_mem (adr, length, unit,
image), the shared work area 7
At 7, the data of the in-target work area 38 of the memory 34 stored in the argument image is written to the area after the start address adr in the memory simulation routine 96.

The same communication sequence is repeated for the contents of the remaining registers, breakpoints, interrupt signal generation requirement information, contents of peripheral I / O registers, and trace data. The state information is transferred to the memory simulation routine 96. A communication sequence for writing the contents of the work area 38 in the target to the memory 34 in the prototype 30 is shown in (2) of FIG.
Are transmitted and received according to the protocol (1). The communication sequence is performed because the monitor control layer 61 uses the function call code MON_set_mem (ad
(r, length, unit, image).

Each of the three types of packets shown in FIG. 16B, that is, MEMWRITE packets, DATA1 to n packets, and ACK1 and 2 packets has an 8-byte length field. The 0th byte of the MEMWRITE packet is a CMD field in which a command code indicating the type of command is written. The first byte is a UIT field, which indicates to the processor the unit of reading from the memory (byte, word, double word). The second and third bytes are a SIZE field in which the size of the in-target work area 38 data to be read is written. The fourth to seventh bytes are an ADRS field in which the write destination address of the contents of the memory 34 is written.

In the ACK1 packet and ACK2 packet, a type code indicating the type of error that has occurred in the monitoring program 36 is written in the 0th byte. FIG.
9 is a flowchart showing the processing contents of a monitor control layer 61 when executing a read sequence of the contents of a work area 38 in a target.

The format conversion routine 74 uses the function call code MO
When the function is called by N_set_mem (adr, length, unit, image), the monitor control layer 61 determines in step S11 that the CM
Set the D field, size field, and ADRS field, and create a transmission packet. At this time, depending on what content is to be written in each field, a code indicating MEMWRITE is written in the CMD field. The size indicated by the argument length is written into the size field, and the write destination address indicated by the argument adr is written into the ADRS field. In the UIT field, write the write destination address indicated by the argument adr.

When the MEMWRITE packet is created in this way, the created packet is transmitted to the monitoring program 36 via the serial line 40 in step S12. After transmission, the monitor control layer 61 proceeds to step S
At 13, the reception of the ACK packet is waited. If the ACK packet has been transmitted, step S13 becomes Yes and the process proceeds to step S14. In step S14, the monitor control layer 61 checks the ERR field of the ACK1 packet. If abnormal, the process proceeds to step S12 and the MEMREA
The D packet is reissued.
In step S15, the variable j is set to 1, and in step S16, the length specified in the argument is set to the DATA packet size (8 by
Set the variable n to the number divided by te). Variable j is each DATA
Indicates the number individually assigned to the packet, and the variable n is the DAT
Indicates the total number of A packet transmissions.

When initial values are set for these variables, of the data stored in the area image specified by the argument image in step S18, from the (8 * (j-1)) th byte
Read 8 bytes up to the (8 * j-1) byte. Here, since j = 1, data from the 0th byte to the 7th byte is read out, and the monitor control layer 61 writes this in the DATA field of the transmission DATA packet j. After the description, a DATA packet is issued in step S19 and step S20
Move to In step S20, the variable j is compared with the variable n. If the variable j is different from the variable n, the process proceeds to step S2.
In step S18, the variable j is incremented.
Move to

Thereafter, step S20 returns Yes, that is, the variable j
= Transmission of 8-byte data in step S18 and step S19 is repeated until variable = n. Step S
Through the repetition of steps 18 to S21, the data in the shared work area 77 is transferred to the memory 3 via the serial transfer port 31, the serial line 40, and the dedicated terminal 39 in units of 8 bytes.
It is transferred to 4. The transferred 8-byte data is stored in the memory 34. When such repetition is performed n times, the data stored in the area image is stored in the memory 3
4 is stored.

The same communication sequence is repeated for the contents of the remaining registers, breakpoints, interrupt signal generation requirement information, contents of peripheral I / O registers, and trace data. Is stored in the storage resource of the prototype 30. Here, before the function call is performed using the function call code MON_set_mem (adr, length, unit, image), if the held value of the simulator 10 is written in the shared work area 77 in advance, the simulator 10 in the shared work area 77 It is also possible to transfer the value held in the ICE control layer 62 to the memory 34.

The ICE control layer 62 controls the ICE chip 23 in the evaluation board 20. That is, it has the jurisdiction of the program to be debugged and the access right of the storage resources such as the memory and the register on the evaluation board 20. Then, the debugged program is operated at a desired timing, and the shared work area 7 is stored in the storage resources of the evaluation board 20.
7 is written.

The above read / write control is performed by the format conversion routine 7
4, the ICE control layer 62 issues a BIOS command to the device driver 21 in accordance with the function call specifying the ICE type. FIG. 19 shows a state in which the contents of the debugged program 37 in the evaluation board 20 are read out.
FIG. 4 is an explanatory diagram showing control contents of an ICE control layer 62. The ICE control layer 62 executes the function call code ICE_get_mem (adr, length, unit,
image), the ICE control layer 62
Sends the BIOS command “MEM_
READ (adrs, type, num)].

The parameters of the BIOS command will be described. The parameter “adrs” indicates from which address in the work area of the evaluation board 20 the state information is read, and the parameter “type” indicates the unit of reading on the evaluation board 20. Although the argument unit specifies the same reading unit, the acquisition unit used in the evaluation board 20 may be different. In that case, the device driver 21
The parameter ty is used in the unit of acquisition that is accepted by the evaluation board 20.
Set pe.

The parameter num indicates the number of words. The word length of “word” here means the acquisition unit specified by the parameter type, and the parameter num is set to the number obtained by dividing the read size specified by the argument length by the word length unit when calling the function . As described above, the parameters
When adr, type, and num are set, ME
Issue M_READ (adrs, type, num). After the issuance, it waits for the device driver 21 to output the result. When the result is output, the content is received as a value from adr in the area of the memory 24 on the evaluation board 20 and is specified in the argument adrs of the shared work area 77. In the specified area.

FIG. 20 shows the ICE control layer 62 when writing contents to the debugged program 37 in the evaluation board 20.
FIG. 4 is an explanatory diagram showing the control contents of FIG. When the ICE control layer 62 calls a function using the function call code ICE_set_mem (adr, length, unit, image), the ICE control layer 62 sends a BIOS command “MEM_WRITE (adrs, t
ype, num)]. After issuance, shared work area 77
Is output to the device driver 21 as a value to be written.

The contents of the parameters of the BIOS command will be described. Parameter adrs is shared work area 7
7 indicates to which address of the work area 38 in the evaluation board 20 the parameter is to be written.
Indicates a writing unit. The parameter num indicates the number of words.
The word length of the “word” here means an acquisition unit in the evaluation board 20, and is set to a value obtained by dividing the write size specified by the argument length by the word length type when calling a function.

As described above, the parameters adr, type, n
When um is set, MEM_WRITE (ad
rs, type, num). The device driver 21 is an IC
In accordance with the BIOS command issued by the E control layer 62, the address setting ICE resources and the size setting ICE on the evaluation board 20
Set up resources and ICE resources for operation specification.

The reason for setting these ICE resources is as follows.
This is because the chip 23 interprets the contents described in these ICE resources as instructions from the host computer 1 and performs operations such as reading / writing of a memory and setting of a breakpoint. If the BIOS command MEM_READ (adrs, type, num) is issued, the device driver 21 first sets the parameter adrs
Is set to the address setting ICE resource, and second, the value set to the parameter num is set to the size setting ICE resource. Then, a read operation is set in the operation specifying ICE resource. Then, the ICE chip 23 stores the memory 24
The contents specified in the parameter adrs among the areas in
Only m is read out to the device driver 21. The device driver 21 outputs the read value to the ICE control layer 62 as status information of the memory 24 in the evaluation board 20.

When the BIOS command MEM_WRITE (adrs, type, num) is issued, the device driver 21 first sets the value specified in the parameter adrs in the address setting ICE resource, and secondly sets the value in the parameter num. The set value is set in the size setting ICE resource. Then, a write operation is set to the operation specifying ICE resource. When the device driver 21 outputs the value of the area image in the shared work area 77 passed from the monitor control layer 61, the ICE chip 23
In the area specified in parameter adrs among the areas in 4
The contents transferred from the device driver 21 are written by num.

The operation of the debugging device according to the above components will be described. FIG. 12 is a diagram illustrating an example of a message display performed by the user interface layer 50. When the debugging device is started, the user interface layer 50 firstly sets the reference
"* Hardware environment is set to {TARGET1}. {TARGET1} is a {monitor type} hardware environment. Is displayed, and a message "* Please enter a command" and a prompt are displayed, and a command input is awaited.

<Input of "readMEM 0x0100,16"> In this state, the operator types the keyboard 3 and reads "readMEM 0x0100,16".
When the command "100, 16" is input, the user interface layer 50 outputs the input command to the debug kernel layer 51, and entrusts interpretation and execution of the command. The command conversion routine 73 converts the input command into a function call code “TCI_read_MEM (0x0100,16, byte, imag
e)] and outputs it to the format conversion routine 74. The format conversion routine 74 rewrites the function call code into a format depending on the hardware environment. Since the hardware environment is a monitor type, the format "MON_re
ad_MEM (0x0100,16, byte, image)].

When the format conversion routine 74 has the function call code MO
When a function is called by N_get_mem (0x0100,16, byte, image), the monitor control layer 61 transfers the data of the prototype 30 to the serial transfer port 31- according to the flowchart of FIG.
The data is read out to the monitor control layer 61 in units of 8 bytes via the serial line 40 and the dedicated terminal 39. The read 8-byte data is accumulated in the area image in the shared work area 77. When such repetition is performed n times, data of the size specified by the argument length in the function call code is stored in the image area of the shared work area 77.

Here, the content stored in the shared work area 77 is “FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF ”, the user interface layer 50
The character string "* 0x0100,16 value of the hardware environment {TARGET1} is as follows" is displayed, the reading destination specified by the operator is echoed back, and the value held in the shared work area 77 is displayed. 『FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FFFF FF ”is displayed. After that, a message "* Please enter a command" is displayed and command input is waited.

<Input of "writeREG D1,03"> When the operator inputs a command of "writeREG D1,03" by typing on the keyboard 3, the user interface layer 50
The input command is output to the debug kernel layer 51, and interpretation and execution of the command are entrusted. The command conversion routine 73 stores 03 in the element of the register D1 of the array regs in the shared work area according to the input command, converts it to a function call code “TCI_write_REG (regs, mask)”, and Output. The format conversion routine 74 rewrites the function call code into a format depending on the hardware environment. Since the hardware environment is of the monitor type, the format "MON_write_REG (D1,
03)].

The format conversion routine 74 uses the function call code MO
When the function is called by N_write_REG (regs, mask), the monitor control layer 61 instructs the processor 33 to write the register and also sends the immediate value “03” to the serial transfer port 31−.
Output to the prototype 30 via the serial line 40-dedicated terminal 39. Since the register write has been ordered, the processor 33 writes the immediate value into the designated register D1.

Thereafter, when the processor 33 outputs a signal indicating normal writing to the monitor control layer 61, the monitor control layer 61 notifies the monitor interface 61 of normal end via the format conversion routine 74, the command conversion routine 73, and the command interpreter 72 to the user interface layer. Notify 50. The user interface layer 50 is “* Hardware environment @ TARGET
Echoed back with the message "D03 of 1 has been set to {D1}", and then prompt ">"
Is displayed and input from the operator is awaited.

<Input of "SetBP BP1,0x0123"> When the operator types the keyboard 3 and inputs a command of "SetBP BP1,0x0123", the user interface layer 50
Outputs the input command to the debug kernel layer 51 and entrusts interpretation and execution of the command. The command conversion routine 73 converts the input command into a function call code “TCI_SET_BP (BP1, 0x0123)” and outputs it to the format conversion routine 74. The format conversion routine 74 rewrites the function call code into a format depending on the hardware environment. Since the hardware environment is of the monitor type, it is rewritten to the format "MON_SET_BP (BP1,0x0123)" depending on the monitor type.

The format conversion routine 74 is executed when the function call code MO
When the function is called by N_SET_BP (BP1, 0x0123), the monitor control layer 61 notifies the setting of the breakpoint "BP1" at the address "0x0123" via the serial transfer port 31-serial line 40-dedicated terminal 39 via the prototype terminal. Output to 30. Since the setting of the breakpoint is instructed, the processor 33 sets the breakpoint BP1 at the address 0x0123.

Thereafter, when the processor 33 outputs a signal indicating a normal setting to the monitor control layer 61, the monitor control layer 6
1 notifies the user interface layer 50 of the normal end via the format conversion routine 74, the command conversion routine 73, and the command interpreter 72. When the normal setting is notified, the user interface layer 50 displays a message “The value {0x0123} has been set to“ BP1 ”of the hardware environment“ TARGET1 ””, and then displays the prompt “>”. , Waiting for input from the operator.

<Input of "RUN">
And the command "RUN" is input, the user interface layer 50 outputs the input command to the debug kernel layer 51, and entrusts interpretation and execution of the command. The command conversion routine 73 converts the input command into a function call code “TCI_RUN (0x0000)” and outputs it to the format conversion routine 74. The format conversion routine 74 rewrites the function call code into a format depending on the hardware environment. Since the hardware environment is a monitor type, the format "MON_RUN (0x000
0)].

The format conversion routine 74 is executed by the function call code MO
When a function is called by N_RUN (0x0000), the monitor control layer 61 informs the serial transfer port 31-serial line 40-dedicated terminal 39 that the debugged program 37 is to be executed.
And outputs the result to the prototype 30. Since execution of the program has been ordered, the processor 33 starts execution of the debugged program 37.

The processor 33 executes the debugged program 3
7, the prototype 30 starts operating. Then, with the breakpoint set earlier,
When the operation of the debugged program 37 is interrupted, the processor 33 notifies the monitor control layer 61 via the dedicated terminal 39, the serial line 40, and the serial transfer port 31 that the program has been interrupted.

When the processor 33 outputs a signal indicating operation interruption to the monitor control layer 61, the monitor control layer 61 sends the operation interruption to the user interface layer 50 via the format conversion routine 74, the command conversion routine 73, and the command interpreter 72. Notice. When the operation interruption is notified, the user interface layer 50 displays "* {TARGET1}".
Program aborted at {0x0123}. ] Is displayed, then the prompt ">" is displayed,
Waits for input from the operator.

<Operation at the time of input of selectTARGET> FIGS.
FIG. 26 is an explanatory diagram in which commands, function call codes, and exchange of state information are added to the internal hierarchy of the debugging device shown in FIGS. 7 and 8. Among them, FIG. 21 shows the flow of state information when a SelectTarget command that specifies a switching destination as a simulator type is input during the operation of a program in a monitor-type hardware environment. A function call code and a command used at this time are arranged in each hierarchy, and the flow between them is added by arrows. The processing contents of the command interpreter 72 related to the decoding of the selectTARGET command will be described with reference to the explanatory diagram of FIG. 21 and the flowchart of FIG.

It is assumed that during operation verification in a monitor-type hardware environment, the operator types a key on the keyboard 3 and inputs a selectTARGET command in which a switching destination is specified in the simulator. Step S in FIG.
At 81, the user interface layer 50 displays the prompt ">" shown in FIG. 12, and waits for a command input from the operator. When the operator inputs a debug command by the key type, the process proceeds to step S82,
The command interpreter 72 analyzes the input command. If the operation code is "selectTARGET" as a result of the analysis, step S83 becomes Yes and the process moves to step S84 to instruct the hardware environment (hereinafter referred to as "src_target") currently used for debugging to stop the program execution. In step S85, step S86, step S87, step S88, step S89, and step S90, the command interpreter 72
Command, copyREG command, copyBP command, copyINT
A command, a copyI / O command, and a copyTRACE_DATA command are automatically issued (see arrow y1 in FIG. 21).

When the copyMEM to copyTRACE_DATA commands are automatically issued, the command conversion routine 73 located in the lower layer converts the automatically issued commands into function call codes. The subcommand CopyMEM is transmitted by the command conversion routine 73 using TCI_get_mem (adr, length, unit, image).
Function call code and TCI_set_mem (adr, length, uni
t, image) (Fig. 21
Arrow y2). The command conversion routine 73 converts the subcommand CopyReg into a function call code called TCI_get_reg (regs, mask) and a function call code called TCI_set_reg (regs, mask).

The format conversion routine 74 converts the function call code converted by the command conversion routine 73 into a format depending on the hardware environment. Since the switching source is set to the monitor type and the switching destination is set to the simulator type, first, the style conversion routine 74 sets the TCI_get_mem
The function name “TCI_get_mem” in (adr, length, unit, image) is rewritten to a function name that specifies the switching source. Since the hardware environment of the switching source is a monitor type, it is rewritten to a function name "MON_get_mem" that clearly indicates the monitor type, and MON_get
_mem (adr, length, unit, image) is obtained (arrow y3 in FIG. 21).
reference).

Subsequently, the format conversion routine 74 executes TCI_set_
"TCI_set_mem" in mem (adr, length, unit, image)
Is rewritten to a function name that clearly indicates the switching destination.
Since the hardware environment of the switching destination is a simulator type, the function name "SIM_set_mem" that explicitly specifies the simulator type
Rewrite to The rewrite result is SIM_set_mem (adr, leng
th, unit, image) (see arrow y4 in FIG. 21). After rewriting the function name, the format conversion routine 74 calls the function using the function call code.

The format conversion routine 74 uses the function call code MO
When the function is called by N_get_mem (adr, length, unit, image), the monitor control layer 61 transfers the data of the prototype 30 to the serial transfer port 31- according to the flowchart of FIG.
The data is read out to the monitor control layer 61 in units of 8 bytes via the serial line 40 and the dedicated terminal 39. The read 8-byte data is accumulated in the area image in the shared work area 77. When such repetition is performed n times, data of the size specified by the argument length in the function call code is stored as state information in the image area of the shared work area 77 (see arrow T1).

After the storage, the format conversion routine 74 calls a function using the function call code SIM_set_mem (adr, length, unit, image). If called by the style conversion routine 74, the argument image in the shared work area 77
Is written as state information into the area after the start address adr in the memory simulation routine 96 (see arrow T2). The writing operation is performed by the size specified in the acquisition length length in the unit specified in the acquisition unit. Thus, the shared work area 7
7 to the memory simulation routine 96, the transfer of the memory contents from the prototype 30 to the simulator 10 is completed.

The same operation is performed by the copyREG command, copyBP command, copyINT command, copyI / O command, copyTRAC
This is performed for the E_DATA command. Then, the prototype 30
Is transferred to the simulator 10. As a result, the operating state of the prototype 30 up to that time is inherited by the simulator 10. After the inheritance, when the operation state information is set, the operation of the program is switched to the switching destination simulator 1
Control to restart at 0.

FIG. 22 shows the flow of state information when a SelectTarget command specifying an ICE destination is input during the operation of a program in the monitor-type hardware environment. This figure differs from FIG.
A function call code TCI_SET_mem (adr, length, unit, image) generated by the command conversion routine 73 because the selectTARGET command specifying the type hardware environment is input
Is converted into a format dependent on the ICE type by the format conversion routine 74, and the ICE control layer 62 is driven by this rewriting.

The driven ICE control layer 62 is
The content of the area image in which the status information is stored is written into the evaluation board 20 using the BIOS command (see arrow T4). In this way, the state information of the prototype 30 is transferred to the evaluation board 20, and the operation of the program of the prototype 30 up to that point is inherited on the evaluation board 20. FIG.
Shows the exchange of state information when a SelectTarget command specifying a switch destination as a monitor type is input during operation of a program in an ICE-type hardware environment. This drawing differs from FIG. 22 in that the relationship between the transfer source and the transfer destination is interchanged. That is, the transfer source is the ICE type and the transfer destination is the monitor type. Since the selectTARGET command specifying the ICE type hardware environment is input, the format conversion routine 74 rewrites the function call code TCI_GET_mem (adr, length, unit, image) generated by the command conversion routine 73 into a format dependent on the ICE type. By this rewriting, the ICE control layer 62 is driven, and the driven ICE control layer 62 transmits the status information in the evaluation board 20 to the BIO
The area image in the shared work area 77 using the S command
(See arrow T5).

On the other hand, the function call code TCI_SET_mem (adr, length, unit, image) generated by the command conversion routine 73
Is rewritten by the format conversion routine 74 into a format dependent on the monitor type. This rewriting drives the monitor control layer 61, and the driven monitor control layer 61
The contents of the area image in which the status information in 0 is stored are written into the prototype 30 via the serial line 40 (see arrow T6). In this manner, the state information of the evaluation board 20 is transferred to the prototype 30, and the operation of the program of the evaluation board 20 up to that point is inherited on the prototype 30.

FIG. 24 shows the flow of state information when a SelectTarget command specifying a switch destination as a simulator type is input during the operation of a program in an ICE type hardware environment. This drawing is different from FIG. 23 in that the transfer destination is changed from the monitor type to the simulator type. That is, the transfer source is the ICE type and the transfer destination is the simulator type. Since the selectTARGET command specifying the ICE type hardware environment is input, the function call code TCI_
The format conversion routine 74 rewrites GET_mem (adr, length, unit, image) to a format dependent on the ICE type. By this rewriting, the ICE control layer 62 is driven, and the driven ICE control layer 62 writes the state information in the evaluation board 20 into the area image in the shared work area 77 using the BIOS command (see the arrow T7). .

On the other hand, the function call code TCI_SET_mem (adr, length, unit, image) generated by the command conversion routine 73
Is rewritten by the format conversion routine 74 into a format dependent on the simulator type. By this rewriting, simulator 1
0 is driven and the contents of the area image in the evaluation board 20 where the state information is stored are stored in the memory simulation routine 9 therein.
Write 6 (see arrow T8). In this way, the state information of the evaluation board 20 is transferred to the simulator 10,
The operation of the program on the evaluation board 20 up to that time is inherited on the simulator 10.

FIG. 25 shows the flow of state information when a SelectTarget command specifying a monitor destination is input during the operation of a program in a simulator-type hardware environment. This drawing differs from FIG. 21 in that the transfer destination and the transfer source are interchanged. That is, the transfer source is a simulator type and the transfer destination is a monitor type. Sele specifying monitor type hardware environment
Since the ctTARGET command is input, the function call code TCI_GET_mem (adr, l
ength, unit, image) is rewritten by the format conversion routine 74 into a format dependent on the simulator type. By this rewriting, the simulator 10 is driven, and the driven simulator 10 writes its own state information in the area image in the shared work area 77 (see arrow T9).

On the other hand, the function call code TCI_SET_mem (adr, length, unit, image) generated by the command conversion routine 73
Is rewritten by the format conversion routine 74 into a format dependent on the monitor type. By this rewriting, the monitor control layer 61 is driven, and the driven monitor control layer 61 writes the contents of the stored area image into the prototype 30 (see the arrow T10). In this way, the state information of the simulator 10 is transferred to the prototype 30 and the simulator 10
The operation of the program is inherited on the prototype 30.

FIG. 26 shows the flow of state information when a SelectTarget command specifying an ICE-type switching destination is input during operation of a program in a simulator-type hardware environment. This drawing differs from FIG. 22 in that the transfer destination and the transfer source are interchanged. That is, the transfer source is a simulator type and the transfer destination is an ICE type. SelectTAR specifying ICE type hardware environment
Since the GET command has been input, the function call code TCI_GET_mem (adr, lengt) generated by the command conversion routine 73
h, unit, image) is rewritten by the format conversion routine 74 into a format dependent on the simulator type. With this rewrite,
The simulator 10 is driven, and the driven simulator 10 writes its own state information in the area image in the shared work area 77 (see the arrow T11).

On the other hand, the function call code TCI_SET_mem (adr, length, unit, image) generated by the command conversion routine 73
Is converted to a format dependent on the ICE type by the format conversion routine 74. By this rewriting, the ICE control layer 62 is driven, and the driven ICE control layer 62
Is written into the evaluation board 20 (see arrow T12). In this way, the state information of the simulator 10 is transferred to the evaluation board 20, and the operation of the program of the simulator 10 up to that point is inherited on the evaluation board 20.

Arbitrary switching of the hardware environment between the monitor type, the ICE type, and the simulator type is realized by the transfer of the state information shown in FIGS. Subsequently, the remaining components of the target interconnect layer 52 (the work area content analysis module 7)
5) will be described. The work area content analysis module 75 divides a memory area of each hardware environment into an area where breakpoints can be set and an area where breakpoints cannot be set, and manages the breakpoint management function (1) for each hardware environment. ), A trace data storage size management function (2) that manages the memory size that each hardware environment can use for storing trace data for each hardware environment, and each hardware environment Interrupt occurrence condition management function (3) that manages whether or not it has the ability to monitor failure for each hardware environment
And an I / O mapping information management function (4).

Work area content analysis module 7
5 has a breakpoint management function (1). This is because when a breakpoint is performed by writing an interrupt instruction, the possibility of setting a breakpoint differs between the ICE type, monitor type, and simulator type. Because it is assumed. That is, when a predetermined area in the memory space that is configured by the RAM at the switching source and has the breakpoint set is configured by the ROM at the switching destination, it is impossible to set the breakpoint at the switching destination. If a breakpoint that can be set at the switching source becomes impossible at the switching destination in this way, the breakpoint becomes invalid as soon as the hardware environment is switched unless the operator is notified in advance. This phenomenon occurs. When the breakpoint is invalidated in accordance with the switching of the hardware environment as described above, the operator may misunderstand the breakpoint as a failure, which may cause distrust. Therefore, the work area content analysis module 75 manages in which area in the memory a breakpoint can be set and in which area a breakpoint cannot be set. FIG. 28A shows an example of management information used for breakpoint management. START_ADDR1 to E in the figure
ND_ADDR1, START_ADDR2 to END_ADDR2, START_ADDR
3 to END_ADDR3 "respectively indicate the start address and the end address of the area in which a breakpoint can be set. “VALID_AREA1”, “VALID_AREA2”,
“VALID_AREA3” indicates a label attached to an area where a breakpoint can be set.

The reason why the work area content analysis module 75 has the trace data storage size management function (2) is that the memory size that can be allocated to the storage of trace data is of the monitor type, ICE type, This is because it is assumed that there is a difference between the simulator types. That is, when the switching source is a simulator and the switching destination is a monitor, it is impossible to transfer all trace data accumulated on the switching source side to the switching destination as it is. During the transfer, the memory at the switching destination overflows, and a part of the trace data accumulated so far is lost. Unless the operator is notified in advance of the possibility of such a loss, the operator may have a distrust of seeing that the trace data is lost without any warning. Therefore, the work area content analysis module 75 manages the memory size that can be allocated to the accumulation of trace data for each hardware environment. FIG. 28B is a diagram illustrating an example of management information for managing a memory size for storing trace data. "Target1" and "tar"
"get2" is the identifier of each hardware environment.
“E_FOR_TRACE_DATA MAX 16 Kbytes” indicates that the memory size that can be allocated to the accumulation of trace data in each hardware environment is 16 Kbytes.

The reason why the work area contents analysis module 75 has the interrupt generation condition management function (3) is as follows.
Monitor type, ICE type,
This is because it is assumed that there is a difference between the simulator types. For example, it is assumed that the interrupt generation condition is an instruction execution time, and the switching source and the switching destination are a simulator and a monitor. In this case, the switching source side can monitor the satisfaction of the interrupt occurrence condition since the instruction execution count can be realized by software. On the other hand, on the switching destination side, counting of instruction execution cannot be realized unless special hardware is modified. If such a modification has not been made, it will not be possible to monitor the satisfaction of the interrupt occurrence condition at the switching destination.
At the switching destination, a phenomenon occurs in which the interrupt occurrence condition does not occur no matter how long it stands. As described above, if the interrupt occurrence condition is not satisfied, the operator must be notified in advance, or the operator may be distrusted. Therefore, the work area content analysis module 75 manages the presence or absence of the monitoring capability of the interrupt occurrence condition for each hardware environment. FIG. 28C is a diagram showing an example of management information for managing the monitoring capability for each hardware environment. In the figure, "target1" and "target2" are identifiers of each hardware environment, and "CYCLE_NUMBER_COUNT VALID" indicates that the number of processor cycles can be counted in the hardware environment of the corresponding identification information. , "CYCLE_
“NUMBER_COUNT INVALID” indicates that it is impossible to count the number of cycles of the processor in the hardware environment of the corresponding identification information.

Next, the reason why the work area content analysis module 75 has a function of managing I / O mapping information is as follows.
This is because it is assumed that there is a difference between the type and the simulator type. That is, it is assumed that the switching destination is the simulator and the switching source is the monitor. In this case, at the switching source, the progress of hardware adjustment etc. is delayed,
Although only a part of the I / O is operating, all the peripheral I / Os can be operated on the switching destination side because the execution environment is virtually created by software. If the I / O state information is transferred in this state, a partially invalid value is stored in the peripheral I / O of the switching destination. Therefore, the work area content analysis module 75 individually manages which peripheral I / O is operable and which peripheral I / O is inoperable for each hardware environment.

Work area content analysis module 7
FIG. 29 shows an example of I / O mapping information managed by
Shown in The I / O mapping information is information indicating what value should be set in the hardware environment of the switching destination when the value of the peripheral I / O register does not exist in the hardware environment of the switching source. "I / O_REGISTER_A" in the figure
`` DDR1 '' indicates the first peripheral I / O register, and `` PSW = STA
“TUS1 0x1F” indicates that “0x1F” is set in the first peripheral I / O register when the PSW register value of the processor is “STATUS1” in the hardware environment of the switching destination. “PSW = STATUS2 0x2A” indicates that if the value of the PSW register of the processor is “STATUS2” in the hardware environment of the switching destination, “0x2A” is set in the first peripheral I / O register. . In addition, "PSW = STATUS
“30x3B” indicates that “0x3B” is set in the first peripheral I / O register when the value of the PSW register of the processor is “STATUS3” in the hardware environment of the switching destination.

Next, an extended command of the selectTARGET command will be described. FIG. 10 shows three typical extended commands. SelectTA here
The extension of the RGET command means that a predetermined condition is given to the issuance of the selectTARGET command, and the three commands in FIG. 10 have different conditions for issuing the selectTARGET command.

The IFBreak command instructs the hardware environment currently used for debugging to execute the program to be debugged, and if the execution is stopped by the breakpoint specified by BreakNO, the hardware Select to switch hardware environment
Issue TARGET automatically. The TargetASSIGN command instructs the target interconnect layer 52 to switch the hardware environment according to the assignment specified by TABLE * in the operand. FIG. 11 is an example of a table specified by the TargetASSIGN command, in which the format is specified so as to instruct the target interconnect layer 52 to assign hardware environment switching. In this format, it is possible to specify a hardware environment for which switching is desired for each set of a start address and an end address. In FIG. 11, a maximum of n sets of combinations of the start address and the end address can be listed, and a different hardware environment can be defined as a switching destination for each set.

The Switch () command is used in the hardware environment t
This command instructs the target interconnect layer 52 to switch the hardware environment according to the value of the variable var of arget0. case '* 1' assumes that the value of the variable var is * 1, in which case the hardware environment target
1 is activated. case '* 2' assumes that the value of the variable var is * 2, in which case the hardware environment
target2 is activated.

Next, the processing of the command interpreter 72 when three extended commands of the selectTARGET command shown in FIG. 10 are input will be described with reference to the flowcharts of FIGS. It is assumed that the operator has input a “TargetASSIGN” command to the user interface layer 50. In this case, step S83 in FIG. 30 is No, and the process shifts to step S71 in FIG. Step S
At 71, the command interpreter 72
Determine whether it is TargetASSIGN. In this case, since the operation codes of the commands match, the TA
Make the table specified by BLE * resident. After being resident, in step S73, each start address in the table
Set a breakpoint at [i] (i = 1, 2,... n). After the setting, the program to be debugged is executed in step S74. When the program is executed, it is monitored in step S75 whether or not the program to be debugged has been broken. It is determined which one corresponds. If it is determined that any of the above conditions is satisfied, a SelectTARGET for automatically switching to the hardware environment corresponding to the start address [i] is automatically issued in step S77.

Next, it is assumed that the operator inputs an “IFBreak” command to the user interface layer 50. In this case, step S83 in FIG.
71, but also in step S71 of FIG.
No, the process moves to step S91. Step S91
In, the command interpreter 72 determines whether the operation code of the input command is IFBreak. In this case, the result is Yes, and the process shifts to step S92 to make “BreakNO” and “SelectTARGET target” specified by the operands resident. Thereafter, the program to be debugged is executed in step S93. When executed, step S
At 94, it is determined whether or not the program to be debugged has broken. If a break has occurred, the address at which the break has occurred is set at the breakpoint [i] (i = 1, 2,
It is determined which BreakNO corresponds to 3 ... n). When a corresponding one is determined, SelectTARGET is automatically issued in step S97.

It is assumed that the operator has input a "Switch (var)" command to the user interface layer 50. In this case, step S83 in FIG.
71, but also in step S71 of FIG.
No, the process moves to step S91. Step S91
Is also No, and the process proceeds to step S100. In step S100, it is determined whether or not the operation code is Switch (var).
Move to 1. In step S101, the command interpreter 72 sets the variable “var” to the memory address mem_adr (va
r), and instructs the debug core layer 51 to read the memory data of the variable adr (var) to the hardware environment of “target0” specified in step S102 after the conversion. After the instruction, it is determined whether the memory data read in step S103 matches any of the contents of casei (i = 1, 2, 3, 4, 5,... N). To switch to TARGET [i]
Issue tTARGET automatically.

As described above, according to the present embodiment, select
With the simple operation of inputting the TARGET command, the operator can switch the hardware environment as desired in any situation during debugging. Therefore, it is possible to investigate the cause of the bug occurrence in another hardware environment without having to worry about reproducing the situation where the bug occurred in another hardware environment, and to use valuable development time effectively be able to.

In particular, if the debug device in which the bug has occurred is a monitor with a poor analysis function, the cause of the bug should be investigated using an IC.
The execution environment can be switched to an abundant analysis function such as E or a simulator, and the time required to elucidate the cause is further reduced. Although the description has been given based on the above embodiment, it is merely presented as an example of a system in which the best effect can be expected at present. The present invention can be modified and implemented without departing from the gist thereof. It goes without saying that the present invention can be applied to any system as long as it is intended to switch the hardware environment. The following changes (a), (b), (c),... Are possible.

(A) In this embodiment, the supervisor program is arranged in the memory. However, a configuration in which the supervisor program exists in the debug kernel layer 51 may be adopted. The target interconnect layer 52 may be configured to exist in the debug kernel layer 51. (B) In the above description, the case where the ICE type hardware environment has a breakpoint, a trace setting, and an interrupt setting is described. When is not available, only the setting information of available functions may be set as the switching destination.

(C) In the above description, the entire contents of the in-target work area 38 are transferred to the switching destination.
The transfer load may be reduced by transferring only the change from the previous transfer. In this case, a backup of the contents of the stack area and the external variable area is stored in the debug kernel layer 51 or the target interconnect layer 52. If the hardware environment switching is instructed by the input of the selectTARGET command, the storage contents that have been backed up and the storage contents to be transferred are compared to detect the changed part, and the changed part is detected. Only transfer. In this case, the changed memory area may be stored, but an area including the changed memory area may be stored.

(D) The application example in which the changed memory area is transferred in a lump when the hardware environment is switched in (c) has been described. However, each time the hardware environment changes the memory content, the changed content is changed. May be transferred to another hardware environment. In this case, since the transfer of the memory contents does not occur when one hardware environment is switched to another hardware environment, the hardware environment is switched more quickly.

(E) In the above description, the changed memory area is stored and the stored memory area is transferred to the switching destination. However, the changed register value is stored. The stored register value may be transferred from the switching source to the switching destination. In this case, only the changed register values are transferred, so that the hardware environment switching is faster than in the case where all registers are transferred.

(F) The command for switching the hardware environment at the time of the break of the debugged program has been described.
When the hardware environment can use the area break, the hardware environment may be switched by the area break. Here, the area break refers to a function of stopping a running program when a hardware environment accesses a certain address area. In this case, it is checked which instruction read destination of the current program is within the range of the start address and the end address, and the program corresponding to the range is executed.

(G) In the present embodiment, the command for switching the hardware environment according to the value of the variable has been described. However, the command for switching the hardware environment according to the value of the parameter is provided to switch the hardware environment. May be realized. (H) A hardware environment switching instruction, an instruction to monitor the generation of an interrupt signal, and an instruction of a hardware environment to be specified as a switching destination are arranged in a command, and the command interpreter 72 interprets these instructions. The decryption may be performed, and the hardware environment may be switched based on the decryption result. By switching the hardware environment by using the command of the configuration, the operator can observe the operation of the program to be debugged when a specific interrupt signal is generated in another hardware environment.

(I) An instruction to switch the hardware environment, an instruction to monitor rewriting of the contents of a predetermined memory or register in the hardware environment, and a second instruction to be designated as the switching destination
May be arranged in a command, the command interpreter 72 decodes these instructions, and the hardware environment may be switched based on the result of the decoding. The present debugging apparatus switches the hardware environment by using the command having such a configuration, so that the operator can observe the operation of the program to be debugged when the specific memory or the register is rewritten in another hardware environment. .

(J) A command for switching the hardware environment and a correspondence table indicating which scheduled execution times are associated with the plurality of hardware environments by the operator are arranged in the command, and these instructions are transmitted to the command interpreter 72. May be decoded, and the hardware environment may be switched based on the decoding result. (K) Although the configuration in which the debug information is arranged on the memory 24 and the memory simulation routine 96 has been described, these may be arranged on the debug kernel layer 51 to the target interconnect layer 52. In such an arrangement, the target dependent layer 53
The process of reading debug information from the monitor control layer 61, the ICE control layer 62, and the simulator in the inside becomes substantially unnecessary, and the function call code TCI_get_
It is not necessary to issue mem, TCI_get_reg, and TCI_get_BP.

[0140]

As described above, the debugging device tests an embedded program developed for a predetermined target machine on any one of the target machine, the emulator machine of the target machine, and the software simulator of the target machine. A debug apparatus for operating and verifying the operation of the target machine, wherein the target machine, the emulator machine, and the software simulator have operation state information indicating an operation state of the embedded program, and input / output the operation state information in a specific format. Operation verification target storage means for storing any one of a target machine, an emulator machine of the target machine, and a software simulator of the target machine as a target of operation verification, and accepting a command input by an operator Receiving means, detecting means for detecting if a predetermined instruction is included in the command received by the receiving means, and detecting the operation verification target stored in the operation verification target storage means when the predetermined instruction is detected. The target machine, the emulator machine of the target machine, and the software simulator of the target machine, which are different from the target of the switching source operation verification, are designated as the switching source operation verification target and based on the command received by the receiving means. Designation means for designating an object, read means for reading the operation state information from the switching source operation verification target when the switching source and the switching destination are specified, and the read operation state information in the format of the switching destination operation verification object A converting means for converting the operating state information into the switching destination format, and converting the operating state information having the converted format into the switching destination format. A setting unit for setting the verification target; and an operation restarting unit for controlling the operation of the embedded program to be restarted in the switching operation verification target when the operation state information is set. Since the debugged program can be debugged while switching the environment, the program can be executed in such a way that the disadvantages of each hardware environment are compensated for by the advantages of the other hardware environment, and an efficient program can be created. You can debug.

For example, a certain hardware environment is constituted by a simulator, and requires a huge amount of execution time as compared with a hardware environment using a hardware environment of a prototype while having abundant analysis functions. In this case, the debugged program can be executed halfway in the hardware environment of the prototype, and the essential bug cause analysis can be performed using the abundant functions of the simulator.

If it is desired to use the analysis function of the simulator when investigating the cause of a bug that occurs very frequently, once for every several tens or hundreds of executions of the program to be debugged, it is normally necessary to execute the program to be debugged by the simulator. The execution needs to be repeated tens or hundreds of times. However, by using the hardware environment switching described above, it is possible to make the hardware environment of the prototype machine repeat the program to be debugged tens or hundreds of times, and use the simulator only to find the cause of the bug. it can. By applying the switching of the hardware environment in this way, the program to be debugged can be executed several tens or hundreds of times quickly, and abundant analysis functions can be used, so that the time required for the debugging work is greatly reduced. .

Further, since this switching is a simple operation of issuing a command, the operator can perform the switching as desired in any situation during debugging. Therefore, it is possible to investigate the cause of the bug occurrence in another execution environment without having to worry about reproducing the situation where the bug occurred on another debug device, and to use valuable development time effectively. it can.

The switching is performed without the trouble of setting the value held at the time of the bug occurrence in another hardware environment and re-executing the microcomputer or microprocessor program from the beginning. Effective use of development time. Further, the target machine performs input / output of operation state information in a first format,
The emulator machine performs input / output of operation state information in a second format, and the software simulator includes:
The input / output of the operation state information is performed in a third format, and the conversion means converts the operation state information having the first format into the third format if the switching source is the target machine and the switching destination is the software simulator. And a second converter for converting the operating state information having the second format into a third format if the switching source is an emulator machine and the switching destination is a software simulator, The setting means sets the operation state information in the software simulator when the operation state information is converted into the third format.
You may comprise so that a setting part may be provided. In this configuration,
Even if the input / output of the operation state information is performed using three modes, the target machine and the emulator machine can exchange the operation state information with each other.

Further, in the debugging device configured as described above, if the switching source is a software simulator and the switching destination is a target machine, the converting means converts the operating state information having the third format into the first format. And a fourth conversion unit for converting the operating state information having the third format into the second format if the switching source is a software simulator and the switching destination is an emulator machine, A setting unit configured to set the operation state information in the target machine if the operation state information is converted to the first format; and to set the operation state if the operation state information is converted to the second format. A third setting unit for setting information in the emulator machine may be provided. With this configuration, the target machine and the emulator machine can exchange the operating state information with each other even if the input and output of the operating state information are performed using three modes.

If the switching source is the target machine and the switching destination is the emulator machine, the conversion means controls the first conversion unit to convert the operation state information having the first format into the third format. After the conversion, a first control unit that controls the fourth conversion unit to convert the operation state information having the third format into the second format, and that the switching source is the emulator machine and the switching destination is the target machine If so, the second converter is controlled to convert the operating state information having the second format into the third format, and after the conversion, the third converter is controlled to control the operating state having the third format. And a second control unit configured to convert the information into the first format. With this configuration, the target machine and the emulator machine can exchange the operating state information with each other even if the input and output of the operating state information are performed using three modes.

A serial transfer port connected to a processor inside the emulator by a first line for inputting / outputting operating state information converted into a first format, an in-circuit emulator machine inside a target machine, and a second line And an emulator machine driver unit for inputting and outputting the operation state information converted into the second format.

A storage resource management means for classifying and managing registers and memories of the target machine, emulator machine and software simulator into those storing valid values and those storing invalid values, When the operating state information is read from the switching source operation verification target by the reading unit, the rewriting unit rewrites an invalid value included in the read operating state information to a default value by referring to the management content of the storage resource managing unit. The conversion means may be configured to convert the operation state information in which the invalid value has been rewritten to the default value into a format of the switching destination operation verification target. According to this configuration, when the program developer switches the hardware environment, the invalid value included in the operation state information is rewritten to the default value.
You can debug programs smoothly.

In addition, even if the mounting state of the register is different between the switching destination and the switching source, a predetermined value can be set in the difference. Therefore, debugging of a program to be debugged including control of the peripheral device register can be performed. In the memory of the target machine, emulator machine, and software simulator, an area where breakpoints can be set,
The setting possible / impossible area management means which divides and manages the area into impossible areas, and when the operation state information is converted, the break point is similarly set in the switching operation verification target by referring to the setting possible / impossible area management means. A judgment means for judging whether or not a breakpoint can be set at a switching destination operation verification target and a notifying means for notifying an operator that a breakpoint cannot be set at a switching destination when a breakpoint cannot be set at a switching destination are added to the above configuration. May be.

According to this configuration, if some of the breakpoints that have been used at the switching source until now become unusable at the switching destination, it is determined by the program that the breakpoint cannot be used after the switching. Let developers know. Here, the maximum amount management means for managing the maximum amount of addresses that each operation verification target can store, and when the operation state information is converted, the maximum amount management means refers to the maximum amount of addresses in the switching destination operation verification target. Recognition means for recognizing the storage amount of the instruction address group, and, when recognizing the storage amount, notification means for notifying the operator of the difference between the address storage amount of the switching destination operation verification target and the address storage amount of the switching destination operation verification target May be added to the above configuration.

According to this configuration, when a part of the trace data which has been continuously accumulated on the switching source side is lost at the switching destination, the program developer can be informed that the missing part is to be noted. it can.

[Brief description of the drawings]

FIG. 1 is an external view of a debugging device according to an embodiment.

FIG. 2 is a configuration diagram illustrating a hardware configuration of a debugging device according to the present embodiment.

FIG. 3 is a diagram illustrating a configuration of a monitor-type hardware environment.

FIG. 4 is a diagram showing a configuration of an ICE type hardware environment.

FIG. 5 is a diagram illustrating a configuration of a simulator-type hardware environment.

FIG. 6 is a diagram showing a hierarchical structure of the debugging device.

FIG. 7 is a diagram showing a hierarchical structure inside an application layer 11;

FIG. 8 is a diagram showing components included in each layer inside the application layer 11.

FIG. 9 is a system diagram of a debug command that can be used in the debug device of the present embodiment.

FIG. 10 is a diagram showing an extended command of a selectTARGET command that can be used in the debugging device of the present embodiment.

FIG. 11 is a diagram showing a format of a table that specifies hardware environment switching.

FIG. 12 is a display example of the display 2 at the time of debugging work by the user interface layer 50.

FIG. 13: copyMEM command before conversion to copyTRACE_DATA
Command and the converted function call code TCI_get_mem (adr,
length, unit, image) ~ TCI_get_TD (adr, length, unit, ima
ge) is a diagram showing a correspondence relationship. FIG.

FIG. 14 is a diagram showing how all the function call codes shown in FIG. 13 have been rewritten.

15 is an explanatory diagram showing a communication protocol between the monitor control layer 61 and the prototype 30 when reading the contents of the in-target work area 38, and a packet used for the communication protocol. FIG.

FIG. 16 is an explanatory diagram showing a communication protocol performed between the monitor control layer 61 and the prototype 30 when writing contents to the in-target work area 38, and a packet used for the communication protocol.

FIG. 17 is a flowchart of a process performed by the monitor control layer 61 when reading the contents of the in-target work area 38.

FIG. 18 is a flowchart of a process performed by a monitor control layer 61 when writing contents to a work area 38 in a target.

FIG. 19 is an explanatory diagram of a process performed by the ICE control layer 62 and the ICE device driver when reading the contents of the ICE type hardware environment.

FIG. 20 is an explanatory diagram of processing performed by the ICE control layer 62 and the ICE device driver when writing content to the ICE type hardware environment.

FIG. 21 is an explanatory diagram showing how state information is transferred from a monitor type to a simulator type.

FIG. 22 is an explanatory diagram showing how state information is transferred from a monitor type to an ICE type.

FIG. 23 is an explanatory diagram showing how state information is transferred from the ICE type to the monitor type.

FIG. 24 is an explanatory diagram showing how state information is transferred from the ICE type to the simulator type.

FIG. 25 is an explanatory diagram showing how state information is transferred from a simulator type to a monitor type.

FIG. 26 is an explanatory diagram showing how state information is transferred from a simulator type to an ICE type.

FIG. 27A shows an example of a breakpoint setting destination address. FIG. 3B is a diagram illustrating an example of an interrupt signal generation requirement. FIG. 3C is a diagram illustrating an example of trace data.

FIG. 28A illustrates an example of management information for a breakpoint management function (1). FIG. 4B is a diagram illustrating an example of management information for a trace data storage size management function (2). (C) is a diagram showing an example of management information for the interrupt generation condition management function (3).

FIG. 29 is a diagram showing an example of management information for a management function (4) of I / O mapping information.

FIG. 30 is a flowchart showing the processing contents of the debug device when executing a selectTARGET command according to the present embodiment.

FIG. 31 is a flowchart showing the processing contents of the debugging device when a TargetASSIGN command of the present embodiment is executed.

FIG. 32 is a flowchart showing the processing contents of the debug device when executing the IFBreak command of the present embodiment.

FIG. 33 is a flowchart showing the processing contents of the debug device when executing a switch (var) of the embodiment.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Host computer 2 Display 3 Keyboard 10 Simulator 11 Application layer 12 Operating system layer 13 BIOS layer 14 Physical layer 20 Evaluation board 21 Device driver 22 Control board 24 Memory 25 Register group 26 Supervisor program 27 Debug information area 28 Parallel line Reference Signs List 30 prototype 31 serial transfer port 33 processor 34 memory 35 peripheral I / O register group 36 monitoring program 37 program to be debugged 38 work area in target 39 dedicated terminal 40 serial line 50 user interface layer 51 debug core layer 52 target interconnection layer 53 Target dependent layer 61 Monitor control layer 62 ICE control layer 72 Command interpreter 73 Command conversion routine 74 Formula conversion routine 75 Work area content analysis module 77 Shared work area 95 Processor simulation routine 96 Memory simulation routine 97 Register simulation routine

Claims (17)

[Claims] 1. A test operation of an embedded program developed for a predetermined target machine is performed on one of the target machine, an emulator machine of the target machine, and a software simulator of the target machine, and the operation of the test program is verified. A debugging device, wherein the target machine, the emulator machine, and the software simulator have operation state information indicating an operation state of the embedded program, and perform input and output of the operation state information in a specific format. An operation verification target storage unit for storing any one of a machine emulator machine and a software simulator of the target machine as an operation verification target; a reception unit for receiving a command input by an operator; and a reception unit for receiving Detecting means for detecting if a predetermined instruction is included in the command, and specifying the operation verification target stored in the operation verification target storage means as a switching source operation verification target when the predetermined instruction is detected, Designation means for designating a target machine, an emulator machine of the target machine, and a software simulator of the target machine that are different from the switching source operation verification target as the switching destination operation verification target based on the command received by the reception means; Reading means for reading operating state information from the switching source operation verification target when the source and the switching destination are specified; converting means for converting the read operation state information into a switching destination operation verification target format; Setting means for setting, when the information is converted into the switching destination format, the operation status information whose format has been converted to the switching destination operation verification target; When the operation status information is set, the debugging apparatus characterized by comprising an operation resuming means for controlling to restart the operation of the built-in program in the switching destination operation verified. 2. The target machine performs input and output of operation state information in a first format, the emulator machine performs input and output of operation state information in a second format, and the software simulator includes: The input / output of the operation state information is performed in a third format, and the conversion unit converts the operation state information having the first format into the third format if the switching source is the target machine and the switching destination is the software simulator. And a second converter for converting the operating state information having the second format into a third format if the switching source is an emulator machine and the switching destination is a software simulator, The said setting means is provided with the 1st setting part which sets operation state information to a software simulator, when operation state information is converted into the 3rd format. 1 debug device described. 3. The conversion device according to claim 1, wherein the conversion unit converts the operation state information having the third format into the first format if the switching source is a software simulator and the switching destination is a target machine. And a fourth conversion unit configured to convert the operation state information having the third format into the second format when the switching source is a software simulator and the switching destination is an emulator machine. A second setting unit that sets the operation state information to the target machine if the state information is converted to the first format; and sets the operation state information to the emulator machine if the operation state information is converted to the second format. 3. The debugging device according to claim 2, further comprising a third setting unit that performs setting. 4. The debugging device according to claim 1, wherein the conversion unit controls the first conversion unit if the switching source is the target machine and the switching destination is the emulator machine, and outputs the operating state information having the first format. And a first control unit that controls the fourth conversion unit to convert the operation state information having the third format into the second format, and that the switching source is an emulator machine and the conversion is performed. If the destination is the target machine, the second conversion unit is controlled to convert the operation state information having the second format into the third format.
The debugging device according to claim 3, further comprising: a second control unit that controls the third conversion unit to convert the operation state information having the third format into the first format. 5. A debugger, comprising: a serial transfer port connected to a processor in an emulator via a first line for inputting / outputting operation state information converted into a first format; and an in-circuit emulator in a target machine. 5. The debugging device according to claim 4, further comprising: an emulator machine driver unit connected to the machine via a second line and configured to input and output the operation state information converted into the second format. 6. The debugging device according to claim 5, wherein the operation state information includes a held value of a register in an operation verification target and a held value of a memory. 7. The value held in the memory includes a breakpoint for instructing the processor to stop operation, trace data including an address of an executed instruction among instructions constituting an embedded program, and a predetermined condition determined by an operator. 7. The debug device according to claim 6, wherein the debug device has any one of interrupt setting information for generating an interrupt signal when the condition is satisfied. 8. The debugging device further manages registers and memories of the target machine, the emulator machine, and the software simulator by classifying the registers and the memory of the target machine, the emulator machine, and the register of a valid value into a type storing a valid value and a type storing an invalid value. When the operating state information is read from the switching source operation verification target by the reading means, the invalid value included in the read operating state information is referred to by referring to the management contents of the storage resource managing means. And a rewriting means for rewriting the operation state information to a default value, wherein the conversion means converts the operation state information in which the invalid value has been rewritten to the default value into a format of a switching destination operation verification target. Debug device. 9. The setting device according to claim 1, wherein the debug device further manages the memory of the target machine, the emulator machine, and the software simulator by dividing the memory into areas where breakpoints can be set and areas where breakpoints cannot be set. When the operation state information is converted, the determination unit determines whether the breakpoint can be similarly set in the switching destination operation verification target with reference to the setting possibility area management unit, 8. The debugging device according to claim 7, further comprising: a notifying unit that notifies an operator that a breakpoint cannot be set at a switching destination when a breakpoint cannot be set at an operation verification target. 10. The debugging device further comprises: a maximum amount management means for managing a maximum amount of addresses that can be stored by each operation verification target; and, when the operation state information is converted, a maximum amount of addresses in the maximum amount management means. A recognizing means for recognizing an accumulation amount of the instruction address group in the switching destination operation verification target by referring to the address storage amount of the switching destination operation verification target and an address accumulation amount of the switching destination operation verification target when recognizing the accumulation amount; The debugging device according to claim 7, further comprising: a notification unit configured to notify an operator of the difference. 11. The debugging device further comprises: a monitoring capability management unit that manages, for each operation verification target, whether each operation verification target has a capability of monitoring whether an interrupt generation condition is satisfied or not satisfied; When converted into the switching destination format, the switching destination operation verification target determines whether or not the switching target operation verification target has the ability to monitor the satisfaction of the condition, and if the switching destination operation verification target does not have the capability, the switching destination operation verification target includes , Established,
8. The debugging device according to claim 7, further comprising: a notifying unit that notifies an operator that there is no ability to monitor the failure. 12. When the command received by the receiving unit does not include a predetermined instruction, the debugging device decodes the command if the command includes an instruction to monitor the generation of an interrupt signal. First decoding means for decoding, a signal number of an interrupt signal generated in the command, and second decoding means for decoding a switching destination corresponding to the number if the command is included, and an instruction for monitoring is decoded. Then, the monitoring means for monitoring the generation of the interrupt signal in the operation verification target of the switching source currently being operated, and, when the monitored interrupt signal is generated, whether the interrupt signal matches the decoded signal number. 8. The debugging device according to claim 7, further comprising: a determination unit configured to determine the operation state information from the switching source operation verification target when the signal matches the signal number. 13. The debugging device according to claim 1, wherein the command received by the receiving unit does not include a predetermined instruction, and the command includes an instruction to monitor rewriting of the contents of the predetermined memory or the register in the command. For example, a first decoding means for decoding the command, a second decoding means for decoding if the command contains an instruction of a switching destination to be switched when the content rewriting occurs, and a command for monitoring rewriting. Monitoring means for monitoring rewriting of the contents of a predetermined memory or a register in the operation state information when the instruction is included, wherein the readout means includes: 8. The device according to claim 7, wherein the conversion unit converts the read operation state information into a format of a switching destination operation verification target included in the command. Grayed apparatus. 14. The debugging device further comprises: first decoding means for decoding, if the command received by the receiving means does not include a predetermined instruction, a switching instruction of an operation verification target if the command is included, If the command includes an assignment table indicating which operation verification target should be allocated to a plurality of areas in the embedded program, the second decoding means for decoding this command, A third decoding means for decoding the instruction to detect the movement timing of the command if the command is included in the same command; and Monitoring means for monitoring the movement between the areas, wherein the specifying means disconnects the operation verification target associated with the area when the movement between the plurality of areas is confirmed during the monitoring of the movement. A switching destination defining unit for defining a switching destination operation verification target, wherein the reading unit reads the operation state information from the switching source operation verification target when the switching destination operation verification target is defined. 7. The debugging device according to 7. 15. The debugging device further comprises: first decoding means for decoding, when a command received by the receiving means does not include a predetermined instruction, an operation verification target switching instruction if the command is included, A second decryption means for decrypting, if the command includes an assignment table indicating which operation verification target has been assigned to a plurality of value ranges that can be taken by variables used in the embedded program, the command; If the command includes an instruction to refer to a change in the value of a predetermined variable in the program, a third decryption unit that decrypts the instruction. If the instruction to reference the change is decrypted, a register or a register corresponding to the variable is read. Is a multi-value range in which the values held in the memory are divided.
A determination unit that determines which one of the areas corresponds to, the designation unit includes a switching destination specifying unit that defines an operation verification target associated with the determined area as a switching destination operation verification target; 8. The debugging device according to claim 7, wherein, when a switching destination operation verification target is specified, the operation state information is read from the switching source operation verification target. 16. The method according to claim 16, wherein when the command received by the receiving unit does not include a predetermined instruction, the debugger determines which operation verification target the plurality of value ranges that the parameters used in the embedded program can take. If the command contains an assignment table indicating whether or not the command has been assigned, first decoding means for decoding the command, and if the command contains an instruction to refer to the value of a predetermined parameter in the embedded program, A second decryption unit for decrypting the current parameter value, and a determination unit for determining which one of the plurality of regions where the value after the change is detected when a change in the value of the current parameter is detected, The designating means includes a switching destination specifying unit that specifies an operation verification target associated with the determined value range as a switching destination operation verification target, and the reading unit includes a switching destination operation verification target. If it is defined, the debugging system of claim 7, wherein the reading the operating state information from the switching 換元 operation verified. 17. The debugging device according to claim 1, wherein, if the command received by the receiving unit does not include a predetermined instruction, a correspondence table indicating which scheduled execution time the operator has associated with the plurality of operation verification targets is the same. A first decoding unit that decodes the command if it is included in the command; and a timing unit that counts the current time. When the current time reaches the scheduled execution time,
A switching destination defining unit that defines the operation verification target as a switching destination, wherein the reading unit reads the operation state information from the switching source operation verification target when the switching destination operation verification target is defined. Item 7. The debugging device according to Item 7.