JP2000242528A - Device for monitoring cpu runaway - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a runaway monitoring device for a CPU capable of minimizing the influence due to ROM damages and continuing the program processing at an undamaged part. SOLUTION: A computer system consists of a means 31 storing a module to be printed to a ROM, a means 32 calculating the check sum of the module, a means 33 storing the check sum of the module, a means 34 comparing the calculated check sum with a stored check sum, a means 37 storing the default output value of each module and a means 38 outputting the default value without executing the module when the compared results of the check sums do not coincide. That is, when program runaway due to ROM damages takes place, a monitoring IC inputs a reset signal to a CPU, only a module in a damaged area is stopped by performing processing just after the CPU is restarted, and a program can be restarted by using the default output value of the module.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to runaway processing of a program used in a computer system.

[0002]

2. Description of the Related Art As a conventional real-time system,
There was a structure as shown in FIG. In the figure, 1 is CP
U, 2 are PRUN signal output terminals of CPU1 and 3 is CPU
1 is a reset signal input terminal, 4 is a monitoring IC, 5 is a monitoring I
A PRUN signal input terminal C4 and a reset signal output terminal 6 of the monitoring IC 4 are provided.

In this conventional technique, a PR1 signal output program executed by a CPU 1 at a constant cycle makes a PR
The UN signal is inverted and output at a constant frequency.
A reset signal is output when the period of the PRUN signal is different from a predetermined value. In other words, when the program runs away, PRU
The N signal output program is not executed at the correct cycle, and the monitoring IC 4 resets the CPU 1.

[0004]

However, in such a conventional method, it is not possible to determine in which part of the program the runaway occurred, so that the cause of the runaway cannot be eliminated, and the CPU is reset and restarted from the initial state. Even if it starts, there is a problem that it runs away again. For example, if the ROM of the one-chip microcomputer fails and the execution instruction of the program cannot be read correctly, the microcomputer may be reset and restarted from the initial state, or it may run away.

The present invention has been made in view of such a conventional problem, and it is determined which module of a program caused a runaway, and the module is not executed at the time of restarting after resetting without executing the module. The purpose of this is to minimize the effect of module stoppage by outputting the default output value of.

[0006]

SUMMARY OF THE INVENTION In order to solve the above-mentioned problems, a runaway monitoring apparatus for a CPU according to the present invention comprises means for storing a module to be burned into a ROM and calculating a checksum of the module in a computer system. Means for storing a checksum of the module; means for comparing the calculated checksum with the stored checksum; means for storing a default output value for each module; Means for outputting a default value without executing the module when the comparison results do not match.

[0007]

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram showing an embodiment of a CPU runaway monitoring apparatus according to the present invention; FIG. 1 is a diagram showing a memory map of a ROM of an embodiment of a CPU runaway monitoring device according to the present invention, and FIG. 2 is a diagram showing a module table of an embodiment of a CPU runaway monitoring device according to the present invention. FIG.

First, the configuration will be described. In FIG. 1, 1
0 is a ROM, 11 is an area for storing each module in the ROM, 12 is an area for storing a checksum value for each module in the ROM, and 13 is an area for storing a default output value of each module in the ROM. is there.

In FIG. 2, reference numeral 20 denotes a module table, 21 denotes a flag for identifying whether a module can be executed in the module table, 22 denotes a head address of the module in the module table, and 23 denotes a variable output from the module in the module table. Address.

Next, the operation of the present embodiment will be described with reference to FIGS. FIG. 3 is a configuration diagram of the present embodiment. In the figure, 31 (== 11) is an area for storing each module, 32 is means for calculating a checksum of the module, 33 (== 12) is an area for storing a checksum value for each module, and 34 is Means for comparing the value calculated by the checksum calculation means 32 with the checksum value in the checksum value storage area 33; 36 (== 20) a module table; and 35 when the comparison result of the checksum comparison means 34 is different. Is the flag 21 of the module table 36
Means that module execution is prohibited. If the comparison results match, the module 21 sets the flag 21 of the module table 36 to "permit module execution." 37 (== 13) is an area for storing a default output value of each module. And 38 are means for executing the module when the flag 21 of the module table 36 is "executable", and for copying the default value of the default output value storage area 37 to the output variable when the flag 21 is "executable".

FIG. 4 is a flowchart of the embodiment. In the event of a ROM failure, the program runs away, and a reset signal is input from the monitoring IC 4 of FIG. C
The PU 1 performs a process according to the flowchart of FIG. 4 immediately after the reset, for example. The processing of steps S101 to S105 is repeated for module i.

In step S101, the checksum of the module storage area 11 is calculated and assigned to a variable x. In step S102, the checksum value 12 previously burned into the ROM is substituted for the variable y. In step S103, the x and the y are compared. If they match, the flag 21 of the module table 20 is set to "OK" in step S104. If they do not match, the flag 21 of the module table 20 is set in step S105. Set to “No”.

FIG. 5 shows a module 38 for executing a module.
It is a flowchart of (refer FIG. 3). For each module i in the module table 20, step S201
To S203 are repeated.

In step S201, the flag 21 of the module table 20 is checked. Flag i is "OK"
In step S202, the module i registered at the head address 22 of the module is executed in step S202.
If the flag i is "No", the default output value 13 of the module i is copied to the output variable 23 of the module i in step S203. The CPU starts each module by repeating this every fixed period or every time an interrupt occurs.

[0015]

As described in detail above, according to the present invention, in the case of program runaway due to ROM destruction,
When a reset signal is input to the CPU by the monitoring IC,
By performing the processing of this configuration immediately after the restart of the PU, only the module in the destroyed area can be stopped, and the program can be restarted using the default output value of the module. As a result, the effect of minimizing the influence of the ROM destruction and continuing the program processing of the part not destructed can be obtained.

[Brief description of the drawings]

FIG. 1 is a diagram showing a memory map of a ROM of an embodiment of a CPU runaway monitoring device according to the present invention.

FIG. 2 is a diagram illustrating a module table of an embodiment of a CPU runaway monitoring device according to the present invention.

FIG. 3 is a configuration diagram of an embodiment corresponding to the claims of the present invention.

FIG. 4 is a flowchart of one embodiment of a CPU runaway monitoring device according to the present invention.

FIG. 5 is a flowchart of a module execution unit of the embodiment of the CPU runaway monitoring device according to the present invention;

FIG. 6 is a configuration diagram of a conventional system.

[Explanation of symbols]

 Reference Signs List 10 ROM 11 Module storage area 12 Checksum value storage area of module area 13 Default output value storage area of module 20 Module table 21 Flag 22 Head address of module 23 Address of output variable 31 Module storage area 32 Checksum calculating means 33 Checksum Value storage area 34 Checksum comparison means 35 Module execution means 36 Module table 37 Default output value storage area 38 Means for copying default values to output variables

Claims (1)

[Claims] 1. A computer system, comprising: means for storing a module to be burned into a ROM; means for calculating a checksum of the module; means for storing a checksum of the module; Means for comparing the checksum with the stored checksum, means for storing a default output value for each module, and means for outputting a default value without executing the module when the comparison result of the checksums does not match. A runaway monitoring device for a CPU, comprising: