JPH04195437A - Program runaway monitoring device - Google Patents

Abstract

PURPOSE:To easily investigate the cause at the time of the occurrence of watchdog error due to misprogramming or the like by logging the state of a program just before detection of the watchdog error. CONSTITUTION:A processor 1 is inputted the time-out signal of a watchdog timer 3 to start the interrupt handling, and the state of program just before the interrupt handling is logged at the time of this interrupt handling. When the interrupt handling is terminated, a timer clear signal is outputted to a response waiting timer 4. This timer is inputted the time-out signal of the watchdog timer 3 and is started, and this timer 3 outputs a signal to reset the processor if the timer clear signal is not inputted within a set time. Thus, error processing is performed by software of the processor 1 even if watchdog error occurs, and the state of the program just before the interrupt handling is logged when the interrupt processing is completed within a prescribed time, thereby easily grasping the state of fault.

Description

DETAILED DESCRIPTION OF THE INVENTION [Object of the Invention] (Industrial Application Field) The present invention relates to a device for monitoring program runaway in a computer system.

(Prior Art) Watchdog timers have traditionally been widely used to monitor runaway computer systems.

This watchdog timer includes a timer that is reset by program processing, and if this timer is not reset by program processing within a certain set time, it is determined that the program has runaway. This allows the computer system to be forcibly stopped or the program to be restarted.

FIG. 4 is a block diagram of a conventional program runaway monitoring device.

The processing device 1 includes a watchdog timer clear terminal la and a reset terminal 1b. The program runaway monitoring unit 2 includes a watchdog timer 3 that operates at a fixed set time, and includes a clear terminal 3a and a timeout terminal 3b.

In the program runaway monitoring section 2, a watchdog timer clear signal S1 outputted from the watchdog timer clear terminal 1a by the program processing of the processing device 1 is inputted to the clear terminal 3a of the watchdog timer 3. This causes the watchdog timer 3 to be reset and restarted.

After that, the processing device 1 outputs the watchdog timer clear signal S.
Every time it outputs 1, the watchdog timer 3 repeats resetting and restarting.

With the above configuration, when the program of the processing device 1 is operating normally, the watchdog timer clear signal S1 is output at regular intervals, so the watchdog timer timeout signal S2 is never output. However, if the program does not operate normally for some reason, the watchdog timer clear signal Sl will no longer be output. As a result, the watchdog timer 3 times out after a certain period of time and outputs the watchdog timer timeout signal S2. This is called a watchdog error. This watchdog timer timeout signal S2 is input to the reset terminal 1b of the processing device 1.
will be initialized and restarted.

(Problem to be Solved by the Invention) However, the conventional program runaway monitoring device described above forcibly resets and restarts the computer system and does not leave an error log.
It was difficult to trace the cause of the watchdog error.

Here, the following are possible causes of the watchdog error: First, there are hardware-related factors, such as when the processor hangs up and becomes unable to continue operating, or when a program runs out of control. Also, the program may be created incorrectly. Even if an interrupt is applied to a hardware factor, it is difficult to determine the cause from the error log, and in order to return to a normal state from such a state,
It seems that the only option is to reset the processing device 1.

However, in the following cases due to software-related factors, it may be easier to investigate the cause and restore the normal state by keeping an error log. That is, one case is that the interrupt for regularly starting a program that controls execution according to the priority of tasks is set so as not to occur, and is not released for a long time. Another problem is that a task that has a higher priority than the task that clears the watchdog timer at regular intervals may be created by mistake, making it impossible to clear the watchdog timer at regular intervals. In such cases, there has been a problem in the past in that the cause of the watchdog error cannot be determined because there is no means to leave an error log.

Therefore, the present invention is useful when a watchdog error occurs.

An object of the present invention is to provide a program runaway monitoring device that can easily determine the cause of a failure.

[Structure of the Invention] (Means for Solving the Problems) In the present invention, a processing device inputs a watchdog timer timeout signal to start interrupt processing, and when processing the interrupt, logs the state of the program immediately before the interrupt processing. do. When the interrupt processing is completed, a timer clear signal is output to the response waiting timer. The response wait timer is started by inputting the timeout signal of the watchdog timer, and outputs a signal to reset the processing device when the timer clear signal is not input within the set time.

(Function) With the above configuration, even if a watchdog error occurs,
The software of the processing device can handle errors as much as possible. Further, when the interrupt processing is completed within a predetermined time, the state of the program immediately before the interrupt processing is logged, making it easy to understand the failure state.

(Embodiment) FIG. 1 is a block diagram of a program runaway monitoring device showing an embodiment of the present invention.

The same parts or equivalent parts as in FIG. 4 are denoted by the same reference numerals, and the description of the parts that have already been explained will be omitted.

The difference from FIG. 4 is that a response waiting timer 4 is provided. In addition, in FIG. 4, the processing device 1 is reset as a timeout by the watchdog timer timeout signal S2 of the watchdog timer 3, but inputs the watchdog timer timeout signal S2 of the watchdog timer 3 to the interrupt terminal Ic, The difference is that when the interrupt processing is successfully executed, a log immediately before the interrupt processing is left and a response wait timer clear signal S3 is output from the response wait timer clear terminal 1d to the response wait timer 4. The response wait timer 4 has a start terminal 4a that inputs the watchdog timer timeout signal S2 of the watchdog timer 3, a clear terminal 4b that inputs the response wait timer clear signal S3 from the processing device 1, and the processing device 1.
A timeout terminal 4C is provided for outputting a response waiting timer timeout signal S4. In addition, the response wait timer 4 receives the watchdog timer timeout signal S2 of the watchdog timer 3 to start the timer, and when the response wait timer clear signal S3 is input from the processing device 1 within a certain set time, The configuration is such that the response wait timer 4 is cleared at the time of input.

On the other hand, the response wait timer clear signal S3 within a certain set time
When the response wait timer timeout signal S4 is not inputted, the processing device 1 is configured to output a response waiting timer timeout signal S4 to force the processing device 1 to be reset and restarted.

The operation of the program runaway monitoring device with the above configuration is shown in Figure 2 (
A) This will be explained with reference to (B) and FIG.

The processing device 1 outputs a watchdog timer clear signal Sl at regular intervals when the program is operating normally. As a result, the watchdog timer 3 is cleared and no watchdog error occurs thereafter.

On the other hand, if the program of the processing device I is no longer able to operate normally, the watchdog timer clear signal St is no longer output. In this case, as shown in FIG. 2(A), which has been set by the watchdog timer 3 since the previous output of the watchdog timer clear signal S1, when a certain set time e has elapsed, the watchdog timer 3 A watchdog timer timeout signal S2 is output as error detection. In response to this watchdog timer timeout signal S2, the processing device 1 enters the interrupt processing routine shown in FIG. 3, while the response wait timer 4 is started. The processing device 1 that has entered the interrupt processing routine executes the processing routine program and logs the following information (101). That is, this includes a flag indicating whether interrupts are enabled or disabled, a log of the number of the task currently being executed, and the priority of the task. These logs are for later analysis of watchdog errors. Next, the interrupt status flag is checked (102). If this check shows that interrupts are not permitted, it is determined that the cause is as follows, the interrupt is permitted, and the operation of the target task is stopped (+03). In this case, it is determined that the cause (1) is that interrupts are not allowed because interrupts are set to periodically start a program that controls execution according to task priorities, and are not cleared for a long time. Upon permission of the interrupt state, a response wait timer clear signal S3 is output (104).

On the other hand, if the interrupt status flag is in the enabled state in the inspection of the interrupt status flag (1, 02), then the priority order of the task is inspected (105). In this inspection, if the task has a higher priority than the task that clears the watch timer, it is determined that the cause is as follows and proceeds to the next step (+
06). In this case, it is determined that the cause (2) is that a task with a higher priority than the task that clears the watchdog timer at a constant period was erroneously generated, making it impossible to clear the watchdog timer at a constant period. Therefore, the priority of that task is lowered (106), and the response wait timer clear signal S3 is thereby output (104). In this case, as shown in FIG. 2(A), the response wait timer clear signal S3 is output before the time f set by the response wait timer 4 has elapsed.

Therefore, the response wait timer 4 is cleared by the response wait timer clear signal S3, and the response wait timer timeout signal is not output to the processing device 1 of the computer. Therefore, the processing device 1 is not forced to be reset and returns to the original processing.

On the other hand, if the task has a lower priority than the task that clears the watchdog timer in step 104, it is determined that the above-mentioned (1) and (2) are not the cause, and the response wait timer clear signal S3 is not output. The processing device 1 is reset and restarted as will be explained later. That is, as shown in FIG. 2(B), if the response wait timer clear signal S3 is not outputted from the processing device 1 even after the time f set by the response wait timer 4 has elapsed since the detection of the watchdog error, the response wait timer is activated. 4 forcibly resets the response waiting timer timeout signal S4 to the processing unit 1 of the computer and restarts it. This operation is similar to that of the watchdog timer 3 described in the conventional example.

Even in situations where a watchdog error occurs like this,
Since the state of the program immediately before the watchdog error is detected in the processing device 1 is logged, it is easy to identify the cause.

For example, if a program error causes the program to enter a loop that cannot be exited forever, or a task with a higher priority than the task that clears the watchdog timer at a fixed period is created, and the processing unit There are cases where the processing takes time. This is effective in elucidating the cause when a watchdog error occurs in such a situation.

[Effects of the Invention] As described above, according to the present invention, the state of the program immediately before a watchdog error is detected is logged. Therefore, when a watchdog error occurs due to a programming error or the like, it becomes easy to find the cause.

[Brief explanation of the drawing]

FIG. 1 is a block configuration diagram of a program runaway monitoring device showing an embodiment of the present invention, FIGS. 2A and 2B are explanatory diagrams explaining the operation of the device, and FIG. 3 is a processing section of the device. FIG. 4 is a block diagram of a conventional program runaway monitoring device. 1... Processing device, 2... Program runaway monitoring unit, 3
...Watchdog timer, 4...Response wait timer. Agent Patent Attorney Noriyuki Chika Figure 1 (A) Se (B); Figure 2 Figure 3 Figure 4

Claims (1)

[Scope of Claims] A program runaway monitoring device for monitoring runaway of a program in a processing device using a watchdog timer, the processing device comprising means for inputting a timeout signal of the watchdog timer to start interrupt processing;
A logging means for logging the state of the program immediately before the interrupt processing is provided by this interrupt processing, and a means for outputting a timer clear signal when the interrupt processing is completed, and a timeout signal of the watchdog timer is input to start the watchdog timer. A program runaway monitoring device further comprising a response wait timer that outputs a signal to reset the processing device when the timer clear signal is not input within a set time.