JPH04229331A - How to handle exceptions in an embedded multitasking operating system - Google Patents

Abstract

PURPOSE:To perform debugging operation efficiently and to suppress the influence of a system runaway. CONSTITUTION:A CPU(central processing unit) 1 controls the operation of a device, a ROM 2 is stored with a process program that the CPU 1 executes and various data required for the execution of the process program, and a RAM 3 has a work area for the process program that the CPU 1 executes. An I/O port 4 connects peripheral devices 5 and 6 to the CPU 1. In this device model, if the same user task makes a system call for an undefined function successively by a specific number of times at the time of device function inspection, the user task is forcibly placed in a wait state.

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 it is necessary to execute multiple tasks (processing units) in parallel in a device such as a facsimile device that uses a microcomputer system to control its operation, the control system is You are using a multitasking operating system.

[0003] In such a multitasking operating system, it is necessary to perform a function check of the control software several times, or so-called debugging, until the control software for the device is completed. ing.

[0004] For example, a user task program (hereinafter referred to as
A trace function that allows you to inspect the execution status of a program (hereinafter simply referred to as a program) step by step, a break function that allows you to stop a program at any point, and a watch function that stops the system when the system goes out of control due to an inconvenience in the program (hereinafter referred to as a bug). This includes a dog timer function, etc.

[0005]

[Problem to be Solved by the Invention] However, in such conventional devices, when the system goes out of control during debugging, the execution state of not only the task that caused the runaway but also other tasks may change, and this In such a case,
This caused an inconvenience in that the operator could not determine which task had the bug.

[0006] Furthermore, while a device incorporating the completed control software is in operation, depending on the operating environment of the device, noise may enter the system's internal bus, destroying data on the bus, causing the system to run out of control. This has caused inconveniences such as making it impossible or destroying equipment built into the device.

The present invention has been made in view of the above circumstances, and provides an exception handling method for an embedded multitasking operating system that allows efficient debugging work and suppresses the effects of system runaway. It is intended to.

[0008]

[Means for Solving the Problems] The present invention transitions the user task to a suspended state when a system call for an undefined function is issued a predetermined number of times in succession from the same user task during a device function test. This is how it was done.

Furthermore, when the system call for an undefined function is issued a predetermined number of times in succession from the same user task during operation of the device, the user task is forcibly terminated.

0010

[Effect] Therefore, during device function inspection, the user task that caused the system runaway is placed in a forced wait state, which prevents the system runaway from affecting other user tasks. Functional tests can be performed efficiently. Further, when the apparatus is in operation, the user task that caused the system to run out of control is forcibly terminated, so that the influence of the system to run out of control is prevented from affecting other user tasks.

[0011]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

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

In the figure, a CPU (central processing unit) 1
controls the operation of this device, and the ROM (
The read-only memory) 2 stores the processing program executed by the CPU 1 and various data necessary to execute the processing program.
A random access memory (Random Access Memory) 3 serves as a work area for processing programs executed by the CPU 1.

[0014] The I/O port 4 is connected to peripheral devices 5, 6 and the CP.
It is for connecting U1, and the peripheral devices 5 and 6 are
Each is used to realize the functions of this device. For example, in the case of a facsimile machine, the peripheral devices 5 and 6 include a scanner for reading images and a plotter for recording and outputting images.

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

In the figure, the system resources are CPU1
, the work area of RAM 3, peripheral devices 5 and 6, etc., a user task represents a processing unit of software that realizes the processing functions of this device, and a multitasking operating system (hereinafter referred to as OS) represents a user task. Represents system software for efficiently processing task execution.

[0017] This OS has a function of executing multiple user tasks in parallel, and in this embodiment, a processing execution request from a user task is issued by issuing data in a predetermined format called a system call. It is done in form. Further, this system call is issued by issuing a software interrupt while setting a function code representing the processing function to be executed in a predetermined register.

In addition, in this device model, as shown in FIG. 3(a), an OS area where OS programs are placed;
The CP is placed in the user task area, work area, and data table area where user task programs are placed.
U1's memory space is divided.

Here, in the user task area, there is a
), multiple tasks are stored.

FIG. 4 shows an example of the processing that the OS executes when a system call is issued from a user task when debugging the software of this device model with the above configuration.
Shown below.

First, when a software interrupt is input, the OS puts the task currently being executed into a waiting state (W
AIT state) and CPU1 at that time.
Save the contents of the register to a predetermined area (process 101)
, determine whether the function of the issued system call is undefined (decision 102).

[0022] When the result of judgment 102 is NO,
Since this is a normal system call, the process corresponding to the function code specified at that time is executed (process 103),
When the process is finished, a task to be executed next according to a predetermined execution schedule is selected from among multiple tasks registered in an executable state (READY state) (process 104), and the selected task is In order to execute the task, the contents of the register are updated to the contents corresponding to the selected task (process 105), and a transition is made to a state in which the task is executed.

Further, when the result of judgment 102 is YES, check whether the variable I_TCB for storing the task that issued the illegal system call is equal to the identification information C_TCB of the task that issued the system call ( Judgment 106), when the result of judgment 106 is NO, the content of identification information C_TCB is set in variable I_TCB (process 107), and a counter is set to store the number of consecutive invalid system calls issued by the same task. I
A predetermined value N is set in _CNT (process 108), and the process moves to process 104 to resume execution of the task whose execution was interrupted.

Further, when the result of judgment 106 is YES, the counter I_CNT is decremented (processing 1
09), and checks whether the value of counter I_CNT is equal to 0 (decision 110).

[0025] When the result of decision 110 is NO,
Without executing the function of the system call issued at that time, the process moves to process 104 and resumes execution of the interrupted task.

Further, when the result of judgment 110 becomes YES, it means that the same task has issued an invalid system call N times in a row, and the task is in an abnormal state, so a predetermined exception handling routine (not shown) is executed. ) (process 111), and puts the currently executing task into a forced wait state (SUSPE).
ND state) (processing 112), and the variable I_TC
B is set to a predetermined value NULL (processing 113
), and sets a predetermined value N to the counter I_CNT (processing 1
14) The process moves to process 104 and resumes execution of the task whose execution was interrupted.

In this way, in this embodiment, when the same task issues an invalid system call N times in a row during debugging, it is determined that the user task that issued the system call is abnormal, and the user task that issued the system call is determined to be abnormal. Since the user task is transitioned to the SUSPEND state while in the abnormal state, it is possible to prevent a situation in which the execution state of other tasks becomes abnormal due to an abnormality in this user task.

Furthermore, if a break is made at an appropriate timing, it is possible to appropriately trace the task that has been transitioned to the SUSPEND state while in its abnormal state, and therefore efficient debugging work can be performed.

FIG. 5 shows an example of the processing that the OS executes when a system call is issued from a user task when debugging the software of this device model is completed and this device model is actually operated. .

First, when a software interrupt is input, the OS transitions the task currently being executed to the WAIT state, and saves the contents of the register of the CPU 1 at that time to a predetermined area (process 201). It is checked whether the function of the issued system call is undefined (decision 202).

[0031] When the result of judgment 202 is NO,
Since this is a normal system call, the process corresponding to the function code specified at that time is executed (process 203),
When the process is finished, a task to be executed next according to a predetermined execution schedule is selected from among multiple tasks registered in an executable state (READY state) (process 204), and the selected task is In order to execute the task, the contents of the register are updated to the contents corresponding to the selected task (process 205), and a transition is made to a state in which the task is executed.

Further, when the result of judgment 202 is YES, it is checked whether the variable I_TCB is equal to the identification information C_TCB of the task that issued the system call (judgment 206), and when the result of judgment 206 is NO, , sets the contents of the identification information C_TCB in the variable I_TCB (process 207), sets the predetermined value N in the counter I_CNT (process 208), moves to process 204, and resumes execution of the task whose execution was interrupted.

Further, when the result of judgment 206 is YES, the counter I_CNT is decremented (processing 2
09), check whether the value of counter I_CNT is equal to 0 (decision 210).

[0034] When the result of decision 210 is NO,
Without executing the function of the system call issued at that time, the process moves to process 204 and resumes execution of the task whose execution was interrupted.

Further, when the result of judgment 210 becomes YES, it means that the same task has issued an invalid system call N times in a row, and the task is in an abnormal state, so a predetermined exception handling routine (not shown) is executed. ) (process 211), executes the end routine corresponding to the task being executed, releases all system resources used by that task (process 212), and sets a predetermined value NUL to the variable I_TCB.
At the same time as setting L (processing 213), counter I_
A predetermined value N is set in CNT (process 214), and process 20
4, the execution of the task whose execution was interrupted is resumed.

In this way, in this embodiment, when the same task issues an invalid system call N times in succession during device operation, it is determined that the user task that issued the system call is abnormal, and the user task that issued the system call is determined to be abnormal. Since the user task is forcibly terminated, it is possible to prevent a situation in which the execution status of other tasks becomes abnormal due to an abnormality in this user task.

At that time, the termination routine corresponding to the abnormal user task is executed to release the system resources used by that user task, and the user task is also When a task (referred to as a task) is woken up or created, its child tasks are destroyed and the work area is released.

[0038] In the above-mentioned embodiment, the system call is realized using software interrupts.
The present invention can be applied in the same way even if the implementation form of the system call is different from this embodiment.

[0039]

[Effects of the Invention] As explained above, according to the present invention,
During a device function test, the user task that caused the system out of control is placed in a forced wait state, which prevents the system out of control from affecting other user tasks, making the device function test more efficient. can be done. Furthermore, since the user task that caused the system runaway during operation of the device is forcibly terminated, the effect of preventing the system runaway from affecting other user tasks is obtained.

[Brief explanation of the drawing]

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

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

FIG. 3 is a schematic diagram illustrating how the memory space of the device model in FIG. 1 is divided.

FIG. 4 is a flowchart showing an example of processing executed by the OS when a system call is issued from a user task when debugging the software of the device model in FIG. 1;

FIG. 5 is a flowchart showing an example of processing executed by the OS when a system call is issued from a user task during operation of the device model in FIG. 1;

Claims (2)

[Claims] Claim 1: In an exception handling method for an embedded multitasking operating system capable of processing multiple user tasks in parallel, during a device function test, a system call for an undefined function is made consecutively from the same user task a predetermined number of times. An exception handling method for an embedded multitasking operating system, characterized in that when a user task is issued, the user task is transited to a suspended state. Claim 2: In an exception handling method for an embedded multitasking operating system that can process multiple user tasks in parallel, when the device is operating, a system call for an undefined function is made consecutively from the same user task a predetermined number of times. An exception handling method for an embedded multitasking operating system, characterized in that when an exception is issued, the user task is forcibly terminated.