JPH01307837A - Mpu simulation method and mpu simulator - Google Patents

Abstract

PURPOSE:To debug a program only with software by filing data of hardware environments and external phenomena and performing simulation based on data of this file. CONSTITUTION:When an MPU simulator is started, data of hardware environments of a simulation object MPU is loaded from a configuration file CF where configuration information is stored. Various timing signals to be supplied to terminals of the MPU are loaded from an external phenomenon file EPF as test data. A target program TP as the debugging object is loaded to memory table MRTY. When execution of the program TP is indicated in this state, a debugger DBG instructs an MPU module MM to execute and stop instructions of the MPU, and execution of instructions of the MPU is simulated in the module MM.

Description

[Detailed Description of the Invention] [Industrial Application Field] The present invention relates to an emulator device used when developing equipment controlled by an MPU (microprocessor unit), and in particular, to an emulator device for debugging a control program. 7 Millennium method and simulator for.

[Conventional technology]

In recent years, it has become common practice to control electrical devices and the like using MPUs. The MPU is an integrated circuit in which a logic operation unit, program memory, data memory, register, interface, etc. are formed on the same chip, and can perform various controls by changing the program.

The equipment controlled by this MPU is basically divided into three parts. For example, taking a copying machine as an example, as shown in FIG.
, an MPU 202, and an electric circuit board 203 that provides an interface between the two.

The copying machine main body 201 is provided with a sensor for detecting the state of copying operation and a switch for receiving instructions from the control panel.
Inputs from switches etc. are first supplied to the electric circuit board 203, where predetermined signal processing is performed, and then the M P
, U2O5 as input data. Also, some of the inputs are provided as interrupt signals to MPU2O5. The output data that has undergone predetermined processing in the MPU2O5 is supplied to an electric circuit board 203, and from this electric circuit board 203, data is sent to control driving parts such as motors and solenoids provided in the copying machine body 201. Outputs the signal.

When developing a copying machine controlled by such an MPU2O5, in parallel with the design of the copying machine body 201, that is, the mechanical design and the electrical circuit design, software development, that is, software that is executed by the MPU of the device, is carried out. A target program will be developed.

Figure 28 shows the general development procedure when developing equipment controlled by an MPU. When a product is planned, basic specifications are designed, and based on these specifications, mechanical design and electrical Circuit design and software development are carried out in parallel.

Here, conventional software development will be explained.

First, the software specifications of the MPU 1 used in the copying machine that is the object of development, that is, the target MPU, are created. A source program is then created based on this specification. When creating and editing this source program, an editor on a minicomputer, for example, is used as a development tool. This source program is then converted into an object program by the compiler or assembler of the development tool. After this, it is necessary to debug this object program.

For this reason, conventionally, in-circuit emulators are generally used as development tools for debugging. This in-circuit emulator is connected to replace the MPU and simulates the operation of the MPU, and is capable of displaying the operation of each step and the contents of registers.

[Problem to be solved by the invention]

However, traditional in-circuit emulators
It is used by being connected to the actual electric circuit board 203, and debugging cannot begin until the prototype of this electric circuit board 203 is completed, which delays the debugging process. For this reason, due to design period constraints, etc., the device is sent to the next step of actual device debugging before complete debugging is performed.

In this actual device debugging, the Targetera MPU is combined with an actual electrical circuit or mechanical part and the software is inspected, but a large number of bugs are discovered at this stage. In addition, troubles discovered at this stage require a great deal of time and effort to investigate the cause and take countermeasures, resulting in a problem in that the development efficiency of the system as a whole is significantly reduced.

Further, only one type of MPU can be debugged, and when the type of MPU changes, it is necessary to use another in-circuit emulator. Furthermore, in conventional in-circuit simulators, M
The signal supplied to the input terminal of the PU is a predetermined static voltage, and it was not possible to perform simulations by dynamically changing the signal supplied to the input terminal as in actual operation. .

The present invention was devised to solve the above-mentioned problems, and its purpose is to enable debugging of a single piece of software during software development, and to easily support multiple MPUs. shall be.

[Means to solve the problem]

In order to achieve the above object, the MPU simulation method of the present invention reads the hardware configuration information of the MPU to be simulated and various timing signals supplied to the terminals of the MPU as file data, and also It is characterized by reading a program and using these data to simulate the execution of the target program according to the instruction execution structure specific to the MPU to be subjected to simulation.

Furthermore, in order to achieve the above object, the MPU simulator of the present invention stores a configuration information file that stores hardware configuration information of the MPU to be simulated, and data of various timing signals to be supplied to the terminals of the MPU. an external event file for processing, a user interface for processing input commands from a terminal or information displayed on the terminal, and a memory table contents into which a target program is loaded based on commands entered via the user interface. A debugger that instructs to display change 1, execute target program, stop, etc.
and an MPU module that simulates the execution of the target program according to a structure specific to the MPU to be simulated using data from the configuration information file and the external event file based on instructions from the debugger. Features.

[Effect]

The operation of the present invention will be explained in detail by giving an example with reference to FIG.

In the present invention, when the MPU simulator is started, data on the hardware environment of the MPU to be simulated is loaded from the configuration file CF in which configuration information is stored, and is to be supplied to the terminals of the MPU. Various timing signals are loaded as test data from the external event PF. Furthermore, the target program TP to be debugged is loaded into the memory table MRYT. When the execution of the target program TP is instructed in this state, the debugger DBG instructs the MPU module MM to execute or stop the MPU instructions, and the execution of the MPU instructions is simulated by the MPU module MM. Therefore, the object program is executed under substantially the same hardware environment as that of the actual machine.

When simulating this MPU, various commands are input to the debugger DBG from the keyboard etc. via the user interface old F, and the debugger DBG
MPU module based on instructions from! ,+3.1 the execution of the MPU instructions is simulated. The execution result is the user interface UIF
displayed on a display etc. via . If a trouble occurs during program execution, this trouble is displayed on the terminal display, etc., and the user uses commands from the debugger DBG to analyze and correct the cause of the trouble.

The MPU modules M are provided depending on the type of MPU, and select the MPU to be simulated based on an instruction when starting the MPU simulation.
MPU module compatible with U! AM is selected. Therefore, even if the types of MPUs are different, the debugger DBG, user interface old F, etc. can be used in common. That is, MPU module)Aλ1
By simply switching, it is possible to easily support many types of MPUs.

〔Example〕

DETAILED DESCRIPTION OF THE INVENTION Hereinafter, features of the present invention will be specifically described based on examples with reference to the drawings. In addition, in this example, M
An example of developing a control program for a copying machine controlled by a PU will be described.

FIG. 2 is an explanatory diagram showing an example of the hierarchical structure of the entire software configuration of a copying machine simulator including the MPU simulator of the present invention, and FIG. 3 is an explanatory diagram showing an outline of an example of the software configuration of the MPU simulator of the present invention.

As shown in FIG. 2, the MPU simulator M of this embodiment
S is located as one of a plurality of program blocks constituting a copying machine simulator C3 that simulates the operation of a copying machine.

That is, the copying machine simulator C3 includes a configuration generation unit CG that generates information regarding the hardware settings of the MPU, and an external event data generation unit that generates test data indicating the changing state of the signal to the input terminal of the MPU. EP
It consists of an MPU simulator MS that performs DG and MPU simulation.

M P U 'y Mi, Lake MS Ha, UN I
It executes MPU simulation under the management of an operating system called X (registered trademark), and as shown in FIG. 3, it consists of five subsystems having a tree structure.

That is, a simulator SIM for starting a program, and a debuffer D that receives commands from the user interface IIIF (described later) and processes accordingly.
An MPU module that executes one instruction of OG and MPU! J), l, User interface UIF that analyzes commands from the terminal's keyboard, etc., converts them into a format that can be understood by the debugger 08G, passes them on, and returns processing results to the terminal's display, etc.
and a loader LDR that loads the target program TP into the virtual memory space of the MPU, for example, the memory table MRYT.

The details of these subsystems will be described later, but each subsystem is highly independent of each other, and as described later,
For example, by switching the MPU module H, it is possible to simulate various MPUs.

Furthermore, each subsystem is composed of an IJ module that has functions called from other subsystems, and submodules that perform various internal processes.

FIG. 4 is a block diagram showing the hardware configuration of the MPU simulator of this embodiment.

In FIG. 4, 1 is a central processing unit that controls the entire MPU simulator and processes data.

A main memory 2 is connected to the central processing unit 1 . Furthermore, a keyboard 4 for inputting various data and instructions and a display 5 for displaying processing results etc. are connected to the central processing unit 1 via a serial data line 3a. In addition, keyboard 4 and display 5
A plurality of sets of terminals are arranged, and the central processing unit 1 processes a plurality of tasks in a time-sharing manner. Further, a disk device 6 for storing programs and data is connected to the bus 3 of the central processing unit 1.

The disk device 6 stores, as files, software resources such as program bodies and data necessary for all processes being executed by the MPU simulator, and when executing the program, the disk device 6 The programs and data in main memory 2
The central processing unit 1 uses these software resources to proceed with necessary processing.

The relationship between each subsystem in the MPU simulator of this embodiment will be explained with reference to FIG.

As shown in the figure, the MPU simulator of this embodiment is broadly divided into emulator SIM, debugger DBG,
MPU module M)4. User interface [consists of five subsystems: IIF and loader LDR.

And for these subsystems, target program TP, configuration file CF
, external event file EPF, ) race file T
An external file such as F is provided.

In addition, the external tables include the configuration table CFGT, external event table PT, command table CMDT, and register information table R.
IT, terminal function table TPT, MPU execution status table! , 1EST, Memory table! J
RYT, message table! , l S G
T is provided. Furthermore, a message buffer (message buffer) and IB are provided as external buffers.

The outline of the configuration of each file and table will be explained below. Note that details of the items will be described later.

The target program TP is a disk file and is a program in a hex format file format that the user wants to run on the simulator, that is, to be debugged. Note that the disk file here means a file stored in the disk device 6 shown in FIG. 4.

The configuration file CF contains information such as the MPU operating clock, default file name of external event file, capacity and address of additional RAM and ROM, serial clock frequency, MPU type, etc., corresponding to the MPU to be simulated. This is a disk file that stores MPU hardware data, and is a disk file that stores MPU hardware data.
Prior to the activation of M, necessary data is generated by the configuration generator CG shown in FIG. 2 and stored in the configuration file CF.

Further, the configuration table CFGT is a memory file corresponding to the configuration file CF. This configuration table CFGT
is the user-defined configuration file C
It is generated by analyzing F and has the configuration shown in FIG. 6, and its contents are shown in Table 1.

Table 1 Note that the ID number is 8-bit data that indicates the type of MPU. "1" is assigned to the μP07811, which is a built-in program version of the μP07810.

Similarly, different I
Assign a D number.

The external event file EPF is a disk file that stores the properties of signals supplied to the terminals of the MPU, such as logical signal names, terminal function names, attribute single output type, start time, number of repetitions, and data itself. , is created as a data statement by the external event data generation unit EFDG shown in FIG. 2, prior to starting up the simulator SIM.

A logical signal name is a signal name arbitrarily assigned by the user,
If the input is omitted, it will be the same as the terminal function name explained below.

The terminal function name is a name for a terminal or a group of terminals of the MPU, and uses a predetermined name as described later.

Further, the attribute specifies the attribute of data, and rdJ means 8-bit data. Moreover, "S" is 1-bit data, that is, 2. It means that it is value signal data. Note that this attribute is paired with the terminal function name.

The input/output type distinguishes between input and output, and Fi
l means input to the MPU, and "0" means output from the MPU.

The start time specifies the start time of data using the number of MPU clocks, and the simulator specifies the start time of the data as described below.
run) J or [step (step) J ko? The data becomes valid when the accumulated clock after starting execution by the command reaches the specified clock.

The number of repetitions specifies the number of times specified data is repeated.

The data itself is defined according to the attribute, and in the case of 8-bit data, it is specified by two hexadecimal digits, and in the case of signal data, it is specified by "h" or "1".

An example of a data statement in this external event file EPF is shown below.

data s+data, rxd, d, +, 150,
3. "30.if" The signal defined in this data statement is
The logic signal name is input 8-bit data of rsidajaJ, and the integrated clock is 150 from the special sale, r30J is input to the terminal with the terminal function name rrxdJ, and the data of Nfj is 3.
This indicates that it will be supplied repeatedly.

data dataQ, paQ, s, i, 1
0.3. h, l, l, bi Also, the signal defined in this data statement is the input signal data with the logical signal name radataOJ, and from the point in time when the integration clock is 10, a high level is applied to the terminal with the terminal function name rpaOJ. , low level, low level.

This shows that a low level signal is repeatedly supplied three times.

In addition, the external event table L-IEPT can be used with the debugger [
]The above external event file EPF informed by BG
This is a table on the main memory 2 that formats and temporarily stores the data. An example of the structure of this external event table EPT is shown in FIG. 7, and its contents are shown in Table 2.

Table 2 The register information table RIT is a table on the main memory 2 that stores information regarding each register of the MPU, and has the configuration shown in FIG. 8, and its contents are shown in Table 3. A plurality of register information tables RAT are provided corresponding to each MPU.

Table 3 An example of registers for the μP07811 described above is shown in Table 4. In addition, Table 4 (a) shows the general distribution, and the same table et al.)
indicates a special register, and (C) in the same table indicates a request register.

For details of each register of this μP07811, please refer to “μC0M-87AD μ
P07811 User's Manual (16M768G
), so a detailed explanation will be omitted here, only listing the types of registers.

(Hereinafter, blank spaces) Table 4 (a) Table 4 (b) Table 4 (C) The terminal function table TPT is a table on the main memory 2 that stores information regarding the terminal functions of the MPU.
It has the configuration shown in FIG. 9, and its contents are shown in Table 5. A plurality of terminal function tables TPT are also provided corresponding to each MPU.

The terminal function names in Table 5 are names for terminals or terminal groups of the MPU, and predetermined names are used.

Table 6 shows an example of terminal function names when μP07811 is used as the target MPU. In the table, I in the column of input/output type J indicates input, 0 indicates output, and Ilo indicates human output.

(Space below) Table 6 A schematic hardware configuration of the μP07811 itself described above is shown in FIG. Regarding the configuration of this μP[]7811 itself, please refer to the above-mentioned “μCO!J-87A Dμ
P[]7811 User's Manual (IE!, +7
686) Since it is described in detail in Section 686), only an outline will be given here.

In the MPU shown in FIG. 10, the program to be executed is program memo IJP! ,! is stored in. When a program is executed, the instruction at the address specified by the program counter IC of the register section RB is stored in the instruction register IH and interpreted by the instruction decoder 10. Then, based on this interpretation result, necessary processing is performed on the internal data or data input from the outside. Instructions and data flow within the internal data bus IDB, and data that requires an operation is supplied to the arithmetic logic circuit ALIJ via the latches LTCI and LT[:2, where the specified operation is performed. At this time, the external data necessary for execution is serial output unit 5IO1 interrupt control unit + NTC, timer TI
It is input from MER, timer/event counter TlEC, A/D converter ADC, port section PB, etc. The state of the flag after the calculation is stored in the program status word section PSW.

The data after the operation is stored in a predetermined register in register fiRB or data memo IJD! Stored in J. In addition, if necessary, the serial input unit SID and the timer T I!
, I E It.

The signal is output to the outside of the MPU via the timer/event counter TEC, port section PB, etc.

The explanation will be given below by returning to FIG.

Memory table! , IRYT is a table on the main memory 2 having an address space of 64 bytes into which the target program TP is loaded.

Command table C! The JDT is located between the user interface [lIF and the server DBG.
Main memory 2 where the user interface UIF stores data if there is a correct input from the user.
The above table has the structure shown in FIG. 11, and its contents are shown in Table 7.

Table 7 Debugger DBG performs processing according to the sent command number and parameters.

Furthermore, the message table M S G T is a table in the main memory 2 that stores messages that are not to be output to the display 5.Next is the MPU execution status table! A E S T
is a table in the main memory 2 that has information regarding the execution operations of the MPU, and the MPU modules も, +!
, 1 to the debugger DBG to report errors that occur during instruction execution. This MPU execution status table 1.1 EST has the configuration shown in FIG. 12, and an example of its contents is shown in Table 8.

To explain each item in Table 8, first, the reset signal continuation occurs when the input to the MPU reset terminal remains at a low level and does not go to a high level.
It is set by 4.

The presence or absence of a reset signal is determined when there is a low level input to the MPU reset terminal.
It is set by The presence or absence of execution of a halt instruction indicates whether or not there was a halt instruction, that is, an instruction to stop the MPU. Port access error is M
This indicates whether or not there has been an illegal access to a PU port, and is set, for example, when there is an instruction that attempts to write data to an input terminal. An address access error indicates that an illegal address was accessed, for example in the configuration file CF
This is set when an address area not defined in is accessed. An instruction execution error indicates that an error occurred during instruction execution, such as when an instruction was not defined! Two cents will be given. The calculation error indicates that an error has occurred during calculation, and is set, for example, when dividing by 0 or when a finger becomes warm. The last memory map error indicates an illegal access to memory,
For example, it is set when there is an instruction to write data to the ROM area.

Next, the internal tables of each subsystem will be explained.

The debugger DBG includes internal tables: debugger status table DST, breakpoint table BPT, race mode table TMT, line buffer LB, and message editing table! , lET, etc. are provided.

Debugger status table DST is debugger DB
This is a table on the main memory 2 that stores various information regarding the execution operations of G, and has the configuration shown in FIG. 13, and its contents are shown in Table 9.

Table 9 Note that the initial state of this debugger status table DST is set to simulation mode, no target program, and no external event file. Also, M
The PU status is a copy of the contents of the MPU execution status table MEST (see Table 8) shown in FIG.
It is read from the U execution status table MEST and updated.

The breakpoint table BPT is a table on the main memory 2 that stores breakpoint information, and has a configuration in which, for example, five breakpoints can be set as shown in FIG. 14. Table 10 shows examples of breakpoint settings.

Table 10 In the example shown in Table 10, the program temporarily stops at three locations: address a090, address bb12, and address 0210 (all expressed in hexadecimal). Note that -1 in the table indicates that no breakpoint has been set.

Trace mode table TMT (c) This is a table on the main memory 2 that stores various modes of race execution, and has the configuration shown in FIG.
It is shown in Table 1.

Table 11 Note that in the initial state, there is no trace and the file is closed.

Line buffer LB is user interface UIF
is a memory buffer that takes one line of input from
For example, it has a capacity to store 256 character data.

The message editing table MET is a memory buffer for message editing, and has a capacity to store, for example, 256 character data.

Next, the MPU module! The internal table of AM will be explained.

MPU module), 1M has as an internal table,
Register table RT, terminal table TT, MPt
J status table MST, pace clock table BCT.

Execution timer table ETT, instruction set table IST
and an instruction analysis table IAT.

Register table RT stores all registers in actual M
It is a table in the main memory 2 that has the same size as the PU register and stores actual information.As shown in FIG. 16, it is a table in the main memory 2 that stores real information. Consists of tables. The general register table, special register table and request register table are shown in Table 4 (a), (
This corresponds to each register described in b) and (C). The program status word table also includes the program status word section of the MPU (PS in FIG. 10).
This is a table on the main memory 2 that has the same function as (indicated by l'l), and has areas such as a zero flag, a skip flag, a half carry flag, an Ll flag, and an LOl flag carry flag.

The terminal table TT is a table on the main memory 2 that stores actual information regarding terminal functions, and has the configuration shown on the 17th page, and its contents are shown in the 12th table.

The twelfth MPU status table MST is a table on the main memory 2 that has information regarding the execution operation mode of the MPU, and has the configuration shown in FIG. 18, the contents of which are shown in Table 13.

Note that the reset information in Table 13 is obtained by converting the low level input to the reset terminal into clocks, and here, when the number of clocks exceeds 60, the MPU is reset. Further, El indicates a state in which interrupts can be accepted, and DI indicates a state in which interrupts cannot be accepted.

The base crotter table OCT is a table in the main memory 2 containing information regarding clock operations, and has the structure shown in FIG. 0 time interval, whether level 1 is high level or low level, level 1 time interval, 1 black ivy time interval, whether current level is high level or low level, 1 clock relative time , the clock count number and the total clock number.

The execution timer table εTT is a table in memory containing information regarding execution time, and has the structure shown in FIG. 20, where 1 basic tarlock time 1 total execution time 1 total number of locks to be executed, and 1 instruction time.

It consists of 1 number of instruction states, 1 number of instruction clocks, 2 total steps, 1 number of interrupt clocks, and interrupt time.

The instruction set table IST is a table in memory that has information regarding the operation code, classification code, number of states required during execution, etc. for each instruction, and is referred to during instruction analysis to be described later.

The last instruction analysis table IAT is the memory table M
This is a table on the main memory 2 containing various information for analyzing and executing the object of the target program read from RYT, and has the structure shown in FIG. 21, and has an instruction code number.

First operand, second operand, instruction code length.

It has information on the number of first states and the number of second states.

How the above-mentioned pace crotter table BCT, execution timer table ETT, and instruction analysis table [AT are referred to will be described later.

Furthermore, the old user interface F includes a command classification table COT and a command set table CST.

A command check table CCT and the like are provided.

:177) 'Min iTable COT displays the contents of the command line for each command input by the user.

This is a table that is broken down into delimiters and parameters and set (see Figure 22). The command set table C3T also contains a command number for each command.

Command character strings, parameter default values, and input formats are registered in code (see FIG. 23). Further, the command check table CCT is a temporary table in which the registered contents of the corresponding command are copied from the command server f-pull C3T every time a user command is input. When the character string of the command input by the user matches the contents of the character string of the command set CHIFLE C3T, this table is created and it is checked whether the user input is correct.

As a result, if the command is correct, it is set in the command table CMDT provided as an external table.

FIG. 24 schematically shows the relationship among the command classification table COT, command set table C3T, and command check table CCT.

Next, each entry module of the MPU module M L+ will be explained.

The MPU module MM is required to have the following functions.

(i) Execute one MPU instruction.

(ii) According to the request of the debugger DBG, the MPU
Notifies status information, registers, memory contents, etc.

(iii) Register specified by debugger DBG,
Set the value of the memory area.

(1v) The debugger DOG notifies the external input, and conversely notifies the debugger DOG of the contents of the external output.

In order to realize these functions, MPU module M
has the following multiple entry functions:

c-initial register table RT,
Function c-asmadrs that accesses the terminal table TT etc. and resets the MPU state in hardware: Function that stores the start address when assembler statement is input c-asm: Converts assembler statement to object code and stores it in memory. Function c-disasm to store in a predetermined memory space in table MRYT: Function to refer to instruction analysis table IAT and write the specified memory range to message buffer MB as a disassembler image c-memprint: Specify the specified memory range in format Message buffer with display image! IBi write function c-regprint: Displays the contents of the specified register in the specified format in the message buffer MB+:
Function to write m c-memwr+te: Function to write specified data to specified address C-regWrlte: Function to write specified data to specified register c-memfill: Function to fill specified memory range with specified data c-inpadrs: Function c-input that stores the start address for continuously inputting hexadecimal data: Function that writes input hexadecimal data sequentially from the address specified by the function rc-inpadrsj C-eXec: One step of the address pointed to by the current program counter Note that this function rc-execJ is basically as shown below! Processing is performed in sequence.

This will be explained with reference to FIG. 25. First, before execution, the execution status flag is cleared (step 51).
.

(1) Refer to the instruction table IST in the MPU module 1.4M in which the number of states required for execution of the operating lane concode 9 classification code 1 is registered for each instruction analysis instruction.
1 Analyzes the execution content, time required for execution, etc., and stores the analysis content in the instruction analysis table IAT.

(2) Instruction execution The command is executed according to the contents of the command analysis table IAT.

Also, this instruction causes the register table RT to be updated.

Memory table MRYT, terminal table TT
etc. Furthermore, if there is a halt instruction or memory access error, the MPU execution status table M
Write the contents to EST (that's all, step 5)
2).

(3) Execution time update The execution timer table T, which stores various information regarding execution time, is updated.

(4) Update the base clock table BCT that is referenced when executing functions such as the pace clock update timer and event function.゛(5)
Executes the timer, event, serial interface functions, etc. of the function execution MPU. When executing this function, the base clock table BCT is referred to, and the terminal table T
T, the register table RT is accessed (step 53).

(6) Trace execution According to the trace settings in the MPU status table MST, internal trace and external trace are processed and the processing results are written to the trace file TF (Step 5
4-57).

(7) Refer to the flag in the interrupt analysis execution register table RT to determine whether there is an interrupt. If there is an interrupt, the program counter Ic in the register table RT is rewritten to the start address of the interrupt program (step 53).

(8) External event capture When the execution mode in the MPU status table MST is simulation mode, the external event table EPT is read while referring to the execution timer table ETT.
The external event is taken in from the terminal table TT and the like is set (step 59).

And finally return.

The above is the explanation of the function "c-execJ".

The explanation of the functions will be continued below.

c-time: A function that refers to the execution timer table ETT and informs the previous execution time c-status: A function that refers to the MPU status table 14sT and returns the current status c-exin: Refers to the external event table EPT Function c-exout that takes in an external input event: Function c- that notifies external event input
config: MPU status table 11! MPU with reference to ST! The function c-opbyte: which sets the t1 production environment is a function which returns the number of instruction bytes of the instruction pointed to by the current program counter.Next, the functions in the user interface UIF will be explained.

The user interface LIIF performs processing for displaying terminals such as the keyboard 4° and the display 5, and is required to perform the following functions in response to requests from the debugger DBG.

(i) Display the output from the debugger DBG on display 5.
to be displayed.

(ii) Input a command line from the keyboard 4, analyze it, and convert it into a format that the debugger DBG can understand. At this time, check for grammar errors.

(iii) Pass one line of input from the keyboard 4 as is to the debugger DBG.

(iv) Pass one character input from the keyboard 4 as is to the debugger DBG.

To implement these functions, the user interface UIF has multiple entry functions described below.

u-display: A function that displays the given character string data on the display 5 of the terminal u-comin: Displays the input command by referring to the command table CMDT, register information table RIT, terminal function table TPT, etc. A function ug that checks the syntax and, if it is grammatically correct, sets a predetermined command number and parameters in the command table CMDT and returns to the debugger DBG.
etline: Function 1-getchar that takes one line of character string until the newline key on keyboard 4 is pressed and writes the contents to the address of the temporary memory buffer (not shown) specified by the file pointer.
:A function that takes one character from the keyboard 4 and returns that character as it is to the debugger DBG as a function value Next, for details of the functions of each subsystem, see the subsystem relationship diagram in Figure 5 and the flowchart in Figure 26. Refer to the following and explain the operation procedure. Note that in the following explanation, each step is processed by the debugger DBG, except where particularly noted.

Note that, prior to starting the simulator SIM, the configuration generation unit CG shown in FIG. 2 generates necessary data corresponding to the MPU to be used and stores it in the configuration file CF. Similarly, the external event data generation unit EPDG generates necessary test data and stores it in the external event file EPF.

The simulator SIM is started by a predetermined startup command at the UNIX command level, and the debugger DBG instructs the simulator SIM to load the target program TP.
Let me know. For example, the MPU to be simulated is the μP07811 mentioned above, and the file name of the target program TP to be debugged is rte.
stJ, input rmpu7811 test J from the keyboard 4 shown in FIG.

When the simulator SIM is started in this way, first,
The configuration file CF is loaded (step 101), and then the internal tables of the debugger DBG and MPU module MM are initialized (step 102).

Also, the debugger DOG calls the loader LDR and stores the target program TP in the memory table! ,IRY
T (step 103). Next, the external event file EPF is loaded (step 104), the user interface [IIF] is called from the debugger DBG, and it waits for input of a debugger command (step 105) and accepts user input (step 106).
). Note that these steps 105. 106 is performed by the user interface UIF.

That is, at step 105, the user interface old F is called from the debugger DBG in the form of call u-comin(), and the simulator S is called from the keyboard 4.
I Wait for IJ command. Then, when the user inputs one line, the command table CMDT is referred to to check for grammar errors. If there is a syntax error, use the ru-di function of the user interface tlIF.
Call sprayJ to display an error message, set the function value to 0, and return to debugger DBG. Also, if it is grammatically correct, the command table CMD
The necessary parameters are placed in T, the command number is placed in the function value, and the process returns to the debugger DBG. Note that when this function ru-cominJ is called, r (mpu) is displayed as a prompt on the display 5.
Display J.

An example of the debugger command is shown below.

The assemble command rasmj is a command for changing memory contents using assembler mnemonics. When this rasmJ command is received, the debugger DBG
After checking the start address, calls the function r c-asmadrs J of the MPU module MM,
Notifies the starting address of assembler input. After that, the user interface IJIF function ru-displ indicates that the assembler mnemonic input mode is entered.
Notify users through ayJ. When entering the assembler mnemonic input mode, the user interface U
[F's function "u-getline" is called.

This function [u-getlineJ executes 1 line input until the newline key input without checking the input for grammatical errors.
Returns the line input as is. Debugger DOG uses this as M
PU module j, l! , pass it as is to MPU
module! ,1! , 1 analyzes this statement, converts it into an object, and stores it in a predetermined location.

When normal, the MPU module (AM) waits for the next input, but when abnormal, it displays an error message and then waits for the input. Note that when the input is only the line feed key, the assembler mnemonic input mode is canceled, the function ru-cominJ is called, and the command input mode is entered.

For example, if you want to change the program contents starting from memory address 0215 to data corresponding to rmvi a, 0OhJ, while the r (mpu) j prompt is displayed, enter the address r0215j and press the new line key. Then, this entered address becomes a prompt and waits for input, and then rmvi a, 0OhJ
When you input this and press the new line key, the input assembler statement, ie, rmvi a, 00hJ, is converted into an object, and ``69'' is stored at address 0215 and ``00'' is stored at address 0216. In addition, rmv
i a, 0OhJ is an instruction of μP07810 and μP07811 to put hexadecimal “00” into the A register.

The break command rbreakj is a command for setting up to five breakpoints, and upon receiving this command, the debugger DBG rewrites the contents of the breakpoint table BPT. In addition, the debugger DBG is
Before executing one step, the MPU module M is inquired about the program counter value and the number of instruction bytes, and if the breakpoint is included in the address space of the program to be executed, execution of the program is stopped at the breakpoint.

The clear command "clearJ" is the above rbreak
J: This is a command to cancel the breakpoint set in step 17.

The debug command rdebugJ is a command that initializes the simulator, and if a target program is specified, this program is
Loaded onto RYT.

The disassembly command rdisaassembleJ is a command that disassembles the contents of memory and displays it in assembler mnemonics. This command uses the MPU address and number of words as parameters.
Call the function rc-disasmJ of module MM. The MPU modular IAM creates a display image of the result of disassembly, stores it in the message buffer) 4B, and then returns to the debugger []BG.

The debugger DOG displays the results on the display 5 via the user interface tllF.

The external event load command r external J is
This command loads the contents of the specified external event file EPF onto the memory table MRYT.

The fill command rfillJ fills the memory table M R
This is a command that fills the address space in the specified range of YT with specified data.

The help command rhelpJ is a command that displays a list of all commands of the MPU simulator.

The input command rinputJ is a command that continuously sets hexadecimal data from a specified address.

The mode command rmodeJ is a command for specifying/changing the execution mode of the simulator. The simulator of this embodiment has two execution modes: a program mode and a simulation mode. In the program mode, only the target program TPO execution operation is performed, and in the simulation mode, simulation including external events is performed. When the simulator is started, it automatically enters simulation mode, but the execution mode can be changed using this rmodeJ command.

The print command rprintJ is a command that displays the contents of registers, memory, etc. of the MPU, and uses the starting address, number of words, register salt, and display format as parameters to print the function rc-me of the MPU module MM.
Call mprint J or rC-regprintJ. The MPU module MM creates data in the designated address space or designated register as a display image, stores it in the message buffer MB, and then returns to the debugger DBG. The debugger DOG displays the results on the display 5 via the user interface [IIF].

The termination command rquitJ is a command for terminating the simulation, and upon input of this command, the system returns to the UNIX command level.

The run command rrunJ is the target program T.
This is a command to execute P from a specified address.

When this command is received, it instructs the debugger DBGliMPU module MM to execute. The MPU module MM rewrites the value of the program counter in the register table RT to the designated address, and then executes the program step by step.

(2) When executing a step, the debugger DBG refers to the current setting status using the debugger status table DST.

Breakpoint display command rshow break
J is a command that displays a list of setting statuses for all current breakpoints.

The step command [5tepJ is a command that executes one step at the address pointed to by the current program counter and then stops.

The status command "5tatusj" is a command that displays the current simulator operating environment, etc. For example, it refers to the debugger status table DST and displays the simulator execution mode, MPU type, MPU operating clock, target program name, external event file name, current Displays the program counter value, trace mode setting status, etc.

The trace command ``tracej'' is a command for tracing the occurrence of internal or external events, displaying the contents on the display 5, and storing them in the trace file TF.

The write command rwritej is a command for setting a value in a specified memory or register.

Note that if control C is activated while the above rrunJ command is being executed, the target program being executed will stop and wait for the command. Note that control C means pressing the "C" key while pressing the control key on the keyboard 4.

The basic flow of debugging individual software using the MPU simulator of this embodiment is to set input data and set a breakpoint at the exit of the program unit to be debugged before executing the program. After setting, execute the program unit from the beginning. Then, when the program stops at a breakpoint, the output data is referenced and checked to see if it matches the data expected in advance. If there is a discrepancy, use debugger commands to find where the bug is.

A command line input from the keyboard 4 is analyzed by the user interface [IIF] and converted into a format that can be understood by the debugger DBG.

The user's input is the exit command, i.e. rquitJ
If so, the operation of the MPU simulator is ended (step 107). In addition, "If the command is other than quitJ and is not an MPU instruction execution command, for example, rwriteJ, rρrint
J.

rbreakj, etc., the respective commands are executed (steps 108 and 117). Then, the execution result is notified to the user interface old F (stenoa '118), and the user interface UIF
The execution result is displayed on the display 5 (step 119).

Also, if the user's input is an MPU instruction execution command, ``run J, r 5tep J
If it is a command (step 108), it is determined by referring to the debugger status table DST whether it is in the simulation mode or not (step 109). If it is in the simulation mode, the external event file E is
Set external input data from PF (step 110
). Next, the MPU module: a! , MP by 1
After simulating the execution of the U instruction (step 111), internal functions of the MPU such as timer and timer/event counter processing are executed (step 112), and furthermore, the instruction execution results are notified to the debugger DBG, etc. will be held (Stella 7'113)
. Note that when not in simulation mode, that is, when in program mode, only the execution of the target program is performed and no external input data is required.
Setting external input data (step 110) is skipped. Note that steps 111, 112, and 113 are
It is executed not by the debugger DBG but by the MPU module MM.

The instruction execution result is further notified to the user interface UIF (step 114), and the user interface UIF displays the execution result on the display 5 shown in FIG. 4 (step 115).

For example, if a breakpoint is set at address a090, when a program is executed in the address space that includes address a090, execution of the target program will stop midway, and rbreak at breakl(a090) J
This message is displayed. This display means that execution of the target program has stopped at address 8090, which is the address of the first breakpoint. In this state, use the rprintj command to display the contents of registers and memory and check whether they match the expected values.

If they match, input rrun a090J as a command to restart execution of the target program from this breakpoint and execute the program to the next breakpoint.

Perform this simulation for each breakpoint.

If the contents of the output register or memory do not match the expected values, use the rtracej command to display the changes in the registers and memory up to the breakpoint for each MPU instruction to find the location of the bug. In this trace mode, the debugger DBG's trace mode table T! JT is referenced, internal tracing, external tracing, or both tracing is performed depending on the specified trace mode, and the trace results are displayed on the display 5 and stored in the trace file TF. Note that in the case of internal tracing, registers, memory, and internal functions caused by MPU execution are traced. In addition, in the case of external tracing, external input imported from the external event file EPF and MP
Trace port output, serial output, etc. from U.

Once a bug is discovered, the target program is fixed at the object level. For example, [asmj
The command changes the memory contents at the corresponding address using assembler mnemonics.

In addition, for this debugging work, "breakJ.

In addition to the rprint and rasmJ commands, the various debugger commands described above are used.

Debugging work is performed by repeating the above-mentioned work.

If execution of the target program over multiple steps is instructed, step 116 is executed until execution of all specified instructions is completed.
Then, the process returns to step 109. When execution of all instructions is completed, the process returns to waiting for input of a debugger command (steps 116 and 105).

As mentioned above, in the simulator of this embodiment, when executing the simulation, the target program TP is loaded into the memory table MRYT by the loader LDR, and the data in the configuration file CF and external event file EPF are loaded. Based on MPU module ゛11! , l simulate the MPU operation. That is, the target program TP is executed according to the test data based on the set hardware environment. The simulation results are then displayed on the display 5 (see FIG. 4).

The user checks the results of this simulation and
If a problem occurs, analyze the cause using debugger commands. If a bug is found as a result of trouble analysis, the target program is modified using debugger commands.

By repeating the above operations while changing various conditions, for example, test data, debugging is completed and a bug-free object program is obtained.

At this time, the part of the information specific to MPU, that is,
The parts related to the register structure, terminal structure, instruction system, etc. are independent modules, that is, the register information table RIT, the terminal function table TPT, and the MPU module MM. These tables and modules may be switched depending on the situation.

〔Effect of the invention〕

As described above, according to the present invention, when developing software for a device using an MPU, data on the hardware environment and external events are created in a file, and a simulation is performed based on the data in this file. Therefore, it is possible to debug the software alone without using an actual device, and debugging efficiency can be improved. At this time, an MPU module is provided independently, and this MPU module is provided with processing specific to the MPU. Therefore, even if the type of MPU is changed, there is no need to change the debugger body, user interface, etc., and this can be handled by simply switching the MPU module. As a result, each MP
There is no need to prepare independent simulators for each U, and software development costs can be reduced.

[Brief explanation of the drawing]

Fig. 1 is a principle diagram for explaining the MPU simulator of the present invention, Fig. 2 is a block diagram showing the hierarchical relationship between the MPU simulator and the copying machine simulator as a whole, and Fig. 3 is a diagram of the MPU simulator of the present invention.
Explanatory diagram showing the software structure of the U simulator, Part 4
The figure is a block diagram showing the hardware configuration of the MPU simulator, Figure 5 is an explanatory diagram showing the relationship between each subsystem, files, and tables that make up the MPU simulator, and Figure 6 is an explanatory diagram showing the configuration of the configuration table. , FIG. 7 is an explanatory diagram showing the structure of the external event table, FIG. 8 is an explanatory diagram showing the structure of the register information table,
Figure 9 is an explanatory diagram showing the configuration of the terminal function table;
The figure is a schematic block diagram showing an example of the structure of the MPU to be simulated, FIG. 11 is an explanatory diagram showing the configuration of the command table, FIG. 12 is an explanatory diagram showing the configuration of the MPU execution status table, and FIG. 13 is an explanatory diagram showing the configuration of the MPU execution status table. An explanatory diagram showing the structure of the debug status table, FIG. 14 is an explanatory diagram showing the structure of the breakpoint table, FIG. 15 is an explanatory diagram showing the structure of the trace mode table, and FIG. 16 is an explanatory diagram showing the structure of the register table. , FIG. 17 is an explanatory diagram showing the configuration of the terminal table, FIG. 18 is an explanatory diagram showing the configuration of the MPU status table, FIG. 19 is an explanatory diagram showing the configuration of the pace clock table, and FIG. 20 is an explanatory diagram showing the configuration of the MPU status table. FIG. 21 is an explanatory diagram showing the configuration of the timer table, FIG. 21 is an explanatory diagram showing the configuration of the command analysis table, FIG. 22 is an explanatory diagram showing the composition of the command classification table, and FIG. 23 is an explanatory diagram showing the configuration of the command set table. 24 is an explanatory diagram showing the relationship between command-related tables, and FIG. 25 is an explanatory diagram showing the relationship between command-related tables.
FIG. 26 is a flowchart showing an example of the flow of function processing in the U module. FIG. 26 is a flowchart for explaining the flow of simulation operation in the MPU simulator of this embodiment. Also, Figure 27 shows the MPU
FIG. 28 is a process chart showing the general procedure for developing equipment controlled by an MPU. CF: Configuration file DOG: Devasoga EPF: External event file! JM: MPU module! , 1RYT: Memory table TP: Target program 111F: User interface Patent applicant Fuji Xerox Co., Ltd. Agent
Masu Kobori (2 people) Figure 1 TP IF Figure 2 CG EPDG MS Figure 3 Figure 4 Figure 6 Figure 7 Figure 11 Figure 12 Figure 8 Figure 9 Figure 14 Figure 16 Figure 17 Figure 18 Figure 21
Figure 22 Figure 23 Figure 19 Figure 20 1 Bell 1 Definition: Total number of executed clocks/1 clock count Number of i interrupt clocks, 1Lλh ') O-/') tl Kasumi 1if
”) Include BW Fig. 24 User input Fig. 25 Fig. 26

Claims (1)

[Claims] 1. Read the hardware configuration information of the MPU to be simulated and various timing signals supplied to the terminals of the MPU as file data, and read the data of the target program to be debugged; An MPU simulation method, characterized in that the execution of a target program is simulated according to an instruction execution structure specific to an MPU to be simulated using data of the MPU. 2. The M according to claim 1, wherein the hardware configuration information is stored in a configuration information file, and the various timing signals are stored in an external event file.
PU simulation method. 3. The MPU simulation method according to claim 1, wherein the target program is loaded into a memory table prior to simulation. 4. An MPU module for simulating execution of the target program is provided for each type of MPU, and a user interface is provided for inputting commands to the MPU module and displaying output from the MPU module. The MPU simulation method according to claim 1. 5. A debugger is provided that instructs the MPU module to change or display the contents of a memory table loaded with the target program, execute or stop the target program, etc., based on commands input through the user interface. Claim 4 characterized in that
The MPU simulation method described. 6. A configuration information file that stores hardware configuration information of the MPU to be simulated, and the MPU
an external event file that stores data of various timing signals supplied to the terminals of the terminal, a user interface that processes input commands from the terminal or information displayed on the terminal, and a A debugger that instructs to change or display the contents of a memory table into which the target program is loaded, execute or stop the target program, and use data from the configuration information file and external event file based on instructions from the debugger. An MPU simulator comprising: an MPU module that simulates execution of a target program according to a structure specific to an MPU to be simulated. 7. The MPU simulator according to claim 6, wherein a plurality of said MPU modules are provided corresponding to types of MPU.