JP3124788B2 - Exception handling method of embedded multitasking operating system - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an exception handling method for an embedded multitasking operating system capable of processing a plurality of user tasks in parallel.

[0002]

2. Description of the Related Art For example, when a plurality of tasks (processing units) need to be executed in parallel in a device such as a facsimile machine that performs operation control using a microcomputer system, the control system includes: You are using a multitasking operating system.

In such a multitasking operating system, it is necessary to perform a function check of the control software several times until the control software of the apparatus is completed, that is, a so-called debugging work, and various functions for convenience are provided. ing.

For example, a user task program (hereinafter, referred to as a user task program)
A trace function that can check the execution status of a program (step-by-step), a break function that can stop the program at any time, and a hardware system that runs out of control when a program runs out of control due to inconvenience (hereinafter referred to as a bug). For example, a watchdog timer function to stop.

[0005]

However, in such a conventional apparatus, when the system goes out of control during debugging, not only the task causing the runaway but also the execution state of other tasks may be changed. In such a case,
There has been a problem that the operator cannot determine which task has a bug.

In addition, during operation of a device incorporating the completed control software, depending on the operating environment of the device, noise may be mixed into the bus inside the system and the data on the bus may be destroyed. There have been inconveniences such as being in an impossible state or destroying devices incorporated in the apparatus.

Further, since it is necessary to provide a hardware element such as a watchdog timer for system runaway,
There has been an inconvenience that the cost increases.

SUMMARY OF THE INVENTION The present invention has been made in view of the above circumstances, and has been made so that debugging can be performed efficiently, the influence of system runaway can be suppressed, and system runaway can be detected by software. It is an object of the present invention to provide an exception handling method for an embedded multitasking operating system.

[0009]

SUMMARY OF THE INVENTION The present invention relates to an exception handling method for an embedded multitasking operating system capable of processing a plurality of user tasks in parallel. On the other hand, when the processor is used for device function inspection, if an illegal instruction fetch is detected a predetermined number of times in succession from the same user task, the user task is shifted to a forced wait state,
Another user task is executed.

Also, in an exception handling method of an embedded multitasking operating system capable of processing a plurality of user tasks in parallel, a microprocessor capable of detecting that an illegal instruction has been fetched is used. When an illegal instruction fetch is detected a predetermined number of times in succession from the same user task, the user task is forcibly terminated and another user task is executed.

[0011]

[0012]

Therefore, at the time of the device function test, the user task that caused the system runaway is shifted to the forced wait state, so that the system runaway is prevented from affecting other user tasks, and the device function is prevented. Inspection can be performed efficiently. Also, when the apparatus is operating, the user task that caused the system runaway is forcibly terminated, so that the system runaway is prevented from affecting other user tasks.

[0013]

Embodiments of the present invention will be described below in detail with reference to the accompanying drawings.

FIG. 1 shows an apparatus model according to an embodiment of the present invention.

In FIG. 1, a CPU (central processing unit) 1
Is used to control the operation of this device.
The (read only memory) 2 stores a processing program executed by the CPU 1 and various data necessary for executing the processing program.
The (random access memory) 3 forms a work area for a processing program executed by the CPU 1. Further, the CPU 1 has an illegal instruction detecting function for detecting that an illegal instruction has been fetched.

The I / O port 4 is connected to the peripheral devices 5 and 6 and the CP
U1 is connected, and the peripheral devices 5 and 6 are
Each is for realizing the function of this device.
For example, in the case of a facsimile machine, the peripheral devices 5 and 6 correspond to a scanner for reading an image and a plotter for recording and outputting an image.

These CPU1, ROM2, RAM3,
The I / O port 4 is connected to the internal bus 7, and data exchange between these elements is performed via the internal bus 7.

In this device model, as shown in FIG.
The system is hierarchical.

In FIG. 1, a system resource is a CPU.
1. Work area of RAM3 and peripheral devices 5, 6
The user task represents a processing unit of software for realizing the processing function of the device, and the multitask operating system (hereinafter, referred to as M_OS) represents system software for efficiently processing the execution of the user task. .

The M_OS has a function of executing a plurality of user tasks in parallel. In this embodiment, a request to execute a process from a user task issues data of a predetermined format called a system call. Performed in form. The system call is issued by issuing a software interrupt in a state where a function code representing a processing function for requesting execution is set in a predetermined register. The processing functions include a general-purpose subroutine module commonly used by a plurality of user tasks.

Further, in this device model, as shown in FIG. 3A, M_O
The memory space of the CPU 1 is divided into an S area, a user task area in which a user task program is arranged, a work area, and a data table area.

Here, a plurality of tasks are stored in the user task area as shown in FIG.

Normally, one step of the program code executed by the CPU 1 is composed of an instruction code and an operand code for specifying a resource (memory or register, etc.) to be executed by the instruction code.
When the CPU 1 goes out of control for any reason, a situation may occur in which the operand code is erroneously fetched as an instruction code or the instruction code of the next step is erroneously fetched as an operand code.

When such a situation, that is, an illegal instruction fetch phenomenon occurs, the CPU 1 enters an illegal instruction interrupt state and executes a predetermined process.

FIG. 4 shows an example of an illegal instruction interruption process executed by the CPU 1 when debugging the software of the device model. This illegal instruction interrupt processing is performed by M
This is one of the processes executed by the _OS.

First, when an illegal instruction interrupt state occurs, M_O
S waits for the currently executing task (WAIT
State), the contents of the register of the CPU 1 at that time are saved in a predetermined area (process 101), and a variable T for storing the task in which the illegal instruction interrupt state is detected.
It is checked whether or not _TCB is equal to the identification information C_TCB of the task being executed at the time (decision 102).

When the result of the judgment 102 is YES, the counter T_CNT for storing the number of times the illegal instruction interrupt state is continuously detected for the same task is decremented (process 103), and the value of the counter T_CNT becomes 0. It is checked whether they are equal (decision 104).

If the result of decision 104 is YES, the same task sends an invalid system call N (predetermined value)
In this case, the task is in an abnormal state. Therefore, a predetermined exception handling routine (not shown) is executed (processing 105), and the task being executed is forcibly waited (SU).
(SPEND state) (process 106), and the variable T
_TCB is set to a predetermined value NULL, and a counter T_CNT is set to a predetermined value N (Process 10
7).

Next, a task to be executed next is selected from a plurality of tasks registered in an executable state (READY state) according to a predetermined execution schedule (step 108), and the selected task is executed. To do so, the contents of the register are updated to the contents corresponding to the selected task (process 109), and the state is shifted to a state in which the task is executed.

On the other hand, when the result of the determination 104 is NO, the process shifts to a process 108 to shift to an execution state of a task to be executed next.

When the result of the determination 102 is NO, the contents of the identification information C_TCB are set in a variable T_TCB (step 110), and a predetermined value N is set in a counter T_CNT.
Is set (process 111), and it is determined whether or not the predetermined value N is equal to 0 (determination 112).

When the result of the determination 112 is YES, the processing shifts to step 105 to shift to the exception processing state, and when the result of the determination 112 is NO, the processing 10
Then, the process shifts to the execution state of the task to be executed next.

As described above, in this embodiment, when an illegal instruction interrupt state is detected N times consecutively during execution of the same task during debugging, it is determined that the task being executed is abnormal. SUSP with the task in an abnormal state
Since the transition is made to the END state, it is possible to prevent a situation in which the abnormality of this task causes the execution state of another task to become abnormal.

Further, when a break is made at an appropriate timing, a task that has transited to the SUSPEND state in the abnormal state can be appropriately traced, and thus efficient debugging can be performed.

FIG. 5 shows an example of an illegal instruction interruption process executed by the CPU 1 when the debugging of the software of the device model is completed and the device model is actually operated. This illegal instruction interruption processing is one of the processing executed by the M_OS.

First, when an illegal instruction interrupt state occurs, M_O
S waits for the currently executing task (WAIT
State), the contents of the register of the CPU 1 at that time are saved in a predetermined area (process 201), and a variable T for storing the task in which the illegal instruction interrupt state is detected.
It is checked whether or not _TCB is equal to the identification information C_TCB of the task being executed at the time (decision 202).

When the result of the determination 202 is YES, the counter T_CNT for storing the number of times the illegal instruction interrupt state is continuously detected for the same task is decremented (process 203), and the value of the counter T_CNT is set to 0. It is checked whether they are equal (decision 204).

When the result of determination 204 is YES, the same task makes an illegal system call N (predetermined value)
In this case, the task is in an abnormal state, so that a predetermined exception handling routine (not shown) is executed (process 205), and an end routine corresponding to the task being executed is executed to execute the task. Release all the system resources used (process 206), set a predetermined value NULL to a variable T_TCB, and set a predetermined value N to a counter T_CNT (process 207).

Next, a task to be executed next is selected from a plurality of tasks registered in an executable state (READY state) according to a predetermined execution schedule (step 208), and the selected task is executed. In order to execute the task, the content of the register is updated to the content corresponding to the selected task (process 209), and the state is shifted to the task execution.

On the other hand, when the result of the determination 204 is NO, the process shifts to a process 208 to shift to an execution state of a task to be executed next.

When the result of the determination 202 is NO, the contents of the identification information C_TCB are set to the variable T_TCB (step 210), and the predetermined value N is set to the counter T_CNT.
Is set (process 211), and it is determined whether or not the predetermined value N is equal to 0 (determination 212).

When the result of the determination 212 is YES, the process shifts to step 205 to shift to the exception processing state, and when the result of the determination 212 is NO, the process 20
Then, the process shifts to the execution state of the task to be executed next.

As described above, in the present embodiment, when an illegal instruction interruption state is detected N times consecutively while the same task is being executed while the apparatus is operating, it is determined that the task being executed is abnormal. Since the task is forcibly terminated, it is possible to prevent a situation in which the abnormality of the user task causes the execution state of another task to become abnormal.

Further, at that time, a termination routine corresponding to the abnormal task is executed to release the system resources used by the task, and at the same time, the task replaces another task (hereinafter referred to as a child task). When the user wakes up or generates a task, the child task is deleted and the work area is released.

By the way, to detect that the operation of the CPU 1 has gone out of control by software, for example, the following may be performed. This operation is executed by the M_OS. In this case, the runaway state of the CPU 1 is detected before and after the user task calls a general-purpose subroutine module, that is, before and after performing a so-called subroutine call.

First, when the user task makes a subroutine call, an identification number assigned to each subroutine module to be called, for example, 01H (H
Represents a hexadecimal number; the same applies hereinafter) onto the common stack (see FIGS. 6A and 6B).

Then, the M_OS pushes (stores) a return address (in this case, 2 bytes) for returning to the user task that issued the subroutine call after the subroutine module is completed (FIG. 6).
(Refer to (c)), execute the requested subroutine module. In this running state, a work area required for the subroutine module is secured on the common stack (see FIG. 6D).

When the execution of the subroutine module is completed, M_OS stores 2 in the stack pointer SP at that time.
The identification number (01H in this case) stored in the stack address area position of the common stack to which the subroutine module has been added is taken out, and is compared with the value of the identification number set in the subroutine module which has been executed at that time (FIG. 6 (e)
reference).

At this time, if the two are equal, it can be determined that the system is not in a runaway state during the execution of this subroutine module.
Data 0 is set in the common stack area storing the identification number so as to cope with the issuance of the subroutine call (see FIG. 6F).

When the value of the identification number stored in the common stack area does not match the identification number set in the subroutine module, it can be determined that the system is in a runaway state. Predetermined exception handling,
For example, a system reset process is performed.

As described above, every time the user task makes a subroutine call, the operation of determining whether or not the system is in a runaway state is performed. Therefore, a special hardware such as a watchdog timer for detecting a system runaway is used. No mechanical mechanism is required.

Normally, when the system goes into a runaway state, a task that has nothing to do with the task that issued the subroutine call is activated by a return instruction from the subroutine detected first after the runaway, or A situation such as a case where the control is shifted to the execution state of the subroutine due to the noise on the bus 7 occurs.

Therefore, as described above, the system runaway state can be appropriately detected by performing the inspection process of the identification number corresponding to the subroutine before and after the subroutine call.

FIG. 6 shows an example of processing when a subroutine call is issued from a user task.

First, the identification number set in the subroutine module requested to be executed by the issued subroutine call is pushed onto the common stack (step 30).
1), the requested subroutine module is executed (process 302).

When the execution of the subroutine module is completed, the value of the stack pointer SP indicating the head area of the common stack is increased by one, so that the stack pointer S is moved to the area next to the identification number pushed onto the common stack.
The value of P is moved (process 303), and the process proceeds to the next process.

FIG. 7 shows an example of processing at the time of a subroutine call.

First, the subroutine module requested to be executed is executed (process 401), and when the process is completed,
Since the value of the stack pointer SP at that time indicates the top stack address of the return address, the identification number stored in the stack address obtained by adding 2 to the value of the stack pointer SP is extracted (process 402).

Then, it is checked whether or not the identification number set in the subroutine module which has been executed at that time coincides with the extracted identification number (decision 40).
3) If the result of determination 403 is YES, data 0 is set in the stack area storing the identification number (process 404), and the process returns to the user task that called the subroutine.

When the result of determination 403 is NO, it is determined that a system runaway condition has occurred, a predetermined exception process is executed (process 405), and the process ends with an error.

In the above-described embodiment, when a subroutine call is issued, the identification number corresponding to the subroutine is recorded directly in the stack area. However, this identification number is recorded via a register. You can do it.

[0062]

As described above, according to the present invention,
During the device function test, the user task that caused the system runaway is transitioned to the forced wait state, so that the system runaway is prevented from affecting other user tasks, and the device function test is performed efficiently. The effect that can be obtained. Also, when the device is operating, the user task that caused the system runaway is forcibly terminated.
An effect is also obtained that the system runaway is prevented from affecting other user tasks.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an apparatus model according to one embodiment of the present invention.

FIG. 2 is a schematic diagram showing an outline of a system configuration of the device model of FIG. 1;

FIG. 3 is a schematic diagram illustrating a mode of dividing a memory space of the device model of FIG. 1;

FIG. 4 is a diagram showing a state where an illegal instruction interrupt state is detected when debugging software of the device model of FIG. 1;
9 is a flowchart illustrating an example of processing executed by the OS.

FIG. 5 is a flowchart showing an example of processing executed by the M_OS when an illegal instruction interruption state is detected during operation of the device model of FIG. 1;

FIG. 6 is a schematic diagram for explaining an operation of detecting system runaway by software.

FIG. 7 is a flowchart showing a processing example for implementing the operation of FIG. 6;

FIG. 8 is a flowchart showing another processing example for realizing the operation of FIG. 6;

[Explanation of symbols]

 1 CPU (central processing unit)

Claims (2)

(57) [Claims] 1. An exception handling method for an embedded multitasking operating system capable of processing a plurality of user tasks in parallel, using a microprocessor capable of detecting that an illegal instruction has been fetched, When an illegal instruction fetch is detected a predetermined number of times in succession from the same user task, the user task is shifted to a forced wait state and another user task is executed. Exception handling method. 2. An exception handling method for an embedded multitasking operating system capable of processing a plurality of user tasks in parallel, wherein a microprocessor capable of detecting that an illegal instruction has been fetched is used. And detecting an illegal instruction fetch from the same user task a predetermined number of times in succession, forcibly terminating the user task, and executing another user task.