Debugging apparatus for debugging a program

BACKGROUND OF THE INVENTION

(1) Field of the Invention

0001This invention relates Lo a debugging apparatus, and more specifically, to a debugging apparatus for debugging a debug target program by changing hardware environments without changing program operation state.

(2) Description of the Prior Art

0002Microcomputer systems are indispensable to electrical appliances today. In. developing programs for such microcomputer systems, debugging is very important since microcomputer systems require such a quality as enduring mass production.

0003For debugging programs, the debug target programs are run in hardware environments to find errors (bugs). The bugs found are deleted from the programs.

0004The hardware environments in which debug target programs run are classified as follows: <ul id="ul0001" list-style="none" compact="compact"><li>(1) target machine prototypes;</li><li>(2) evaluation boards; and</li><li>(3) simulators on host computers.</li></ul>

0005The hardware environment of (1) above is called "monitor type." In the monitor type hardware environment, operations of prototype microprocessors are monitored and simple debugging is performed.

0006The hardware environment of (2) above enables a high-quality debugging, using an in-circuit emulaLors (ICE) and various debugging tools. This hardware environment is called "ICE type."

0007The hardware environment of (3) above is called "simulator type." The simulators used in the environment are divided into two types: instruction level software simulators and logic level software simulators. Instruction level software simulators are such software systems as realizing, in a hosL computer, pseudo operation states of microprocessors by executing instructions of the microprocessors in the host computer.

0008The logic level software simulators simulate hardware operations and are generally used for designing microprocessor chips.

0009Meanwhile, these three types of hardware environments have their limitations respectively in the ability of testing operations.

0010In the ICE type hardware environment, the trace function can be used to output history of program operations. In the monitor type hardware environment, in contrast, it is difficult to use the trace function since it requires a great amount of memory capacity. Therefore, the operator is obliged to analyze the cause of bugs with other less-quality functions in the monitor type. It may be said that the program verification in the monitor type is insufficient since various cases such as multiple interrupts, interrupts at an appointed time, etc cannot be applied to the debug target program. On the other hand, modifying the hardware monitor machine is not realistic.

0011The limitations of the ICE type hardware environment derive from the difference in the circuit structure between the evaluation board and the target microprocessor. Even if the microprocessor appears to operate perfectly on the evaluation board, it is not enough to permit the shipping of the microprocessor. The microprocessor should be verified with its peripherals. Lines in the evaluation board, for example, may be longer than those of a prototype microprocessor. This may generate a time lag when using the peripherals, which results in incorrectness of the microprocessor verification.

0012The limitation of the simulator type hardware environment derives from the slowness of operations. This is because the simulator itself uses the host computer. A process which takes one second in the ICE type or monitor type hardware environment, for example, takes several minutes or tens of several minutes in the simulator type hardware environment.

0013When an error occurs in a certain situation in a hardware environment, the operator may desire to reproduce the same situation in another hardware environment. Reproducing of such situations, however, generally requires a lot of trials and errors before the reproduction succeeds, such as transferring values at the time when an error occurred to the other environment, or running the debug target program from the beginning, etc. Such trials and errors takes a lot of time in the development of the microprocessor.

0014The document Robert D. Gronlund et al: "The HP 64700 Embedded Debug Environment: A New Paradigm for Embedded Systems Integration and Debugging", HEWLETT-PACKARD JOURNAL, vol. 44, No. 2, April 1993, Palo Alto, US, describes a debugging system for embedded systems using emulator systems for simulation and analysts purposes. Also simulator tools are described in the context of embedded system debugging.

SUMMARY OF THE INVENTION

0015It is therefore an object of the present invention to provide a debugging apparatus which makes the most of the advantage of each of different hardware environments by controlling the hardware environments.

0016It is another object of the present invention to provide a debugging apparatus for, when an error occurs in a certain situation in a hardware environment, reproducing the same situation in another hardware environment, without causing the developer to perform a lot of trials and errors.

0017The invention, as defined in claim 1, achieves the above objects by a debugging apparatus for verifying a program, which is to be embedded into a target machine, by running the program in any of the target machine itself, an emulator machine emulating the target machine, and a simulator simulating the target machine in terms of software, where each of the target machine, the emulator machine, and the simulator includes operation state information which indicates an operation state of the program and inputs and outputs the operation state information in a form unique to each of the target machine, the emulator machine, and the simulator, the debugging apparatus including: target environment storing unit for storing information of a target environment which is an identification name of any of the target machine, the emulator machine, and the simulator as an environment target; receiving unit for receiving a command input by an operator; instruction detecting unit for judging whether a certain instruction is included in the command received by the receiving unit; specifying unit for, when the instruction detecting unit judges that the certain instruction is included in the command, specifying a target environment specified by the identification name stored in the target environment storing unit as a source target environment and for specifying, as a destination target environment, one of the target machine, the emulator machine, and the simulator other than the identification name stored in the target environment storing unit; reading unit for reading operation state information from the source target environment; converting unit for converting the operation state information read by the reading unit into operation state information written in a form unique to the destination target environment; setting unit for setting the operation state information written in the form unique to the destination target environment in the destination target environment; and operation resuming unit for resuming an operation of the program in the destination target environment.

0018With such a construction, the debugging apparatus enables the operator to switch the hardware environments in debugging the debug target program. That means the operator can effectively debug the debug target program, making the most of the advantage of each of different hardware environments.

0019The first part of a debug target program, for example, may be run in the prototype hardware environment. Then, the rest of the debug target program may be run in the simulator type hardware environment. This is because the simulator type takes a lot of time in running the program, though it has a lot of functions for analyzing the cause of bugs. This tactic is very effective when to find such a bug as occurring once in several tens or several hundreds of executions of the debug target program. This decreases the time of debugging.

0020Another advantageous aspect of the present invention is that the hardware environments are switched by an issue of a command, which is a handy method and may be possible in any situations in the execution of debugging. That means the operator can analyze the cause of the bug without taking much time for the development.

0021The debug target program also need not be run from the beginning in another hardware environment to reproduce the same situation for an error, while in conventional systems, values are transferred to the other hardware environment and the program is repeated from the beginning. This also decreases the time of debugging, and accordingly the time of developing.

0022The above debugging apparatus may further include: breakpoint setting managing unit for managing areas of the memories and the registers of the target machine, the emulator machine, and the simulator by classifying the areas into areas for which a breakpoint can be set and areas for which a breakpoint cannot be set; judging unit for judging whether a breakpoint is to be set in the destination target environment by referring to the breakpoint setting managing unit after the converting unit has converted the operation state information into the form of the destination target environment; and notifying unit for notifying the operator that the breakpoint is not to be set in the destination target environment when the judging unit judges that the breakpoint is not to be set in the destination target environment.

0023With such a construction it is possible for the debugging apparatus to inform the operator that a part of breakpoints cannot be set in the destination target hardware environment.

0024The above debugging apparatus may further comprise: maximum value storing unit for storing a value representing the maximum number of accumulated addresses for each of the target machine, the emulator machine, and the simulator; address number recognizing unit for recognizing a current number of accumulated addresses in the destination target environment; and notifying unit for notifying the operator of a difference between the current number of accumulated addresses and the maximum number of accumulated addresses.

0025With such a construction, it is possible for the debugging apparatus to inform the operator that a part of trace data accumulated in the source target hardware environment is lost in the destination target hardware environment.

BRIEF DESCRIPTION OF THE DRAWINGS

0026These and other objects, advantages and features of the invention will become apparent from the following description thereof taken in conjunction with the accompanying drawings which illustrate a specific embodiment of the invention. In the drawings: <ul id="ul0002" list-style="none" compact="compact"><li>FIG.1A shows an appearance of the debugging apparatus of the present embodiment;</li><li>FIG.1B is a block diagram showing the hardware construction of the debugging apparatus of the present embodiment;</li><li>FIG.2A shows the hardware construction of the monitor type hardware environment;</li><li>FIG.2B shows the hardware construction of the ICE type hardware environment;</li><li>FIG.2C shows the construction of the simulator type hardware environment;</li><li>FIG.3 shows internal layers of the debugging apparatus;</li><li>FIG.4 shows the sub-layers in application layer 11;</li><li>FIG.5 shows the contents of the sub-layers in application layer 11;</li><li>FIG.6A is a systematic illustration of debug commands which are used in the present embodiment;</li><li>FIG.6B shows three major examples of the extended selectTARGET commands;</li><li>FIG.6C shows a table which shows destination target hardware environments;</li><li>FIG.7 shows messages output onto display 2 by user interface layer 50;</li><li>FIG.8 shows the sub-commands and the corresponding function call codes;</li><li>FIG.9 shows the high function call codes and corresponding low function call codes;</li><li>FIG.10A shows the control of reading data from work area 38 in prototype 30 by monitor control layer 61;</li><li>FIG.10B shows the control of writing data into work area 38 in prototype 30 by monitor control layer 61;</li><li>FIG.11A is a flowchart of the procedure of the communications sequence to control reading data from memories, which is performed by monitor control layer 61;</li><li>FIG.11B is a flowchart of the procedure of the communications sequence to control writing of data into a memory, which is performed by monitor control layer 61;</li><li>FIG.12A shows the control of the data reading by ICE control layer 62;</li><li>FIG.12B shows the control by ICE control layer 62 when ICE control layer 62 writes data into debug target program 37 in evaluation board 20;</li><li>FIG.13A shows the transportation of state information when the selectTARGET command specifying the simulator type hardware environment as the destination target hardware environment is input while the program runs in the monitor type hardware environment;</li><li>FIG.13B shows the transportation of state information when the selectTARGET command specifying the ICE type is input while the program runs in the monitor type hardware environment;</li><li>FIG.13C shows the transportation of state information when the selectTARGET command specifying the monitor type is input while the program runs in the ICE type hardware environment;</li><li>FIG.13D shows the transportation of state information when the selectTARGET command specifying the simulator type is input while the program runs in the ICE type hardware environment;</li><li>FIG.13E shows the transportation of state information when the selectTARGET command specifying the monitor type is input while the program runs in the simulator type hardware environment;</li><li>FIG.13F shows the transportation of state information when the selectTARGET command specifying the ICE type is input while the program runs in the simulator type hardware environment;</li><li>FIG.14A shows breakpoint addresses;</li><li>FIG.14B shows an interrupt signal generation condition;</li><li>FIG.14C shows the trace data;</li><li>FIG.14D shows information used for the breakpoint management function;</li><li>FIG.14E shows information used for the trace data accumulation size management function;</li><li>FIG.14F shows information used for the interrupt generation condition management function;</li><li>FIG.14G shows I/O mapping information used for the I/O mapping information management function;</li><li>FIG.15 is a flowchart of the procedure for the selectTARGET command in the present embodiment;</li><li>FIG.16 is a flowchart of the procedure for the targetASSIGN command in the present embodiment;</li><li>FIG.17 is a flowchart of the procedure for the IFbreak command in the present embodiment; and</li><li>FIG.18 is a flowchart of the procedure for the switch(var) command in the present embodiment.</li></ul>

DESCRIPTION OF THE PREFERRED EMBODIMENTS

0027The debugging apparatus of the present invention is composed of host computer 1, which is a general-purpose computer, connected to ICE control board 22 and serial transfer port 31. FIG.1A shows an appearance of the debugging apparatus of the present invention.

0028Prototype 30 of an electrical appliance is called the monitor type hardware environment. Prototype 30 includes a ROM which stores a debug target program. The debug target program of prototype 30 is under control of host computer 1. The start and end of the operation of the debug target program are performed with instructions from the host computer sent via serial line 40. Host computer 1 reads data from storages of prototype 30, such as memories and registers. The read data is also dealt with as the state information.

0029Evaluation board 20 also runs the debug target program. The debug target program of evaluation board 20 is also under control of host computer 1. The start and end of the operation of the debug target program are performed with instructions from the host computer sent via parallel line 28. Host computer 1 reads data from storages of evaluation board 20, such as memories and registers. The read data is also dealt with as the state information.

0030FIG.1B is a block diagram showing the hardware construction of the debugging apparatus of the present invention. As shown in the drawing, host computer 1 is a general-purpose computer including a CPU, display 2, a memory, a hard disk, keyboard 3, ICE control board 22, and serial transfer port 31. Host computer 1 is connected to evaluation board 20, and prototype 30 respectively via ICE control board 22 and serial transfer port 31.

0031FIG.2A shows the hardware construction of prototype 30. As shown in the drawing, prototype 30 includes processor 33, memory 34, and peripheral I/O register set 35.

0032Processor 33 includes an instruction read circuit, a decoder, a calculator, a register set, and a program counter. The instruction read circuit reads machine-language instructions from the debug target program one at a time. The decoder decodes the machine language instructions. The calculator performs a calculation if a read instruction is an operation instruction. The program counter notifies the instruction read circuit of destinations into which instructions are stored. Processor 33 also includes dedicated terminal 39. Processor 33 reads operation state information and outputs the information to host computer 1 via dedicated terminal 39 when processor 33 receives a certain instruction signal via dedicated terminal 39.

0033Memory 34 stores monitoring program 36 and debug target program 37 and includes work area 38. When prototype 30 is activated, processor 33 runs debug target program 37. Debug target program 37 includes monitoring instructions which instruct processor 33 to branch to monitoring program 36 when data is input to dedicated terminal 39.

0034Monitoring program 36, on receiving data via dedicated terminal 39, allows control to branch from debug target program 37 to monitoring program 36.

0035Peripheral I/O register set 35 hold values of peripheral I/O devices, such as a serial interface, a parallel interface, an interrupt controller, an A/D converter, a D/A converter, and a timer counter. It is possible for processor 33 to fetch an arbitrary value of an arbitrary peripheral I/O device since values of the peripheral I/O devices are respectively stored in the registers making up peripheral I/O register set 35.

0036FIG.2B shows the hardware construction of evaluation board 20. compared with prototype 30, it is found that processor 33 is replaced by ICE chip 23. Evaluation board 20 also includes memory 24 and peripheral I/O register set 25.

0037Memory 24 includes a supervisor space and a user space. The supervisor space includes supervisor program 26 and debug information area 27. The user space includes debug target program 37 and work area 38.

0038Peripheral I/O register set 25 is composed of registers which hold values of corresponding peripheral I/O devices.

0039Supervisor program 26 includes a breakpoint setting tool, a trace tool, and an interrupt setting tool. The breakpoint setting tool sets breakpoints, where the breakpoint indicates a point where an interrupt signal is generated, or a point where an operation stops. The trace tool accumulates addresses of instructions executed by ICE chip 23. The interrupt setting tool monitors whether a certain condition set by the operator is met, and if the condition is met, generates an interrupt signal.

0040Debug information area 27 is an area in the memory which is used as a work area by supervisor program 26. Debug information area 27 stores breakpoint addresses, breakpoint information, trace data, and interrupt signal generation condition information. The breakpoint information indicates whether the breakpoint is effective. The trace data is composed of a plurality of accumulated addresses of instructions. The interrupt signal generation condition information indicates a certain condition set by the operator for generating interrupt signals.

0041FIG.14A shows breakpoint addresses. "BREAK POINT(1)=0x0020" indicates that the first breakpoint is set in an area with a certain size specified by address 0x0020. "BREAK_POINT (2)=0x0250" indicates that the second breakpoint is set in an area with a certain size specified by address 0x0250. "BREAK_POINT(3)=0x0300" indicates that the third breakpoint is set in an area with a certain size specified by address 0x0300. Such breakpoint addresses, which are set by the operator, are written in memory 24 by the breakpoint setting tool of supervisor program 26.

0042FIG.14B shows an interrupt signal generation condition. In the drawing, "CONDITION(1)=20cycle, Int3" indicates that an instruction is executed for 20 cycles then the third interrupt signal is generated, where a cycle representing a unit instruction execution time. "CONDITION(2)=150cycle,Int5" indicates that an instruction is executed for 150 cycles then the fifth interrupt signal is generated. Such interrupt signal generation conditions are written into memory 24 by the interrupt signal generating tool of supervisor program 26 which is activated by debug target program 37 when the operator sets the interrupt generation while debugging debug target program 37.

0043FIG.14C shows the trace data. The trace data shows the history of executed instructions, and "0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005," indicates, for example, that ICE chip 23 has executed the machine-language instructions of debug target program 37 which are stored in the areas respectively specified by addresses 0x0000, 0x0001, 0x0002, 0x0003, 0x0004, and 0x0005. Such trace data is written in memory 24 by the trace tool of supervisor program 26 which is executed by processor 33 when the operator inputs the trace command while debugging debug target program 37 in the ICE type hardware environment.

0044Work area 38 is a work area used by debug target program 37.

0045FIG.3 shows internal layers of host computer 1. As shown in the drawing, host computer 1 is divided into application layer 11, operating system layer 12, BIOS (Basic Input/output System) layer 13, and physical layer 14, which make up a standard construction of a general-purpose computer. Application layer 11 includes simulator 10. This indicates that simulator 10 is an application program that runs on an operating system. ICE control board 22 and serial transfer port 31 exist in physical layer 14. A dedicated device driver 21 in the BIOS layer is connected to ICE control board 22.

0046Since simulator 10 exists in application layer 11, it is required to use the format of application layer 11 to access the simulator type hardware environment. Device driver 21 exists in BIOS layer 13. Thus,,it is required to use the format of BIOS layer 13 to access the ICE type hardware environment. Since serial transfer port 31 exists in physical layer 14, it is required to use the format of physical layer 14 to access the monitor type hardware environment.

0047Accordingly, when parameters are transferred among the hardware environments, the formats should be changed according to the layers of the target hardware environments.

0048Parameters should be transferred to simulator 10 in the formats of arguments since simulator 10 is an application program in application layer 11. Parameters should be transferred to device driver 21 in the formats of commands since device driver 21 is in BIOS layer 13. Parameters should be transferred to serial transfer port 31 through I/O ports since serial transfer port 31 is in physical layer 14.

0049The ICE, monitor, and simulator type hardware environments are respectively assigned identifiers TARGET1, TARGET2, and TARGET3 which are registered in an identifier table (not shown in the drawings).

0050FIG.4 shows the sub-layers in application layer 11 which have the function of synthesizing the formats of hardware environments.

0051Target dependent layer 53 converts the various data formats of the other layers (hardware environments) into the format of arguments.

0052Target interconnect layer 52, including a shared work area in which data with the format of arguments is stored, allows the data to be shared by the three hardware environments.

0053Debug core layer 51 has the function as a symbolic debugger.

0054User interface layer 50 provides the function as a man-machine interface. For this purpose a standard input/output library (not shown in the drawings) of operating system layer 12 is used. User interface layer 50 displays a message on the screen urging the operator to input a command. In doing so, the standard input/output library of operating system layer 12 is used. When the operator inputs a command responding to the message, user interface layer 50 allows debug core layer 51 and other sub-layers to interpret and execute the command. User interface layer 50 then displays the execution results on the screen using the standard input/output library.

0055FIG.5 shows the contents of the sub-layers: debug core layer 51, target interconnect layer 52, and target dependent layer 53.

0056As shown in the drawing, debug core layer 51 includes symbol address map 71, command interpreter 72, and command conversion routine 73.

0057Symbol address map 71 is information indicating the relation between symbols and addresses in the memory, where symbols represent variables, libraries and the like used in the source program. More specifically, symbol address map 71 is composed of memory sizes, variable types, identification numbers of the lines which include source codes, and line information which indicates addresses of execution codes corresponding to the lines.

0058Command interpreter 72 analyzes the commands input by the operator and then sent to user interface layer 50, and notifies command conversion routine 73 of the contents of the commands. FIG.6A shows such commands which are called debug commands.

0059The commands shown in FIG.6A, except the selectTARGET command, have been used conventionally. These commands, however, are differently used in the present embodiment in that these commands specify a target hardware environment with a corresponding identifier (any of TARGET1, TARGET2, and TARGET3).

0060The run command instructs the target hardware environment to start running the debug target program starting from an address which is specified in the command as an operand.

0061The stop command instructs the target hardware environment to stop running the debug target program.

0062The step command instructs the target hardware environment to sequentially execute the instructions written in the debug target program starting from an address which is specified in the command as an operand.

0063The setBP command instructs the target hardware environment to set a breakpoint at an address which is specified in the command as an operand, where the setting of the breakpoint indicates the writing of an instruction for generating an interrupt signal into debug target program 37, or indicates the storing of an address of an operation stop in a certain register of the processor. In the present embodiment, when the instruction for generating an interrupt signal is written into debug target program 37, the address of the instruction is also written in a memory of the current hardware environment.

0064The clrBP command instructs the target hardware environment to delete a breakpoint specified by operand "breakNo." In case the breakpoint is the instruction for generating an interrupt signal, the address of the instruction is also deleted.

0065The setINT command instructs the target hardware environment to monitor whether an instruction is executed for number of cycles specified by operand "CycleNumber" and to generate the interrupt signal specified by operand "intNO." after the instruction is executed for 20 cycles, where a cycle representing a unit instruction execution time.

0066The readMEM command instructs the target hardware environment to read data from an area ranging from "s_address" to "e_address" which are operands in the command.

0067The readREG command instructs the target hardware environment to read data from a register specified by operand "register" of the command.

0068The writeMEM command instructs the target hardware environment to write data, which is specified by operand "value1" of the command, into an area specified by operand "address" of the command.

0069The writeREG command instructs the target hardware environment to write data, which is specified by operand "value2" of the command, into a register specified by operand "register" of the command.

0070Variables may be used as operands in the readMEM, readREG, writeMEM, and writeREG commands. When a variable is used in such a command, command interpreter 72 refers to symbol address map 71 to specify an address or a register corresponding to the variable. Command interpreter 72 then sends the command to the target hardware environment via target interconnect layer 52.

0071The TRACE command instructs the target hardware environment to accumulate the addresses of the instructions which have been executed the hardware environment.

0072The selectTARGET command instructs the target hardware environment to transfer the operation state information, which is stored in the storages of the target hardware environment, to another hardware environment, and instructs that the debug commands should be issued to the other hardware environment. When the operation state information is transferred, data in the storages, namely, content of work area 38, contents of registers, a breakpoint, interrupt signal generation condition information, contents of peripheral I/O registers, and trace data, is transferred separately. Command interpreter 72 issues sub-commands, such as copyMEM, copyREG, copyBP, copyINT, copyI/O, and copyTRACE_DATA, to achieve such separate transfers.

0073The copyMEM sub-command instructs target interconnect layer 52 to transfer the contents of work area 38 of the target hardware environment to another hardware environment which is specified by the selectTARGET command. The copyMEM sub-command may also specify a start address and an end address of an arbitrary area to instructs target interconnect layer 52 to transfer the contents of the arbitrary area of the target hardware environment to another hardware environment. The copyMEM sub-command may also include a switch indicating whether to transfer the whole contents of the memory to another hardware environment.

0074The copyREG sub-command instructs target interconnect layer 52 to transfer the contents of the register set of the target hardware environment to another hardware environment which is specified by the selectTARGET command.

0075The copyBP sub-command instructs target interconnect layer 52 to transfer the breakpoint address of the target hardware environment to another hardware environment which is specified by the selectTARGET command.

0076The copyINT sub-command instructs target interconnect layer 52 to transfer the interrupt signal generation condition information of the target hardware environment to another hardware environment which is specified by the selectTARGET command.

0077The copyI/O sub-command instructs target interconnect layer 52 to transfer the contents of all the peripheral I/O registers of the target hardware environment to another hardware environment which is specified by the selectTARGET command.

0078The copyTRACE_DATA instructs target interconnect layer 52 to transfer the trace data of the target hardware environment to another hardware environment which is specified by the selectTARGET command.

0079The following is a continued description of the components of debug core layer 51.

0080Command conversion routine 73 converts commands interpreted or automatically issued by command interpreter 72 into function call codes.

0081Command conversion routine 73 converts, for example, the readMEM command, which is one of the instructions for reading state information, into function call code "TCI_get mem(adr,length,unit,image)," where "TCI" stands for Target Core Interface, indicating that the present function call code is used between debug core layer 51 and target interconnect layer 52. As is understood from this, the function call codes are used only in limited layers. "get_mem" of the above function call code indicates that a value should be obtained from a memory. Each of "adr," "length," "unit," and "image" is an argument. Augument "adr" indicates a start address. Argument "length" indicates the length of the obtained data. Argument "unit" indicates a unit used in obtaining data, such as byte, word, and double-word. Argument "image" indicates a target area into which the data is transferred from the memory.

0082In the above example, when command interpreter 72 interprets an input command as the readMEM command, an instruction by a corresponding function call code is sent from debug core layer 51 to target interconnect layer 52. A hardware environment reading the data is not specified in the function call code. That means, the definition of the function call code is of an abstract level.

0083Command conversion routine 73 converts, for example, the writeREG command, which is one of the instructions for writing state information, into function call code "TCI_set REG(regs,mask)." "set_REG" of the above function call code indicates that an immediate value should be set. Each of "regs" and "mask" is an argument. Argument "regs" indicates an array name of one of array variables in the shared work area which respectively hold values of registers, such as a general purpose register, a program counter, a state register, a data register, and an address register. Argument "mask" indicates a bit pattern for masking which specifies which array elements in the array variable specified by the argument "regs" are set in the processor in the target hardware environment and which array elements are not set.

0084Similarly, command conversion routine 73 converts the run, stop, step, setBP, clrBP, SetINT, readREG, writeMEM, and TRACE commands respectively into function call codes "TCI run," "TCI_stop," "TCI_step," "TCI_setBP," "TCI_clrBP," "TCI SetINT," "TCI_read_REG," "TCI_write_MEM," and "TCI_TRACE" and sends the function call codes to target interconnect layer 52.

0085Each sub-command is converted into a pair of function call codes: "TCI_getxxx" for instructing the first hardware environment (source target hardware environment) to read the state information from a storage, and "TCI_setxxx" for instructing the second hardware environment (destination target hardware environment) to write the state information into a storage.

0086FIG.8 shows the sub-commands and the corresponding function call codes.

0087As shown in the drawing, the copyMEM sub-command is converted into two function call codes: <ul id="ul0003" list-style="none" compact="compact"><li>"TCI_get_mem(adr,length, unit,image)" and</li><li>"TCI_set_mem(adr,length,unit,image)."</li></ul>

0088Function code "TCI_get_mem(adr, length, unit, image)" instructs the source target hardware environment to read data from work area 38.

0089Function code "TCI_set_mem(adr, (adr,length, unit,image)" instructs the destination target hardware environment to write the data into work area 38.

0090As shown in the drawing, only function call codes "TCI get_reg (regs,mask)," "TCI_set_reg (regs,mask)," "TCI_get INT (cycle, intkind)," "TCI_set_INT (cycle,intkind)" have two arguments and other function call codes, which transfer data between memories, have four arguments. Note that peripheral I/O register sets 25 and 35 can be accessed through memories.

0091Here, the function call codes corresponding to the copyBP sub-command are described. Generally, breakpoints are specified by addresses of machine-language instructions in the debug target program. For specifying such addresses, arguments "length" and "unit" are not necessary. In the present embodiment, however, so-called "area break" is considered, in which an area effective as the breakpoint can be specified. Arguments "adr," "length," "unit," and "image," including the specifications of the length of the data for the breakpoint and the unit of the data, make it possible to use the area break.

0092In function call codes "ICI_get_INT (cycle,intkind)" and "TCI_set_INT(cycle,intkind)" corresponding to the copyINT sub-command, argument "cycle" indicates an integral multiple of a unit instruction execution time and argument "intkind" indicates a signal number of the interrupt signal to be generated.

0093Target interconnect layer 52, as shown in FIG.5, is composed of code conversion routine 74, work area analysis module 75, and shared work area 77. Of these, code conversion routine 74 and shared work area 77 are described now and work area analysis module 75 will be described later.

0094Code conversion routine 74 rewrites the function call codes (high function call codes) to low function call codes which specifies the destination target hardware environment.

0095Suppose the first hardware environment is monitor type and the second hardware environment is simulator type. An example is given below under this condition. Suppose command conversion routine 73 has converted the copyMEM sub-command into high function code "TCI_get_mem(adr,length,unit,image)" which instructs the source target hardware environment to read data from work area 38. Code conversion routine 74 converts the high function call code into low function call code "MON_get_mem(adr,length,unit,image)," specifying the monitor type hardware environment as the source target hardware environment.

0096Code conversion routine 74 then converts high function call code "ICI_set_mem (adr,length, unit, image)" into low function call code "SIM_set_mem (adr, length, unit, image)," specifying the simulator type hardware environment as the destination target hardware environment. After the conversion, code conversion routine 74 calls a function using the converted low function call codes.

0097Code conversion routine 74 performs similar conversions against other function call codes as shown in FIG.8. FIG.9 shows the high function call codes and corresponding low function call codes.

0098When rewriting the function call codes, code conversion routine 74 identifies the source target hardware environment and destination target hardware environment. For identifying the source target hardware environment, code conversion routine 74 refers to the identifier table. For identifying the destination target hardware environment, code conversion routine 74 receives the selectTARGET command from command interpreter 72 and refers to an operand of the command.

0099Shared work area 77 is a work area which is shared by all the hardware environments and an area of shared work area 77 may be specified by argument "image."

0100Target dependent layer 53 is composed of simulator 10, monitor control layer 61, and ICE control layer 62.

0101Simulator 10 is an application program. FIG.2C shows the construction of simulator 10. As shown in the drawing, simulator 10 is composed of processor simulation routine 95, memory simulation routine 96, and I/O register simulation routine 97.

0102Processor simulation routine 95 simulates the function of processor 33.

0103Memory simulation routine 96 stores, as memory 24 does, supervisor program 26, debug information area 27, debug target program 37, and work area 38. Judged from this construction, the bug analysis ability of the simulator type hardware environment is almost the same as that of the ICE type hardware environment.

0104I/O register simulation routine 97 simulates the function of peripheral I/O register set 35.

0105Processor simulation routine 95, memory simulation routine 96, and I/0 register simulation routine 97 are activated when code conversion routine 74 calls a function using low function call codes specifying the simulator type. When code conversion routine 74 calls a function with low function call code "SIM_get_mem (adr,length,unit,image)," processor simulation routine 95 reads data from an area in memory simulation routine 96 specified by start address "adr" in units specified by "unit," the data having a length specified by "length." Processor simulation routine 95 then stores the data into an area of shared work area 77 specified by "image."

0106When code conversion routine 74 calls a function with low function call code "SIM_set_mem(adr,length,unit,image)," processor simulation routine 95 reads data from an area of shared work area 77 specified by "image" in units specified by "unit," the data having a length specified by "length." Processor simulation routine 95 then writes the data into an area in memory simulation routine 96 specified by start address "adr."

0107Monitor control layer 61 controls the operation of the debug target program in prototype 30 and accesses the storages in prototype 30, such as memories and registers. Thus, monitor control layer 61 activates the debug target program or reads/writes data from/into the storages with a desired timing.

0108Monitor control layer 61 achieves the above control of the data reading/writing by performing certain communications sequences with monitoring program 36 via serial transfer port 31, dedicated terminal 39, and serial line 40. Debug core layer 51 performs such a communications sequence when code conversion routine 74 calls a function.

0109FIG.10A shows the control of the data reading by monitor control layer 61. As shown in the drawing, monitor control layer 61 performs a communications sequence to control the data reading when code conversion routine 74 calls a function with low function call code "MON_get mem (adr, length, unit, image)." In the communications sequence, monitor control layer 61 transmits/receives the packets, which are shown in (2) of the drawing, according to the protocol as shown in (1) of the drawing.

0110Each of the three types of packets shown in (2) of FIG.10A, namely, packets "MEMREAD," "ACK," "UNIT," and "DATA," has eight bytes.

0111The first byte (denoted as byte 0) of packet "MEMREAD" is assigned to field "CMD" in which a command type is specified. The second byte (denoted as byte 1) is assigned to field "UIT" in which a unit (byte, word, double-word, etc.) used in reading data from a memory is specified. The third and fourth bytes (denoted as bytes 2 and 3) are assigned to field "SIZE" in which a length of data to be read from a memory is specified. The fifth byte to the eighth byte (denoted as bytes 4 to 7) are assigned to field "ADRS" in which an address of a memory from which data is read is specified.

0112The first byte of packet "ACK" indicates a type of an error which has occurred in monitoring program 36.

0113FIG.11A is a flowchart of the procedure of the communications sequence to control reading data from memories, which is performed by monitor control layer 61.

0114When code conversion routine 74 calls a function with low function call code "MON_get_mem(adr,length,unit,image)," monitor control layer 61 generates a transmission packet "MEMREAD" by setting each field. More specifically, monitor control layer 61 writes an identification code of the MEMREAD command into field "CMD," writes a code of unit name specified by argument "unit" into field "UIT," writes a data length specified by argument "length" into field "SIZE," and writes a read-target address of argument "adr" into field "ADRS" (step S1). Monitor control layer 61 transmits the generated transmission packet to monitoring program 36 via serial line 40 (step S2). Monitor control layer 61 then waits for reception packet "ACK" (step S3). If monitor control layer 61 receives reception packet "ACK," monitor control layer 61 judges whether the first byte of reception packet "ACK" indicates an error (step S4). If it indicates an error, monitor control layer 61 returns to step S2 to re-transmit the generated transmission packet; if it does not indicate an error, monitor control layer 61 proceeds to step S5. In step S5, monitor control layer 61 sets variable i to "1." In step S6, monitor control layer 61 sets variable n to the specified data length divided by the packet size (eight bytes). Here, variable i indicates the number of reception packets "DATA" having been processed and variable n indicates the total number of reception packets "DATA."

0115After setting the above variables to above initial values, monitor control layer 61 waits for reception packets "DATA" (step S7). If monitor control layer 61 receives reception packets "DATA," monitor control layer 61 stores eight-byte data of each reception packet in an area of shared work area 77 specified by argument "image" (step S8). monitor control layer 61 then compares variable i with variable n to judge if they are equal (step S9); if not equal, monitor control layer 61 increments variable i (step S10) then goes to step S7.

0116Steps S7-S10 are repeated until monitor control layer 61 judges that variable i is equal to variable n in step S9.

0117During the repeated operations of steps S7-S10, data in prototype 30 is transferred to monitor control layer 61 eight bytes by eight bytes via serial transfer port 31, serial line 40, and dedicated terminal 39. The transferred data is accumulated in an area of shared work area 77 specified by argument "image." When the above operation is repeated n times, data with the length specified by argument "length" has been stored in the area of shared work area 77 specified by argument "image."

0118After data is transferred from memory 34 to shared work area 77, it is possible to transfer the data to simulator 10 and ICE control layer 62. That is, when code conversion routine 74 calls a function with low function call code "SIM_set_mem(adr,length,unit,image)" at this stage, the data is written into an area of memory simulation routine 96 specified by argument "adr."

0119Monitor control layer 61 repeatedly performs the communication sequence to transfer other pieces of state information of the storages of prototype 30, namely, contents of other registers, a breakpoint, interrupt signal generation condition information, contents of peripheral I/O registers, and trace data, into memory simulation routine 96 via shared work area 77.

0120FIG.10B shows the control of the data writing by monitor control layer 61. As shown in the drawing, monitor control layer 61 performs a communications sequence to control the data writing when code conversion routine 74 calls a function with low function call code "MON_set mem(adr,length,unit,image)." In the communications sequence, monitor control layer 61 transmits/receives the packets, which are shown in (2) of the drawing, according to the protocol as shown in (1) of the drawing.

0121Each of the three types of packets shown in (2) of FIG.10B, namely, packets "MEMWRITE," "ACK1," "ACK2," and "DATA," has eight.bytes.

0122The first byte (denoted as byte 0) of packet "MEMWRITE" is assigned to field "CMD" in which a command type is specified. The second byte (denoted as byte 1) is assigned to field "UIT" in which a unit (byte, word, double-word, etc.) used in writing data into a memory is specified. The third and fourth bytes (denoted as bytes 2 and 3) are assigned to field "SIZE" in which a length of data to be written into a memory is specified. The fifth byte to the eighth byte (denoted as bytes 4 to 7) are assigned to field "ADRS" in which an address of memory 34 into which data is written is specified.

0123The first byte of packets "ACK1" and "ACK2" indicates a type of an error which has occurred in monitoring program 36.

0124FIG.11B is a flowchart of the procedure of the communications sequence to control writing of data into a memory, which is performed by monitor control layer 61.

0125When code conversion routine 74 calls a function with low function call code "MON_set_mem (adr,length,unit,image)," monitor control layer 61 generates a transmission packet "MEMWRITE" by setting each field. More specifically, monitor control layer 61 writes a code representing the MEMWRITE command into field "CMD," writes a code representing a unit name of argument "unit" into field "UIT," writes a data length of argument "length" into field "SIZE," and writes a write-target address of argument "adr" into field "ADRS" (step S11). Monitor control layer 61 transmits the generated transmission packet to monitoring program 36 via serial line 40 (step S12). Monitor control layer 61 then waits for reception packet "ACK" (step S13). If monitor control layer 61 receives reception packet "ACK," monitor control layer 61 judges whether the first byte of reception packet "ACK" indicates an error (step S14). If it indicates an error, monitor control layer 61 returns to step S12 to re-transmit the generated transmission packet; if it does not indicate an error, monitor control layer 61 proceeds to step S15. In step S15, monitor control layer 61 sets variable j to "1." In step S16, monitor control layer 61 sets variable n to the specified data length divided by the packet size (eight bytes). Here, variable j indicates the number of transmission packets "DATA" having been processed and variable n indicates the total number of transmission packets "DATA."

0126After setting the above variables to above initial values, monitor control layer 61 reads eight-byte data from an area of shared work area 77 specified by argument "image," the eight-byte data ranging from byte (8∗(j-1)) to byte (8∗j-1). In the first operation in this step, for example, the eight-byte data ranges from byte 0 to byte 7 since j=1. monitor control layer 61 then writes the eight-byte data into field "DATA" of a transmission packet "DATA"(step S18). monitor control layer 61 transmits the packet (step S19). monitor control layer 61 then compares variable j with variable n to judge if they are equal (step S20); if not equal, monitor control layer 61 increments variable j (step S21) then goes to step S18.

0127Steps S18-S21 are repeated until monitor control layer 61 judges that variable j is equal to variable n in step S20.

0128During the repeated operations of steps S18-S21, data in shared work area 77 is transferred to memory 34 eight bytes by eight bytes via serial transfer port 31, serial line 40, and dedicated terminal 39. The transferred data is accumulated in memory 34. When the above operation is repeated n times, data with the length specified by argument "length" has been stored in memory 34.

0129Monitor control layer 61 repeatedly performs the communication sequence to transfer other pieces of state information of shared work area 77, namely, contents of other registers, a breakpoint, interrupt signal generation condition information, contents of peripheral I/O registers, and trace data, into a storage of prototype 30.

0130It is possible to transfer data of simulator 10 and ICE control layer 62 from shared work area 77 to memory 34 by writing the data in shared work area 77 in advance before code conversion routine 74 calls a function using low function call code "MON_set_mem(adr,length,unit,image)."

0131ICE control layer 62 controls ICE chip 23 in evaluation board 20. That is, ICE control layer 62 controls the debug target program and accesses the storages, such as memories and registers, in evaluation board 20. Thus, ICE control layer 62 activates the debug target program and writes data from the storages in evaluation board 20 into the debug target program with a desired timing.

0132ICE control layer 62 achieves the above control of the data reading/writing by issuing the BIOS command to device driver 21 when code conversion routine 74 calls a function with a low function call code specifying the ICE type hardware environment as the destination target hardware environment.

0133FIG.12A shows the control of the data reading by ICE control layer 62. As shown in the drawing, ICE control layer 62 issues BIOS command "MEM_READ(adrs,type,num)" to device driver 21 when code conversion routine 74 calls a function with low function call code "ICE_get_mem (adr,length,unit, image)."

0134The BIOS command includes the following parameters: "adrs" for indicating a read target address of debug target program 37 in evaluation board 20; "type," set by device driver 21, for indicating a unit of data reading in evaluation board 20 which is used in evaluation board 20; and "num" for indicating the number of "words," the data length of each of the "words" being equal to the unit specified by parameter "type," the value of "num" being equal to the value of argument "length" divided by the value of argument "unit" when code conversion routine 74 calls a function.

0135ICE control layer 62 issues BIOS command "MEM READ(adrs,type,num)" to device driver 21 with the above described parameters. After issuing the command, ICE control layer 62 waits for device driver 21 to output a result. ICE control layer 62 receives the result as a value read from an area in memory 24 specified by argument "adr" in evaluation board 20, then stores the value into an area in shared work area 77 specified by parameter "adrs."

0136FIG.12B shows the control by ICE control layer 62 when ICE control layer 62 writes data into debug target program 37 in evaluation board 20. ICE control layer 62 issues BIOS command "MEM_WRITE(adrs,type,num)" to device driver 21 When code conversion routine 74 calls a function with function call code "ICE_set_mem(adr,length,unit,image)." ICE control layer 62 then outputs a value in an area of shared work area 77 specified by argument "adr" to device driver 21 as a write target value.

0137Parameter "adrs" of the BIOS command indicates a write target address of debug target program 37 in evaluation board 20. Parameter "type" indicates a unit of data writing.

0138ICE control layer 62 issues BIOS command "MEM WRITE(adrs,type,num)" to device driver 21 with the above described parameters.

0139Device driver 21 sets storages for storing addresses, sizes, and operation types in evaluation board 20, according to the BIOS command issued by ICE control layer 62.

0140The reason for setting such storages is that ICE chip 23 interprets the contents of the storages as instructions from host computer 1 and operates according to the interpretation, such as reading/writing data from/to memories and setting breakpoints.

0141Device driver 21, on receiving BIOS command "MEM READ(adrs,type,num)," stores the value specified by parameter "adrs" into the storage for addresses, stores the value specified by parameter "num" into the storage for sizes, and stores operation type "read" into the storage for operation types. ICE chip 23 reads data from an area in memory 24 specified by parameter "adrs" in the unit specified by parameter "num." device driver 21 outputs the read data to ICE control layer 62 as the state information of memory 24 in evaluation board 20.

0142Device driver 21, on receiving BIOS command "MEM WRITE(adrs,type,num)," stores the value specified by parameter "adrs" into the storage for addresses, stores the value specified by parameter "num" into the storage for sizes, and stores operation type "write" into the storage for operation types. Device driver 21 outputs data from an area of shared work area 77 specified by argument "image" which has been transferred from monitor control layer 61. ICE chip 23 writes the data into an area in memory 24 specified by parameter "adrs" in the unit specified by parameter "num."

0143The operation of the present debugging apparatus with the above construction is described below. FIG.7 shows messages output by user interface layer 50.

0144When the debugging apparatus is activated, user interface layer 50 outputs message p1 shown in the drawing, "∗HARDWARE ENVIRONMENT IS SET TO TARGET1. TARGET1 IS MONITOR TYPE." User interface layer 50 then outputs message "∗INPUT COMMAND" and displays a prompt for urging the user to input a command.

0145Here, suppose the user inputs "readMEM 0x0100,16" on keyboard 3. User interface layer 50 transfers the input command to debug core layer 51 so that debug core layer 51 interprets and executes the command.

0146Command conversion routine 73 converts the command into function call code "TCI_read_mem(0x0100,16,byte,image)" and outputs the code to code conversion routine 74. Code conversion routine 74 converts the high function call code to a low function call code specifying a target hardware environment. In this case, the hardware environment is the monitor type. Thus low function call code "MON_read mem(0x0100,16,byte,image)" is generated.

0147When code conversion routine 74 calls a function with "MON_read_mem(0x0100,16,byte,image)," monitor control layer 61 reads data from prototype 30 one byte by one byte via serial transfer port 31, serial line 40, and dedicated terminal 39, as shown in the flowchart of FIG.11A. Monitor control layer 61 accumulates the read data in an area of shared work area 77 specified by argument "image." When monitor control layer 61 repeats this process 16 times as specified by field "SIZE," data with the length specified by argument "length" has been stored in the area of shared work area 77 specified by argument "image."

0148User interface layer 50 displays the value currently stored in shared work area 77 with a message, as shown in FIG.7:    "∗TARGET1 STORES FOLLOWING VALUE FOR 0X0100,16

0149FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF." user interface layer 50 then outputs message "∗INPUT COMMAND" and displays a prompt for urging the user to input a command.

0150Here, suppose the user inputs "writeREG D1,03" on keyboard 3. User interface layer 50 transfers the input command to debug core layer 51 so that debug core layer 51 interprets and executes the command.

0151Command conversion routine 73 converts the command into function call code "TCI_write_REG(D1,03)" and outputs the code to code conversion routine 74. Code conversion routine 74 converts the high function call code to a low function call code specifying a target hardware environment. In this case, the hardware environment is the monitor type. Thus low function call code "MON_write_REG(D1,03)" is generated.

0152When code conversion routine 74 calls a function with low function call code "MON_write_REG(D1,03)," (D1,03)," monitor control layer 61 instructs processor 33 to write data into a register and outputs the immediate value "03" to prototype 30 via serial transfer port 31, serial line 40, and dedicated terminal 39. Processor 33 writes the immediate value into the specified register "D1."

0153Processor 33 outputs a signal to monitor control layer 61 to indicate that the data has been written normally. Monitor control layer 61 notifies user interface layer 50 of a normal end via code conversion routine 74, command conversion routine 73, and command interpreter 72. User interface layer 50 displays a message "∗VALUE 03 WAS STORED IN D1 OF TARGET1" and displays a prompt for urging the user to input a command.

0154Here, suppose the user inputs "setBP BP1,0x0123" on keyboard 3. User interface layer 50 transfers the input command to debug core layer 51 so that debug core layer 51 interprets and executes the command.

0155Command conversion routine 73 converts the command into function call code "TCI_set_BP(BP1,0x0123)" and outputs the code to code conversion routine 74. Code conversion routine 74 converts the high function call code to a low function call code specifying a target hardware environment. In this case, the hardware environment is the monitor type. Thus low function call code "MON_set_3P(BP1,0x0123)" is generated.

0156When code conversion routine 74 calls a function with low function call code "MON_set_BP(BP1,0x0123)," monitor control layer 61 instructs processor 33 to set breakpoint "BP1" at address "0x0123" via serial transfer port 31, serial line 40, and dedicated terminal 39. Processor 33 sets breakpoint "BP1" at address "0x0123."

0157Processor 33 outputs a signal to monitor control layer 61 to indicate that the breakpoint has been set normally. Monitor control layer 61 notifies user interface layer 50 of a normal end via code conversion routine 74, command conversion routine 73, and command interpreter 72.

0158User interface layer 50 displays a message "∗ BREAKPOINT BP1 WAS SET AT 0x0123 OF TARGET1" and displays a prompt for urging the user to input a command.

0159Here, suppose the user inputs "RUN" on keyboard 3. user interface layer 50 transfers the input command to debug core layer 51 so that debug core layer 51 interprets and executes the command.

0160Command conversion routine 73 converts the command into function call code "TCI_run(0x0000)" and outputs the code to code conversion routine 74. Code conversion routine 74 converts the high function call code to a low function call code specifying a target hardware environment. In this case, the hardware environment is the monitor type. Thus low function call code "MON_run(0x0000)" is generated.

0161When code conversion routine 74 calls a function with low function call code "MON_run(0x0000)," monitor control layer 61 instructs processor 33 to run debug target program 37 via serial transfer port 31, serial line 40, and dedicated terminal 39. Processor 33 runs debug target program 37.

0162Prototype 30 starts operating when processor 33 runs debug target program 37. when debug target program 37 stops operation at the breakpoint which has been set previously, processor 33 notifies monitor control layer 61 of the program stop via dedicated terminal 39, serial line 40, and serial transfer port 31.

0163Monitor control layer 61 notifies user interface layer 50 of the program stop via code conversion routine 74, command conversion routine 73, and command interpreter 72.

0164User interface layer 50 displays a message "∗PROGRAM STOPPED AT 0x0123 OF TARGET1" and displays a prompt for urging the user to input a command.

0165Here, suppose the user inputs "selectTARGET" on keyboard 3. The following is a description of the operation for the selectTARGET command.

0166FIGs.13A-13F show the transportation of commands, function call codes, and state information in the layers in the debugging apparatus, as shown in FIGs.4 and 5.

0167FIG.13A shows the transportation of state information when the selectTARGET command specifying the simulator type hardware environment as the destination target hardware environment is input while the program runs in the monitor type hardware environment. Each layer includes the function call codes and commands used under the condition. The arrows indicate the direction of these function call codes and commands.

0168The operation of command interpreter 72 related to the interpretation of the selectTARGET command is described below with reference to FIGs.13A and 15.

0169It is supposed that the user inputs the selectTARGET command on keyboard 3 specifying the simulator type while the program runs in the monitor type hardware environment.

0170User interface layer 50 is waiting for the user to input a command by displaying a prompt, in step S81 in the flowchart of FIG.15. When the user inputs a command, command interpreter 72 interprets the input command in step S82. command interpreter 72 then judges whether the operation code is "selectTARGET" in step S83. If it is, command interpreter 72 instructs the first hardware environment (source target hardware environment) to stop running the program. Command interpreter 72 issues sub-commands copyMEM, copyREG, copyBP, copyINT, copyI/O, and copyTRACEDATA in steps S85-S90, respectively (see arrow yl in FIG.13A).

0171Command conversion routine 73 converts, for example, sub-command "copyMEM" into two high function call codes: "TCI get_mem(adr,length, unit,image)" and "TCI_set_mem(adr,length, unit,image)" (see arrow y2 in FIG.13A). command conversion routine 73 also converts, for example, sub-command "copyREG" into two high function call codes: "TCI_get_reg(regs,mask)" and "ICI_set_reg(regs,mask)."

0172Code conversion routine 74 converts the high function call codes to low function call codes specifying target hardware environments.

0173In this case, the source target hardware environment is the monitor type and the destination target hardware environment is the simulator type. Thus low function call codes "MON_get_mem(adr,length,unit,image)" and "SIM_set mem(adr,length,unit,image)" are generated (see arrows y3 and y4 in FIG.13A). Code conversion routine 74 calls functions with the low function call codes.

0174When code conversion routine 74 calls a function with low function call code "MON_get_mem(adr,length,unit,image)," monitor control layer 61 is activated. Monitor control layer 61 reads data from prototype 30 one byte by one byte via serial transfer port 31, serial line 40, and dedicated terminal 39, as shown in the flowchart of FIG.11A. Monitor control layer 61 accumulates the read data in an area of shared work area 77 specified by argument "image." When monitor control layer 61 repeats this process n times as specified by field "SIZE," data with the length specified by argument "length" has been stored in the area of shared work area 77 specified by argument "image" (see arrow T1 in FIG.13A).

0175When code conversion routine 74 calls a function with low function call code "SIM_set_mem(adr,length,unit,image)," monitor control layer 61 transfers data, as the state information, from an area in shared work area 77 specified by argument "image" to an area in memory simulation routine 96 specified by argument "adr" (see arrow T2 in FIG.13A).

0176The above process is repeated for each of the other sub-commands: copyREG, copyBP, copyINT, copyI/O, and copyTRACE_DATA. When this completes, the operation states stored in the storages of prototype 30 have been transferred to simulator 10. This indicates that the state information has been transferred from prototype 30 to simulator 10 and that simulator 10 has succeeded the operation of prototype 30. Simulator 10 resumes the operation of the program with the succeeded operation state information.

0177FIG.13B shows the transportation of state information when the selectTARGET command specifying the ICE type is input while the program runs in the monitor type hardware environment. When code conversion routine 74 generates low function call code "ICE_set_mem (adr,length, unit,image)," ICE control layer 62 is activated. ICE control layer 62 issues the BIOS command to transfer the state information from an area specified by argument "image" to evaluation board 20 (see arrow T4 in FIG.13B). This indicates that the state information has been transferred from prototype 30 to evaluation board 20 and that evaluation board 20 has succeeded the operation of prototype 30.

0178FIG.13C shows the transportation of state information when the selectTARGET command specifying the monitor type is input while the program runs in the ICE type hardware environment. When code conversion routine 74 generates low function call code "ICE_get_mem (adr,length,unit,image)," ICE control layer 62 is activated. ICE control layer 62 transfers the state information from evaluation board 20 to an area specified by argument "image" (see arrow T5 in FIG.13C).

0179When code conversion routine 74 generates low function call code "MON_set_mem(adr,length,unit,image)," monitor control layer 61 is activated. Monitor control layer 61 transfers the data from the area specified by argument "image" to prototype 30 via serial line 40 (see arrow T6 in FIG.13C). This indicates that the state information has been transferred from evaluation board 20 to prototype 30 and that prototype 30 has succeeded the operation of evaluation board 20.

0180FIG.13D shows the transportation of state information when the selectTARGET command specifying the simulator type is input while the program runs in the ICE type hardware environment. When code conversion routine 74 generates low function call code "ICE_get_mem(adr,length,unit,image)," ICE control layer 62 is activated. ICE control layer 62 transfers the state information from evaluation board 20 to an area specified by argument "image" (see arrow T7 in FIG.13D).

0181When code conversion routine 74 generates low function call code "SIM_set_mem(adr,length,unit,image)," simulator 10 is activated. Simulator 10 transfers the data from the area specified by argument "image" to memory simulation routine 96 (see arrow T8 in FIG.13D). This indicates that the state information has been transferred from evaluation board 20 to simulator 10 and that simulator 10 has succeeded the operation of evaluation board 20.

0182FIG.13E shows the transportation of state information when the selectTARGET command specifying the monitor type is input while the program runs in the simulator type hardware environment. When code conversion routine 74 generates low function call code. "SIM_get_mem(adr,length,unit,image)," simulator 10 is activated. Simulator 10 writes the state information of itself into an area of shared work area 77 specified by argument "image" (see arrow T9 in FIG.13E).

0183When code conversion routine 74 generates low function call code "MON_set_mem(adr,length,unit,image)," monitor control layer 61 is activated. Monitor control layer 61 transfers the data from the area specified by argument "image" to prototype 30 (see arrow T10 in FIG.13E). This indicates that the state information has been transferred from simulator 10 to prototype 30 and that prototype 30 has succeeded the operation of simulator 10.

0184FIG.13F shows the transportation of state information when the selectTARGET command specifying the ICE type is input while the program runs in the simulator type hardware environment. When code conversion routine 74 generates low function call code "SIM_get_mem(adr, length, unit, image)," simulator 10 is activated. Simulator 10 writes the state information of itself into an area of shared work area 77 specified by argument "image" (see arrow T11 in FIG.13F).

0185When code conversion routine 74 generates low function call code "ICE_set_mem(adr,length,unit,image)," ICE control layer 62 is activated. ICE control layer 62 transfers the data from the area specified by argument "image" to evaluation board 20 (see arrow T12 in FIG.13F). This indicates that the state information has been transferred from simulator 10 to evaluation board 20 and that evaluation board 20 has succeeded the operation of simulator 10.

0186Arbitrary switching between the monitor type, ICE type, and simulator type hardware environments is achieved b the above described transportation of the state information.

0187The following is a description of work area analysis module 75, which is a component of target interconnect layer 52.

0188work area analysis module 75 includes a breakpoint management function, a trace data accumulation size management function, an interrupt generation condition management function, and an I/O mapping information management function. The breakpoint management function manages the memories of the hardware environments by dividing each memory into areas in which breakpoints can be set and areas in which breakpoints cannot be set. The trace data accumulation size management function manages, for each hardware environment, the sizes of the areas in which breakpoints can be set. The interrupt generation condition management function manages each hardware environment whether it has an ability to monitor whether an interrupt generation condition has been satisfied. The I/O mapping information management function manages the I/O mapping information.

0189work area analysis module 75 includes the breakpoint management function to deal with a case where description forms of interrupt instruction for setting breakpoint differ among the monitor type, ICE type, and simulator type. If a breakpoint is set in RAM in the source target hardware environment and the RAM corresponds to a ROM in the destination target hardware environment, for example, it is impossible to set the breakpoint in the destination target hardware environment. If the user does not know this fact in advance, the user will be embarrassed at a phenomenon in which a breakpoint becomes ineffective when the user switches the hardware environments. When this happens, the user may think this phenomenon as an error. Therefore, it is necessary for work area analysis module 75 to have a function to manage the memories of the hardware environments by dividing each memory into areas in which breakpoints can be set and areas in which breakpoints cannot be set.

0190FIG.14D shows information used for the breakpoint management function. The information includes: labels of the areas in which breakpoints can be set (e.g. VALID_AREA1), and the start and end addresses of the areas.

0191Work area analysis module 75 includes the trace data accumulation size management function to deal with a case where the memory sizes for the trace data differ among the monitor type, ICE type, and simulator type. If the source target hardware environment is simulator type and the destination target hardware environment is monitor type, for example, it is impossible to transfer all the trace data accumulated in the source target hardware environment to the destination target hardware environment. This is because the memory of the destination target hardware environment goes short of space for storing the trace data. When this happens, a part of the trace data is lost. If the user does not know this fact in advance, the user will be embarrassed at a phenomenon in which a part of the trace data is lost. Therefore, it is necessary for work area analysis module 75 to have a function to manage, for each hardware environment, the sizes of the areas in which breakpoints can be set.

0192FIG.14E shows information used for the trace data accumulation size management function. The information includes identification names (e.g. target1) for the hardware environments, and the maximum sizes of the memory areas in which breakpoints can be set.

0193Work area analysis module 75 includes the interrupt generation condition management function to deal with a case where some hardware environments may have an ability to monitor whether an interrupt generation condition has been satisfied and other hardware environment may not have such an ability. If the source target hardware environment is simulator type and the destination target hardware environment is monitor type, for example, the source target hardware environment may have such an ability since instruction executions can be counted by software; it is difficult for the destination target hardware environment to have such an ability unless the hardware construction is modulated for this purpose. Thus, the destination target hardware environment may not recognize the fulfilment of the interrupt generation condition. If the user does not know this fact in advance, the user will be embarrassed. Therefore, it is necessary for work area analysis module 75 to have a function to manage each hardware environment whether it has an ability to monitor whether an interrupt generation condition has been satisfied.

0194FIG.14F shows information used for the interrupt generation condition management function. The information includes identification names (e.g. target1) for the hardware environments and indicates whether the hardware environment can count the number of instruction executions (cycles). "VALID" in the drawing indicates that the hardware environment can count the number of instruction executions; "INVALID" indicates that the hardware environment cannot count the number of instruction executions.

0195Work area analysis module 75 includes the I/O mapping information management function to deal with a case where the number of effective peripheral I/O registers differs among the monitor type, ICE type, and simulator type. If the source target hardware environment is the monitor type and destination target hardware environment is simulator type, for example, only a part of the peripheral I/O registers are available in the source target hardware environment due to slow adjustment of the hardware environment; all the peripheral I/O registers are available in the destination target hardware environment since the hardware environment is simulated by software. Under such a condition, invalid values may be stored in the peripheral I/O registers of the destination target hardware environment. Therefore, it is necessary for work area analysis module 75 to have a function to manage the effective I/O registers for each hardware environment.

0196FIG.14G shows I/O mapping information used for the I/O mapping information management function. The I/O mapping information indicates values to be set in the peripheral I/O registers of the destination target hardware environment when the corresponding peripheral I/O registers of the source target hardware environment do not have values. "I/O REGISTER_ADDR1," for example, indicates the first peripheral I/O register; "PSW=STATUS1 0x1F" indicates that value "0x1F" should be set in the first peripheral I/O register when the PSW register of the processor in the destination target hardware environment stores value "STATUS1," "PSW=STATUS2 0x2A" indicates that value "0x2A" should be set in the first peripheral I/O register when the PSW register stores value "STATUS2," and "PSW=STATUS3 0x3B" indicates that value "0x3B" should be set in the first peripheral I/O register when the PSW register stores value "STATUS3."

0197The following is a description of the extended selectTARGET commands.

0198FIG.6B shows three major examples of the extended selectTARGET commands. The extension of a selectTARGET command is achieved by assigning a certain condition to the issue of the selectTARGET command. The three extended selectTARGET commands of FIG.6B have different conditions.

0199The IFbreak command instructs the source target hardware environment to run the debug target program, and issues the selectTARGET command when the execution of the program stops at the breakpoint specified by operand "breakNo."

0200The targetASSIGN command allows a table specified by operand "table∗" be resident in the source target hardware environment, instructs the source target hardware environment to run the debug target program, and issues the selectTARGET command based on the table. FIG.6C shows the table. As shown in the drawing, the areas each of which is ranging the first address to the end address have corresponding destination target hardware environments.

0201The switch command switches the hardware environments according to the value of variable "var." In the present embodiment, the switch command has two option cases: case '∗1' for variable value "∗1" and case '∗2' for variable value "∗2." In the present case, if the variable value is "∗1," hardware environment "target1" is activated; if the variable value is "∗2," hardware environment "target2" is activated.

0202The operation procedure of command interpreter 72 for each of the three extended selectTARGET commands is described below with reference to the flowcharts of FIGs.16-18.

0203Suppose the user inputs the targetASSIGN command into user interface layer 50. Control goes to step S71 of the flowchart of FIG.16 via step S83 of FIG.15. Command interpreter 72 judges in step S71 whether the operation code is "targetASSIGN." In this case, it is judged as yes. command interpreter 72 allows a table specified by operand "table∗" be resident in the source target hardware environment in step S72. Command interpreter 72 then sets breakpoints in all the start addresses in the table, in step S73. Command interpreter 72 runs the debug target program in step S74. Command interpreter 72 monitors the debug target program to see if it has stopped at a breakpoint (step S75). If such a stop is detected, command interpreter 72 checks to see whether the address of the breakpoint matches any of the start addresses in the table (step S76). If matches, command interpreter 72 issues the selectTARGET command specifying the destination target hardware environment corresponding to the matched start address.

0204Suppose the user inputs the IFbreak command into user interface layer 50. Command interpreter 72 judges in step S83 in the flowchart of FIG.15 that the operation code is not "selectTARGET." Control then goes to step S71 of the flowchart of FIG.16, and command interpreter 72 judges that the operation code is not "targetASSIGN." Control then goes to step S91 of the flowchart of FIG.17. Command interpreter 72 judges in the step whether the operation code is "IFbreak." In this case, it is judged as yes. Command interpreter 72 allows operands "breakNo" and "selectTARGETtarget" be resident in the source target hardware environment in step S92. Command interpreter 72 runs the debug target program in step S93. Command interpreter 72 monitors the debug target program to see if it has stopped at a breakpoint (step S94). If such a stop is detected, command interpreter 72 checks to see whether the address of the breakpoint matches operand "breakNo" (step S96). If matches, command interpreter 72 issues the selectTARGET command specifying the destination target hardware environment which is specified by operand "selectTARGETtarget" (step S97).

0205Suppose the user inputs the switch(var) command into user interface layer 50. Command interpreter 72 passes through steps S83, S71, and S91 with "no." Command interpreter 72 judges in step S100 in the flowchart of FIG.18 whether the operation code is "switch(var)." In this case, it is judged as yes. Command interpreter 72 instructs debug core layer 51 to convert variable "var" into a memory address "mem_adr(var.)" in step S101. Command interpreter 72 reads data from an area specified by memory address "mem_adr(var)" in step S102. Command interpreter 72 judges whether the read data matches either of "∗1" and "∗2" in step S103. If it matches, command interpreter 72 issues the selectTARGET command specifying the destination target hardware environment ("target1" or "target2") which corresponds to the matched value, namely, "∗1" or "∗2" (step S104).

0206As will be understood from the above description, the present embodiment enables the operator to switch the hardware environments at any state of debugging with a simple procedure, that is, by issuing the selectTARGET command. That means the operator can analyze the cause of bugs in another hardware environment without a trouble reproducing the same situation. This allows the operator to effectively use the time for developing products.

0207The above advantage is remarkable when bugs are found in a hardware environment, such as the monitor type, which has poor analysis functions since the hardware environment can be changed to another hardware environment with affluent analysis functions, such as the ICE type and the simulator type.

0208The above environment shows only one example of systems which displays best effects currently available. The present invention can be changed or modified unless such changes and modifications depart from the scope of the present invention, that is, as long as the invention includes a simple change between the hardware environments. The following are examples of such modifications. <ul id="ul0004" list-style="none" compact="compact"><li>(a) In the present embodiment, the supervisor program is stored in a memory. The supervisor program, however, may be included in debug core layer 51. Alternately, target interconnect layer 52 may be included in debug core layer 51.</li><li>(b) In the present embodiment, it is assumed that the setting of breakpoints, trace data , and interrupts are available in the destination target hardware environment. However, in case any of such functions are not possible in the destination target hardware environment, certain functions that are available may be specified.</li><li>(c) In the present embodiment, all the contents of work area 38 are transferred to the destination target hardware environment. However, only a changed part of previously transferred data may be transferred. This will lessen the load of transfer. To achieve this, the data in the stack area and the external variable area is stored in debug core layer 51 or target interconnect layer 52 as a backup. When the selectTARGET command is issued, data to be transferred is compared with the backup, and only a changed part is transferred to the destination target hardware environment. The changed part or data including the changed part may be stored in a storage.</li><li>(d) A changed part of data may be transferred to other hardware environments each time the data is changed. In such a case, the hardware environments are changed with higher speed since it is not necessary to transfer data from memory to memory.</li><li>(e) In the present embodiment, all the values of registers are transferred to the destination target hardware environment. However, only changed values of registers may be transferred. In such a case, the hardware environments are changed with higher speed since it is not necessary to transfer values of all the registers.</li><li>(f) The "area break" may be used if this function is available in the target hardware environments. With the area break, an area can be specified as the breakpoint.</li><li>(g) In the present embodiment, a command for switching the hardware environments according to the value of a variable is described. There may be used a command, instead of the above command, for switching the hardware environments according to the value of a parameter.</li><li>(h) A command may be used in which the change of the hardware environments, the generation of an interrupt signal, and the state of the destination target hardware environment are specified. By issuing such a command, the debug target program may be monitored in the destination target hardware environment for a specified interrupt in a specified state.</li><li>(i) A command may be used in which the change of the hardware environments, the first and the second destination target hardware environments, the change of the contents of a certain memory or a certain register, and the monitoring of the memory or register are specified. By issuing such a command, the debug target program may be monitored when the contents of the memory or register are changed in a specified hardware environment.</li><li>(j) A command including a table may be used in which the change of the hardware environments is specified, where the table shows a plurality of hardware environments and corresponding scheduled execution times. By issuing such a command, the debug target program may be monitored in specified hardware environments at specified execution times.</li><li>(k) In the present embodiment, the debug is stored in memory 24 and memory simulation routine 96. However, the debug information may be held in debug core layer 51 and target interconnect layer 52. With such an arrangement, it is virtually unnecessary to read the debug information from monitor control layer 61, ICE control layer 62, and simulator 10 of target dependent layer 53. It is also unnecessary for command conversion routine 73 to issue function call codes "TCI_get_mem, "TCI_get_reg," and "TCI_get_BP." Although the present invention has been fully described by way of examples with reference to the accompanying drawings, it is to be noted that various changes and modifications will be apparent to those skilled in the art. Therefore, unless such changes and modifications depart from the scope of the present invention, they should be construed as being included therein.</li></ul>