JP2978841B2 - Emulation method for in-circuit emulator - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an emulation method in an in-circuit emulator used for developing a user program incorporated in a microprocessor, and more particularly to emulation of an in-circuit emulator such as operation of a microprocessor having a flash memory, an E2PROM, and the like. The present invention relates to an emulation method for an operation that cannot be directly emulated by a CPU.

[0002]

2. Description of the Related Art In developing a user program mounted on a microprocessor shipped as a device used for a specific purpose, it is generally difficult to operate a CPU of the microprocessor and check its functions. An emulation CPU corresponding to the microprocessor CPU, a control CPU for controlling the emulation, a required memory, and various firmware for the emulation are prepared.
Is emulated, and the function of the user program is verified.

In this case, for example, a microprocessor C
When the PU is in the standby state or when the flash memory incorporated in the microprocessor is to be subjected to self-writing in which the CPU itself of the microprocessor rewrites, the former requires the emulation CPU itself to be in the standby state. No emulation data is obtained, and in the latter case, the operation cannot be directly emulated by hardware because the in-circuit emulator does not have a flash memory or hardware for performing write processing. Therefore, emulation by software is performed. Hereinafter, emulation by this software will be described by taking an example of an emulation function of a self-writing operation of a flash memory provided in a conventional in-circuit emulator.

In a self-writing operation of a flash memory in a microprocessor, a user who develops a program usually prepares a self-writing subprogram (hereinafter referred to as a boot program) that can be freely called in a user program. Then, the called boot program calls the firmware for rewriting the flash memory (hereinafter referred to as a flash firmware) in accordance with the designated entry address.

In the called flash firmware, a specific special function register (hereinafter, a special function register is referred to as an SFR and a specific special function register is referred to as a specific SFR) is specified according to a write address and write data specified by a boot program. In response, a flash memory rewrite request is issued. Thus, writing of data to the write address is started.

However, a microprocessor can perform a process of writing data to a write address by itself, but the hardware of an in-circuit emulator has a function of processing data to be written to a flash memory. No specific SF
Even if a flash memory rewrite request is issued to R, data cannot be written to the write address. So in the in-circuit emulator,
When a flash memory rewrite instruction is issued to a specific SFR in the flash firmware, a control program (hereinafter, referred to as an ALT program) operating on an emulation CPU of an in-circuit emulator moves to a write address. The emulation of the flash memory by self-writing software is realized by writing the data.

For this reason, the specific S
When a flash memory rewrite instruction is issued to the FR, it is necessary to break the flash firmware operating in the user program and shift the control of the emulation CPU from the user program to the ALT program. To perform this control transition,
In the prior art, the following processing was performed.

The flash firmware performs a write operation on a specific SFR as a flash memory rewrite request. Since the specific SFR is an SFR that is not disclosed to the user, the write operation is performed on the specific SFR. This is limited to flash memory rewrite requests. On the other hand, the in-circuit emulator is provided with an event detector for monitoring the address bus and the data bus of the emulation CPU. For example, a specific bus cycle condition set by the user as an event for emulation break is set in the user program. Emulation CPU when it appears during execution of
A bus detection function is provided for interrupting the execution process and performing control transfer to the control CPU. Therefore, by setting the data write operation to this specific SFR as an event detected by the bus detection function, and by detecting this,
A trigger to start the self-write emulation process in the ALT program (hereinafter referred to as a trigger) is generated, whereby the ALT program writes data to a write address, and then returns control to the flash firmware. Emulation of self-writing of flash memory was realized.

FIG. 8 and FIG. 9 respectively show the emulation of self-writing of the flash memory.
FIG. 9 is a transition diagram and a flowchart showing a control transfer process according to the related art. Referring to FIGS. 8 and 9, in emulation of self-writing of the flash memory, first, a control program (hereinafter, referred to as an executor) 805 operating on the control CPU 802 preliminarily sets a flash to be used as a trigger. Farm 807
After setting the data write operation of the specific SFR therein as the event detection condition (steps 808 and 901), the execution of the user program is started (steps 809 and 90).
2), Executor command processing (step 81)
0), the program control returns to the user program 803 via the ALT program (step 811),
The execution of the boot program 806 for self-writing in the flash memory is started (steps 812 and 9).
02).

The boot program 806 sets an address to be rewritten and rewrite data in an area in the same memory space in advance as preprocessing for self-writing in the flash memory (steps 813 and 90).
3).

Thereafter, the boot program 806 calls the flash firmware 807 which is a module of the user program 803 (steps 814 and 904), and shifts the processing (step 905). The flash firmware 807 to which the processing has been shifted writes a command number corresponding to 1-byte write, block erase, or the like to a specific SFR in order to perform self-writing of the flash memory based on the setting data prepared in advance by the boot program 806 ( Step 906). By this writing, an event break previously set in step 808 occurs (step 907), and the flash firmware 807 breaks (steps 815 and 907). This allows
Emulation by the user program 803 is interrupted (step 908), and the processing is terminated by the ALT program 80.
4 and move to Executor 805 (Step 9)
09).

The executor 805 determines whether the detected event break cause is a trigger set for self-writing emulation of the flash memory (steps 816 and 910).
If the cause of the event break is a trigger set for self-writing emulation of the flash memory, the executor 805
4 is requested to start self-writing emulation of the flash memory (steps 817 and 91).
1). If the break factor is not a trigger set for self-writing emulation of the flash memory, the executor 805 determines that the detected event is an event set by the user, and ends all emulation processing ( Step 91
2).

When the ALT program 804 receives a request to start self-writing emulation of the flash memory from the executor 805, the ALT program 804 starts emulation of the processing (steps 818 and 913) and transfers data to a preset address to be rewritten. Writing is performed (step 914). ALT program 8
When the self-write emulation process in step 04 ends (step 915), the ALT program 80
4 executes an interrupt return instruction (step 819), returns the process to the flash firmware 807 of the user program 803 (step 916), and resumes emulation in the flash firmware interrupted by the trigger.
The self-writing emulation of the flash memory ends, and the process returns to the boot program 806 (step 820). The self-writing to the flash memory has been described above as an example. However, in the conventional technique, software emulation using an ALT program for an operation that cannot be directly emulated by the emulation CPU has been realized in this way.

[0014]

However, in such software emulation using the conventional ALT program, an event break originally provided as a resource for a user is used as a judgment of a trigger for shifting control to the ALT program. Because
There was a problem that the use of the event of the user had to be restricted correspondingly. That is, although the event can be used to trigger the transition of control to the ALT program because the comparison conditions such as the address and data can be set in detail as described above, the event is originally used for setting the break timing for emulation. This function is open as a resource for the user so that the user can freely set the comparison condition. If this function is reserved for a flash firmware, for example, the event types that can be set by the user will be reduced accordingly.

Further, there is a problem that a difference in processing speed between the emulation CPU and the control CPU may be a bottleneck in the speed of emulation. That is, since the occurrence of such an event is detected by the bus detection function described above, the control is performed by the CPU for the emulator.
Is transferred to the control CPU, and the executor operated by the control CPU determines the cause of the event occurrence, confirms that the event is not a user-set event, and transfers control to the ALT program again. .
However, in general, in an in-circuit emulator, a CPU having a performance corresponding to a CPU of a microprocessor on which a development program operates is used as an emulation CPU.
U is prepared, but the processing speed of the control CPU is, for example, about 0.6 times that of the emulation CPU, and this difference in speed can be a bottleneck in the speed of the self-write emulation of the flash memory, for example. is there.

The present invention has been made in order to solve such a problem. Control is performed by using a fail-safe break function provided in an in-circuit emulator as a trigger instead of an event which is a user resource. To provide an emulation method that can start emulation processing by an ALT program without transferring control to a CPU for use, has no speed bottleneck, and does not restrict the use of an event that is a user resource. And

[0017]

[Means for Solving the Problems] Emulation CP
Breaks that can be determined by the ALT program executed in U are triggered by an event, and
(Hereinafter, referred to as a snap) for reading the contents of the program, a break (hereinafter, referred to as a stub) for jumping to a user-specified subroutine using an event as a trigger, and other breaks. However, the two breaks, snap and stub, do not correspond to the judgment of the emulation CPU alone because both events must use events. Other breaks include a forced break and a fail-safe break. The forced break is a break generated at the request of the user and cannot be a trigger of emulation.

On the other hand, the fail-safe break monitors illegal access of a user program, in particular, access to resources that cannot be used by the CPU of the microprocessor to be emulated, and stops the program. It can be generated depending on the execution state. Further, the fail-safe break has a function called an SFR illegal access break, and it is possible to limit the use of the break by accessing an SFR that is not possessed as a resource of the CPU. Therefore, in the present invention, the fail-safe break is used as a trigger for software emulation by the ALT program.

In order to realize such an emulation method, the emulation method in the in-circuit emulator according to the present invention uses the C
In an in-circuit emulator including an emulation CPU for emulating the operation of a PU and a control CPU for controlling the execution of the emulation, a value is stored in a specific special function register (SFR) of the CPU of the microprocessor. In the method of emulating the operation of the CPU of the microprocessor activated by writing the program by an ALT program which is a control program operated by the emulation CPU, an executor which is a control program operated by the control CPU However, when executing a command to start execution of a user program operating on the emulation CPU, the fail-safe break condition is changed and access to the specific SFR is changed to S.
In the step of changing the fail-safe break condition set for the FR illegal access, and when the user program breaks and the control shifts to the ALT program, the ALT program checks the break factor and determines whether the break factor is the specific SFR. Emulation processing step in which the ALT program executes the operation of the CPU of the microprocessor corresponding to the access to the specific SFR without returning control to the executor when the access is to the executor. And

In the step of changing the fail-safe break condition, the command is a command for instructing the start of emulation, and the CPU of the microprocessor to be emulated has
CP that requires emulation by T program
It is characterized in that it is executed only when it is U.

Further, the emulation processing step includes:
The ALT program determines that the cause of the break is SFR
A break factor confirming step for confirming that the access is illegal; an instruction code analyzing process for analyzing an instruction code of the user program corresponding to a case where the break factor is an SFR illegal access; and an instruction code analyzing process. An emulation execution step of emulating the operation of the CPU of the microprocessor corresponding to the instruction code, when it is confirmed that the instruction code is an access to the specific SFR. I do.

Further, prior to the instruction code analysis processing step, referring to a value of a program counter of the emulation CPU, the break is executed immediately after an instruction located at a specific address of firmware executed by the user program. Further comprising a step of confirming that the break has occurred in the instruction code analyzing step only when the break has occurred immediately after the instruction located at the specific address. I do.

The instruction code analyzing means traces back the value of the program counter, restores an instruction code having a length corresponding to a write instruction to the specific SFR, and the restored instruction code matches a specific pattern. It is characterized in that whether or not it is analyzed.

Further, the operation of the microprocessor CPU started by writing a value to a specific SFR of the microprocessor CPU is a self-write operation to a flash memory provided in the microprocessor. I do.

Further, the microprocessor C
The operation of the CPU of the microprocessor started by writing a value to the specific SFR of the PU is an operation of transitioning the operation state of the CPU of the microprocessor to a standby mode.

[0026]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram showing the configuration of the in-circuit emulator. The in-circuit emulator includes an emulation CPU 101 and a control CPU 105. The emulation CPU 101 is provided for the emulation memory 102 and the ALT memory 103.
Access via the address bus 111 for emulation and the data bus 112 for emulation CPU. Access is made to the memory selected by the emulation CPU control signal 109, and the user program 115 or the ALT program 116 can be executed.

The control CPU 105 is connected to a control CPU address bus 113 for the system memory 106.
And access via the control CPU data bus 114. The access is made to the system memory 106 selected by the control CPU control signal 110, and can be executed by executing a program developed in the system memory, for example, the executor 117. Further, the in-circuit emulator is provided with a fail-safe detection memory 107 that can be accessed by the control CPU 105. In the present invention, a fail-safe break is generated in the fail-safe detection memory in advance for use in triggering emulation. Make settings to make

The fail-safe detection memory 107 includes:
An interface with the emulation CPU address bus 111 is provided, and the emulation CPU
By monitoring the execution state of the program in 101 and comparing the access address with the setting data, an access to an illegal address area, for example, an SFR that does not exist in the CPU of the microprocessor to be emulated can be detected. It has become.

FIG. 2 is a transition diagram showing the transition processing of the control according to the present embodiment. Here, similar to the prior art shown in FIG.
Microprocessor CP with flash memory
The transition of the control shift is shown by taking as an example the case where the self-writing of the U flash memory is emulated by the in-circuit emulator. One of the user programs 115 executed by the emulation CPU 101
The boot program 206 as one module is a program executed for rewriting the flash memory. To execute this program, the control CPU 10
It is necessary that the executor 117 which is the control program executed in step 5 starts the execution of the user program (step 208), and the ALT program 116 is called by the command processing (step 209).
The executor 117 starts processing.

Subsequently, the executed boot program 20
Reference numeral 6 denotes a module prepared for flash memory rewriting in which an address to be rewritten and rewriting data are set in an area in the same memory space in advance as a preprocessing for rewriting the flash memory (step 212). A certain flash firmware 207 is called (step 213), and the process is shifted. The flash firmware 207 to which the processing has been shifted writes a command number corresponding to 1-byte write, block erase, or the like to the specific SFR in order to rewrite the flash memory based on the setting data prepared in advance. By this writing, a fail-safe break occurs, and the flash firmware 207 breaks (step 214). Thereby, the processing shifts to the ALT program 116.

The ALT program 116 starts emulation processing (step 215), performs instruction code analysis processing or the like to check the cause of the break, performs emulation of self-write processing according to the command number, and after that, executes ALT. The program 116 returns to the flash firmware 207 of the user program 203 by executing the interrupt return instruction (step 216). This completes the writing to the flash memory (step 217).

The outline of the transition of the control according to the present embodiment has been described above by taking the self-writing process to the flash memory as an example. The difference from the prior art in FIG. 8 is that the executor 805 in the prior art in FIG. Although the setting of the trigger for the event detector (step 808) was performed prior to the start of the execution of the user program (step 809), in the present embodiment, instead of this, step 2 is performed.
09, the condition is set in the fail-safe detection memory 107 during the command processing, and in the prior art, control is transferred to the executor 805 by the break (step 815) of the flash firmware 807, and the executor 805 The trigger determination process (step 816) is performed. However, in the present embodiment, the ALT program 116 performs an instruction code analysis process or the like to check the cause of the break at the start of the emulation process (step 215). is there.

Hereinafter, this point will be described in detail. First, the operating environment of the executor will be described with reference to FIG. To perform emulation by the in-circuit emulator, the user starts a debugger, which is an application for using the in-circuit emulator (step 301). The debugger introduces an executor 117 which is one of the product configurations (step 30).
2). The introduction is performed by downloading to the system memory 106 of the in-circuit emulator, and the execution of the executor 117 is started (step 30).
3), control processing of the in-circuit emulator is performed.

The executor 117 first performs initialization processing for controlling the in-circuit emulator, initialization of the in-circuit emulator hardware (step 304), introduction of the ALT program 116 (step 305), and initialization of the emulation CPU 101. It is executed in four steps of setting (step 306) and setting information of the emulation target CPU (step 307). Here, the ALT program 116 is introduced by downloading to the ALT memory 103 of the in-circuit emulator. In the information setting of the CPU to be emulated (step 307), detailed information on the CPU of the microprocessor to be emulated is replaced with individual information of various CPUs that can be emulated by the in-circuit emulator, called device files. For example, it is read from a file stored for each operating environment such as the presence or absence of a self-writing function of the flash memory, and stored in the system memory 106 together with the name of the emulation target CPU identified for each operating environment.

After setting the operating environment of the emulation in this way, the executor 117 proceeds to the step for processing the command from the debugger. In this step, a break check (step 30)
8) The three processes of checking the change in the operating state of the in-circuit emulator (step 309) and notifying the status (step 310) are performed. These three steps are processing for transmitting a message to the debugger when the operation state of the in-circuit emulator changes between emulation and break. Thereafter, it is checked whether a command transmitted from the debugger has been received (step 311).
After processing the received command (step 312), and if no command is received, the process directly returns to step 308 to monitor the next break. If the command transmitted from the debugger is an EXIT command (step 313), the executor 117 ends the execution (step 314). In this way, the steps for processing the command each time a break occurs (steps 308 to 31)
By repeating 2), the executor 117 performs command processing from the debugger. The memory 107 for fail-safe detection performed in step 209 of FIG.
Is set in the command processing of step 312 in FIG.

FIG. 4 is a flow chart for explaining the details of the command processing performed in step 312 of FIG. The command process (step 209) described in the control transition diagram of FIG. 2 is a pre-process for generating an emulation trigger, and this process will be described in detail with reference to FIG.

First, command processing is started (step 401), and the command number is checked (step 4).
02). Here, it is checked whether or not the command indicated by the command number is a RUN command for instructing the start of emulation (step 403).
And an emulation target CPU previously set in step 307 to determine whether or not the operating environment requires software emulation by the ALT program 116.
A check is made with reference to the information (step 404). If the command is a RUN command and the emulation target CP
If U is a CPU that requires software emulation by the ALT program 116, the fail-safe break that triggers the emulation is changed (step 405).

The change here is to make a setting to generate a fail-safe break for access to a specific SFR. Since this specific SFR is an SFR inherent to the CPU to be emulated, Is set so as not to generate a fail-safe break, but in the present embodiment, by setting this as an SFR that cannot be accessed by the CPU to be emulated, and detecting the SFR illegal access break by the access, the ALT program 11
6 is used as an emulation trigger.

Next, the executor 117 calls a function corresponding to the command (step 406). If the result of the comparison performed in the above-described flow (steps 403 and 404) does not correspond, the executor 117 changes the fail-safe break (step 406). The processing shifts to the function called without performing step 405). When the processing returns from the called function, the command processing ends (step 407).

Next, the self-writing emulation processing of the flash memory by the ALT program 116 described in the processing transition diagram of FIG. 2 (step 21)
5) will be described. FIG.
5 is a flowchart showing details of an emulation process in FIG. When the flash firmware writes a value to the specific SFR in step 214, an SFR illegal access is detected, a fail-safe break occurs, control is transferred to the ALT program, and emulation processing in the ALT program is started (step 50).
1) First, a break factor check is performed (steps 502 and 503). If the break factor checked here is a break due to snap or stub, control is returned to the executor 117 to perform snap and stub processing (step 504) and return to the user program by an interrupt return (step 504). 511). If it is a normal break other than snap and stub, investigate the cause of the break in more detail.

First, the program counter is read (step 505), and the value of the program counter is checked.
It is checked whether the address at which the break occurred is immediately after the instruction located at a specific address of the flash firmware 207.

CPU to be emulated
In the actual operation of the flash firmware 207, when the flash firmware 207 performs self-writing, a specific SFR called a flash mode control register (hereinafter referred to as FLMC) is used.
By writing a value to the flash memory, the flash memory is to be rewritten. Fail-safe break detection is not enough to detect the fail-safe break.
It cannot be determined whether a break has occurred due to writing to C or a break has occurred due to improper access to other resources.

Therefore, in the present embodiment, the write instruction to the FLCM is fixedly arranged at a fixed specific address in the flash firmware 207. Since the flash firmware 207 is configured in this manner, if the address at which the break occurs indicates immediately after the instruction located at a specific address of the flash firmware 207, the SFR generated by writing to the FLCM causes the break.
It can be specified that the access is illegal.

As described above, the break factor is FLCM
(Step 506)
In this case, an instruction code analysis process is performed next to confirm whether the instruction is a true write instruction to the FLCM (step 507).

FIG. 6 is a flowchart for explaining the instruction code analysis processing in step 507 of FIG. Referring to FIG. 6, first, instruction code analysis of a write instruction to the SFR is started from a state immediately after a fail-safe break (step 601). The program counter is decremented (step 602), the memory at the address indicated by the program counter is read (step 603), and the contents are written in the instruction code data table (step 60).
4). This is repeated for the number of instruction code bytes of the write instruction to the SFR (step 605). As a result, instruction code data is created, and this is compared with the instruction code pattern data (step 606). As the instruction code pattern data, an instruction code of a write instruction to FLMC, which is an SFR, is stored. The element of the instruction code is writing data from the register to the SFR,
Since the SFR is fixed to the FLMC, steps 602 to
If the instruction code written in the instruction code data table in 605 is a write instruction to the FLMC, it becomes a fixed code that does not include variable data. Therefore, if the compared results match, the matched data is returned (step 608), and if not, the unmatched data is returned and the instruction code analysis process ends (step 609).

Returning to FIG. 5, the ALT program 116
Based on the value returned from the instruction code analysis processing (step 507), the corresponding instruction is compared (step 50).
8). If the instruction matches, the command number to be emulated is checked (step 509), and 1-byte write (step 510A) and n-byte write (step 51) according to the command number.
0B), emulate command processing such as block erase (step 510C).

The ALT program 116 processes the command to be emulated in this manner. When the command processing is completed, the ALT program 116 executes an instruction for returning the user program by an interrupt return in order to return the processing to the flash firmware 207 (step 511), end the emulation.

In this embodiment, the ALT program 116 is triggered by the fail-safe break as described above.
The emulation by the ALT program 116 is started without causing a speed bottleneck by returning control to the control CPU 105 once and without using an event break which is a user resource.
Software emulation can be performed.

The embodiment of the present invention has been described above by taking self-writing to a flash memory as an example.
The application of the present invention is not limited to this embodiment,
The present invention can be similarly applied to emulation using an ALT program for other processing that cannot be directly emulated by the emulation CPU.

FIG. 7 is a flow chart for explaining the emulation processing of the ALT program 116 in step 215 of FIG. 2 when the processing for shifting the CPU of the microprocessor to the standby mode is performed.

At the start of emulation, the executor changes the fail-safe break in the same manner as in steps 401 to 405 in FIG. Set it. When the writing to the specific SFR is detected by the fail-safe detection memory 107, the control is shifted to the ALT program 116, and the emulation processing is started (step 701). Then, the break factor is checked (step 702, 703). If the break factor checked here is a break due to snap and stub, snap and stub processing is performed (step 704), and the program returns to the user program by an interrupt return (step 709). If it is a normal break other than snap and stub, investigate the cause of the break in more detail.

In this embodiment, when a normal break other than the snap and stub is performed, the instruction code is analyzed immediately (step 705). In the embodiment relating to the self-writing emulation of the flash memory shown in FIG. 5, it has been confirmed in steps 505 and 506 that the value of the program counter indicates immediately after the instruction located at a specific address. When the instruction becomes a special code and can be completely distinguished from the write instruction to the other SFRs as in the transition to the standby mode, even if the address of the instruction is not fixed, the standby mode Since it can be determined that the data is written to the specific SFR for the state transition to, the instruction code analysis processing (step 705) may be directly performed as in the present embodiment.

The instruction code analysis in step 705 is performed in accordance with steps 601 to 609 in FIG. 6 in the same manner as the instruction code analysis in step 505 in FIG. 5, and the instruction is a write instruction to the specific SFR of the state transition to the standby mode. A comparison is made (step 706). If the comparison results match, the data written to the specific SFR is checked (step 707), and the HALT in the standby mode (step 708A), the IDLE in the standby mode (step 708B), and the STOP in the standby mode (step 708A) are performed according to the contents. The emulation of any of the three states of step 708C) is performed. After the emulation processing by the ALT program is completed and the normal state is returned from the standby state, the process returns to the user program by an interrupt return (709), and the emulation is terminated.

[0054]

As described above, in the present invention, the SFR illegal access, which is one of the fail-safe breaks, is used instead of the event break as the trigger of the software emulation by the ALT program in the in-circuit emulator.

As a result, the trigger of emulation can be determined by the ALT program itself, and processing is performed only by the emulation CPU without returning program control to the control CPU whose operation clock is slower than that of the emulation CPU. For example, it is possible to emulate the self-writing process of the flash memory, which has a processing time of about 50 μs with an actual CPU, in almost the same processing time, and to perform the conventional event break. This has the effect of eliminating the problem of speed bottleneck when using as a trigger.

Further, it is not necessary to reserve an event, which is an emulation resource that can be used by the user, for a specific software emulation by the ALT program, so that the emulation can be performed more flexibly and flexibly for the user.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration of an in-circuit emulator.

FIG. 2 is a transition diagram showing a transition process of control according to the embodiment of the present invention.

FIG. 3 is a flowchart illustrating an operation environment of the executor 117 of FIG.

FIG. 4 is a flowchart illustrating details of a command process performed in step 312 of FIG. 3;

FIG. 5 is a flowchart showing details of an emulation process in step 215 of FIG. 2;

FIG. 6 is a flowchart illustrating instruction code analysis in step 507 of FIG. 5;

FIG. 7 is a flowchart illustrating emulation processing of an ALT program according to another embodiment of the present invention.

FIG. 8 is a transition diagram showing a transition process of control at the time of emulation of self-writing of a flash memory according to a conventional technique.

FIG. 9 is a flowchart showing a control flow when emulating self-writing of a flash memory according to a conventional technique.

[Explanation of symbols]

 101, 801 Emulation CPU 102 Emulation memory 103 ALT memory 104 2-port memory 105, 802 Control CPU 106 System memory 107 Fail-safe detection memory 108 Event detector 109 Emulation CPU control signal 110 Control CPU control signal 111 For emulation CPU address bus 112 Emulation CPU data bus 113 Control CPU address bus 114 Control CPU data bus 115 User program 116, 804 ALT program 117, 805 Executor 206, 806 Boot program 207, 807 Flash firmware

────────────────────────────────────────────────── ─── Continuation of the front page (56) References JP-A-9-128262 (JP, A) JP-A-6-214824 (JP, A) JP-A 8-153018 (JP, A) (58) Field (Int.Cl. ⁶ , DB name) G06F 11/22-11/34

Claims (7)

(57) [Claims] An in-circuit emulator comprising an emulation CPU for emulating the operation of a CPU of a microprocessor and a control CPU for controlling the execution of the emulation. Less than,
It is called SFR. A method of emulating the operation of the CPU of the microprocessor started by writing a value to the ALT program by an ALT program which is a control program operated by the emulation CPU, wherein the control program operated by the control CPU In executing the command to start the execution of the user program operating on the emulation CPU, the executor changes the fail-safe break condition and sets the access to the specific SFR to the SFR illegal access. A change step; and when the user program breaks and control is transferred to the ALT program, the ALT program confirms the cause of the break, and determines whether the break cause is an access to the specific SFR. In this case, the ALT program executes an emulation processing step of executing the operation of the CPU of the microprocessor corresponding to the access to the specific SFR without returning control to the executor. Emulation method in a circuit emulator. 2. The step of changing the fail-safe break condition, wherein the command is a command for instructing start of emulation, and the CPU of the microprocessor to be emulated needs emulation by the ALT program. 2. The emulation method in an in-circuit emulator according to claim 1, wherein the emulation method is executed only when the CPU performs the emulation. 3. The emulation processing step, wherein the ALT program determines that the break factor is SFR.
A break factor confirmation stage for confirming that the access is illegal, an instruction code analysis process for analyzing an instruction code of the user program corresponding to a case where the break factor is an SFR illegal access, and an instruction code analysis process. An emulation execution step of emulating the operation of the CPU of the microprocessor corresponding to the instruction code, when it is confirmed that the instruction code is an access to the specific SFR. An emulation method for the in-circuit emulator according to claim 1. Further, prior to the instruction code analyzing step, an instruction in which the break is located at a specific address of firmware executed by the user program is referred to by referring to a value of a program counter of the emulation CPU. And confirming that the break has occurred immediately after the instruction, and proceeding to the instruction code analysis processing step only when the break has occurred immediately after the instruction located at the specific address. The emulation method in the in-circuit emulator according to claim 3, wherein 5. The instruction code analysis means traces back the value of the program counter, restores an instruction code having a length corresponding to a write instruction to the specific SFR, and the restored instruction code matches a specific pattern. 4. The emulation method in an in-circuit emulator according to claim 3, wherein whether or not the emulation is performed is analyzed. 6. A method for specifying a CPU of the microprocessor.
2. The emulation in an in-circuit emulator according to claim 1, wherein the operation of the CPU of the microprocessor activated by writing a value to FR is a self-write operation to a flash memory provided in the microprocessor. Method. 7. A method for specifying a CPU of the microprocessor.
2. The in-circuit according to claim 1, wherein the operation of the CPU of the microprocessor started by writing a value to FR is an operation of transitioning an operation state of the CPU of the microprocessor to a standby mode. Emulation method in the emulator.