JPS59214929A - Input/output control device having diagnosing function - Google Patents

Abstract

PURPOSE:To diagnose an I/O device without influencing on a processing system by reading out optionally the contents of trouble shooting built in the I/O device from a processor when necessary. CONSTITUTION:History codes corresponding to the movement of an I/O control device 1 are stored in a readable/writable RAM6 by setting up the history codes corresponding to the functions of the I/O control device 1 to all operations in the I/O control device 1. The stored contents can be read out and recognized by a DCW (device control information) from the processor 5 when necessary or at the generation of a trouble. Thus, information necessary for trouble shooting and debugging can be read out without exerting the influence on the processing system as seen in the conventional case. Especially, a trapping function enabled to be set up by using the function together with the history codes is used as an analyzing means effective for the division of a trouble in a field.

Description

[Detailed Description of the Invention] [Field of Application of the Invention] The present invention improves troubleshooting and hardware debugging efficiency when a failure occurs in an input/output device in a system in which input/output devices having different input/output control methods are connected. This invention relates to an input/output control device that has a diagnostic function that facilitates diagnosis.

[Background of the invention]

There are various types of input/output devices for computer systems.
Many input/output control devices have been developed depending on their structure and performance.

``With the spread of microprocessors in recent years, the control center of input/output control devices has become microprogrammed, and along with the diversification of functions, the capacity is also increasing. As a result, there is a growing need for debugging and troubleshooting of microprograms.

When debugging a microprogram, it is done by connecting a tester with a tool, but when connected to a tester, there are limitations to the circuit conditions such as the timer of the υ control circuit not operating normally, etc., making it difficult to debug effectively. Not.

In addition, when using a tester, it is necessary to set and check a stop address for each processing point, which causes problems such as difficulty in debugging and the debugging period increasing as the program capacity increases. . Furthermore, if an input/output control device equipped with a microprogram, which is considered to be the most serious problem, fails in the field, the program that occupies the core of the input/output control device is stored in read-only memory and cannot be checked by Schfield. Can not. For this reason, traps are inserted into the operating system and application software of the system stored in rewritable memory to detect failures, and examples of failure analysis are used. However, this method is a countermeasure against unnecessary additions to normal program areas. This can have a significant impact on the system due to the occurrence of secondary failures due to omission of later modifications and loss of time required for trap insertion. Furthermore, even with the above-mentioned countermeasures, it is extremely difficult to confirm them due to the distributed processing and complexity of today's systems, which are becoming larger.

[Purpose of the invention]

An object of the present invention is to eliminate the problems of the prior art described above;
The input/output control device has a built-in function that facilitates troubleshooting of the input/output device without affecting the system, and has a diagnostic function that allows the contents to be read out from the processing device at any time as needed. Its purpose is to provide an input/output control device.

[Summary of the invention]

In order to achieve the above object, in the present invention, a history code associated with each operation route of a processing function is written in the memory of the input/output control device every time it receives device control information from the processing device, and can be read out from the processing device at any time, and has a trap function for history codes defined for each route, making it possible to stop addresses on any route and facilitate online troubleshooting. This is what I did.

Here, the history code is indicator data stored in ROM to check the flow of the program. Specifically,
It consists of numerical values defined in binary or hexadecimal representation for each microprogram route of an input/output control device for controlling input/output devices such as line printers, CRTs, typewriters, etc.

[Embodiments of the invention]

Examples of the present invention will be described in detail below. FIG. 1 shows the case where the present invention is implemented using a microcomputer.
An example of the hardware configuration of an input/output control device is shown. The input/output control device 1 surrounded by a dotted line includes a microcomputer 2, a control circuit 3 that generates and receives various control signals such as a system clock and interrupt signals, and a control circuit 3 that controls the entire input/output control device and controls the input/output devices. A control ROM 4 in which programs for controlling and diagnostic processing are stored, a control R, an input/output data buffer area for transmitting and receiving data to and from the work area of the OM 4 and the processing device 5, and a RAM 6 for storing data associated with the diagnostic processing.
It is composed of an input/output module interface 11 which performs input/output processing with the processing device 5 and an input/output device interface 11 which transmits input/output data 9 and control signals 10 with the input/output device 8. The blocks are connected by a data bus 12 and a control bus 13 for transferring address signals and control signals, and are still connected to the processing device 5 by an input/output bus 14. From the processing device 5,
Device control information (hereinafter abbreviated as DCW) and input/output data for controlling the input/output device 8 are input through the input/output bus 14, and this is input to the input/output bus interface 7,
The data is loaded into the RAM 6 via the data bus 12. The control program in the control ROMd decodes the DCW of
According to the decoding results, processing such as data transfer with the input/output device 8 and diagnosis is performed.

As shown in Figure 2, DCW is generally FUNCTIO
From N15 and a plurality of additional information 16, 1;'UN
CTION 15 specifies data input or output, setting trap detection requests, reading information in the input/output control device, etc. Additional information 16 contains detailed information necessary for operation in each FUNCTION. The settings are made here.

All operations of this input/output control device l are managed by a control program in the control ROM 4, and as shown in FIG. O8 (operating system) 17 manages the hardware and software of the entire device; input/output bus management 18 sends and receives data to and from the processing device 5 using the input/output bus interface 7; and transmits information to the processing device 5 in the event of a power outage. It consists of a power outage process 20 that sends data, and a FUNCTION process 25 that sends and receives data to and from input/output devices. Furthermore, the FUNCTION processing 25 is performed using the DCW FU described above.
DCW decoding processing 19 for decoding the NCTION part and causing each FUNCTION processing program to execute it; trap detection request processing 21. It consists of a data input/output processing 22, a memory read processing 23, and an UNCTION execution unit.

FIG. 4 shows an example of a processing program within the input/output control device when the DCW is sent from the processing device 5. The input/output control device 1 receives the DCW generated by the processing device 5 via the bus 14. The input/output control device 1 decodes the DCW and determines what type it is. The addition of the history code is set in advance to all programs related to DCW. Figure 4 shows an example of the program.
A processing program in which the input/output device receives data from the processing device 5 via the input/output control device 1 is shown.

Various other programs also exist. In other words, there are various types of input/output devices such as typewriters, printers, magnetic tape devices, magnetic drums, magnetic disks, CRTs, keyboards, etc., and each input/output device itself has various shapes and sizes; The present invention targets these various input/output devices, and furthermore, the processing includes various processing contents such as data transfer for printing processing and processing for sending input data to the processing device 5. Because of this.

The processing program shown in FIG. 4 is a program in which the input/output control device 1 receives transfer data from the processing device 5, and the input/output device 1 transfers the transferred data to the input/output device 8. Therefore, the input/output device 8 is, for example, a typewriter.

In order to realize such a processing program in the conventional example, steps 29, 30, 31, 33 and start (ST
Only the steps AR, T) and END are required. Steps 27 and 28 are steps that would enable more accurate processing if provided, and are not essentially necessary.

However, FIG. 4 is characterized in that steps 27 and 28 are provided, and steps 26, 32, 34, and 35 are provided. Steps 26, 32, 34, and 35 are ROMd
Read the history code stored in the memory (RAM) 6
It performs the function of storing. In step 26, the history code A
1 In step 31, history code B is read, in step 34 history code C1, in step 35 history code D is read out R
Store in AM6. This provenance code A, B, C.

D is just a code expressed in binary or hexadecimal and has no meaning like an operation code of an instruction.

It is simply a code indicating a sign.

In the figure, this provenance code is used at the entrance of the process (step 26).
), exit (step 32), and branching position of the processing content (
Step 34 related to Step 27 and Step 35 related to Step 28). This makes it easy to confirm the operation history of the processing program.

Here, confirmation of the operation history of the processing program is as follows. For example, if the input/output device is a printer, the fourth
The figure shows a processing program that sends print data to this printer. Generally, printing data is printed several times. Therefore, when the processing program shown in FIG. 4 is executed normally, A is stored in the history code storage area of the RAM 6.

B/A, B/A, B/... Step 2
History code A because 6°32 is executed alternately.

B are stored alternately. Therefore, in normal processing, A, B
are repeated alternately.

On the other hand, if an abnormality occurs in the above processing, for example, an instruction error occurs in step 27, the history code storage area of the RAM 6 will contain A, B/A, B/C/C/C/...
A history code such as ... is stored.

Storage of the history code C starts when an abnormality occurs.

When an abnormality occurs in step 28, KD is stored instead of C. Note that the number of times C and D are repeated varies depending on the system.

As described above, the history code area of the RAM 6 stores the history code according to the flow of the processing program, and the maintenance worker can read and inspect the stored data. This makes it possible to easily check whether the processing program is normal or not, and when an abnormality occurs, which part is abnormal.

A processing program into which the history code is inserted is prepared in advance and stored in the ROM 4. Generally, there are multiple processing programs into which history codes are inserted. Therefore, memory 6
The storage area for the history code is also determined in advance according to the type of processing program.The determination of the processing program into which the history code is to be inserted, the location for insertion, and the actual insertion work are the responsibility of the manufacturer. This is because, in general, what programs are stored in the ROM 4 is the responsibility of the manufacturer at the OS level. Of course, the application program is created by the user. The history code may also be stored for inspection of this application program.

FIG. 5 shows a table 36 necessary for storing the history code in the memory 6. This table 36 is stored in the memory 6. The area of this table 36 forms a fixed area of the memory 6. The table 36 includes a history code memory write stop flag area 37, a trap request flag area 38, a trap code storage area 39, and a history code write address storage area 40 (2 words for 1 (configured to specify one address) and an area 41 for storing the history code itself.

Further, in FIG. 4, a relative address display is shown on the right side. A total of θ~+527 address areas were set.

FIG. 6 shows details of the processing contents in each of steps 26, 32, and 34.degree. 35 in FIG. 4. Provenance code is R,
All the steps of reading from 0M4 and storing in R and AM6 constitute the processing contents shown in FIG.

In FIG. 6, in step 42, a 1-byte provenance code (
In this example, the case where the history code is 1 byte will be described) is read from the ROM 4. Since which history code should be successively output is determined in advance for each step as shown in steps 26.32 and 34.35 in FIG. 4, the determined history code is read out.

In step 43, the return address of the main program is updated. The main program refers to a processing program as shown in FIG.

In step 44, the area 37 in the table 36 is inspected, and the area 36 (in the explanation of FIG. 4, it was explained as the area of the memory 6, but since the table 36 itself is set in the memory 6, First, it is checked whether the history code can be stored in the area (hereinafter referred to as area 36).

Whether or not the history code can be stored depends on whether the write stop flag is set in the area 37 of the table 36.

For example, the write stop flag is set when the power is turned off, and remains unchanged when the power is turned on. Therefore, when the power is on, the write stop flag is not set in area 37, and the process moves to step 45. If the writing stop knock is on, press R, ET.
Go to URN.

In step 45, the history code read in step 42 is stored in the address of area 41 specified by the write address stored in area 40 of table 36.

In step 46, the area 40 used in step 45 is
Add 1 to the history code write address of , and set the history code address to be written next.

In step 47, it is checked whether the next history code write address calculated in step 46 is the final address (+527.) of area 41. If the final address has not been reached, proceed to step 49.
The write address of the history code to be written next as calculated above is written in the designated area 40. If the final address has been reached, in step 50, the calculated history code write address to be written next is cleared, and the start address (+5) of the area 41 is set as the new history code write address. Next, in step 49, the start address of this area 41 is written into the area 40. Next, RETURN L returns to the main program at the return address.

Thereafter, this program runs every time the input/output control device processes are executed, and the power is turned off or as shown in FIG.

The history code is written in the table 41 in FIG. 5 until memory writing is stopped, which will be described later in FIG.

The fifth section includes the area where the history code explained above is stored.
The contents of the table 36 shown in the figure can be read at any time by the DCW shown in FIG. 8A issued by the processing device 5. This read content becomes data for maintenance work and failure analysis. The contents of areas 54 and 55 in the DCW are additional information that is particularly necessary for reading. FIG. 9 shows 70- of this readout.

For checking the reading program shown in FIG. 9, a history code E is provided at the start position and end position.

The program configuration of the ROM is taken to read out F.

As a result, as shown in FIG. 9, when the program is executed, the history codes E and F are read from R and OM and stored in the memory 6 in steps 58 and 64.

The process shown in FIG. 9 will be explained. At the start of the reading program, the history code E is read from the ROM 4 and stored in the area 41 of the table 36 in the memory 6 in step 58 .

In step 59, a buffer for transmission is secured to temporarily store the read contents of the area 41, and the memory read start address of the area 54 is set.

In step 60, one byte is read from the history code storage area 41 and stored in the transmission buffer. Step 6
1 updates the read address and transmission buffer address (+1) L, and subtracts the number of read words in area 55 (-1).
)do. Further, in step 62, it is checked whether the number of words to be read has been reached, and if not, the process returns to step 60.
If yes, proceed to step 63.

In step 63, the contents of the transmission buffer are transferred to the processing device 5, and in step 64, the history code F is transferred to R, 0M4.
The data is stored in the read area 41 from the beginning.

Next, in step 65, a termination information report is performed, and termination (E
ND).

Furthermore, by using a history code that is stored every time a process of the input/output control device is executed, a trap function similar to an address stop can also be provided at all positions where the history code is set. 9) Wrap function will be explained below with reference to FIGS. 7 and 10. FIG. 7 details step 44 of FIG. The contents of steps 51 and 52 in FIG. 7 indicate 38 and 39 of the table 36 in FIG. 5, and must be written in advance by the DCW in FIG. 8B issued by the processing device 5. When this DCW is issued to the input/output control device, the trap detection request setting program 21 shown in FIG.
The processing flowchart shown in FIG. 0 is executed. Incidentally, steps 66 and 70 for reading and storing history codes G and H are added to check the program shown in FIG. 10. 10th
In the figure, in step 67, the memory write stop flag area 37 of FIG. 5 is unconditionally cleared, and the write stop is forcibly canceled (regardless of whether the stop flag is set or not). In step 68, the contents of the DCW additional information 56 shown in FIG. 8B are stored in the trap request flag area 38 (the trap request can be either valid or invalid, but here it is assumed to be valid). Next, in step 69, the trap code of the DCW additional information 57 (when the history code is 1 byte, the code is 100 to /FF) is stored in the trap code storage IJ area 39, and the operation is ended. In this process as well, the above-described history code processing is executed in steps 66 and 70. When the trap request flag and trap code are set as shown in FIG. 1O, the process shown in FIG. 7 is always performed before writing the history code in step 45 in FIG.

In FIG. 7, in step 72, it is determined whether or not to stop writing the history code to the memory, and if it is stopped, the program returns to the main program without writing the history code. If invalid, proceed to the next step. When there is a trap request in step 51, in step 52, the history code set in advance in the trap code storage area 39 and step 42 in FIG.
The history code is compared with the history code read in step 53, and if they match, the memory write stop 7 lag 37 is unconditionally enabled in step 53, and subsequent storage of the history code in the memory area is prohibited. In order to resume storing the history code, it is necessary to turn on the power to the input/output control device again and execute the process shown in FIG. 10.

Further, the state of stopping writing of the history code in step 53 is reported to the processing device 5 as end information together with information on input/output errors, etc. in step 33 of the processing program shown in FIG. 4 that uses the history code. This report is performed by specifying the number of information input from the input/output device 1 using the DCW FUNCTION.

In the embodiment, a history code is added to all programs related to DCW. This made it possible to see the history of all movements of the input/output control device.

Of course, it is also possible to select an important program and have the history code set in this program with priority. Furthermore,
Although the history code is stored in the memory 4, it may also be stored in the memory 6.

〔Effect of the invention〕

As is clear from the above embodiments, according to the present invention, all operations within the input/output control device can be performed by setting a history code that matches the function of the device. The code is stored in a readable and writable memory, and the contents can be read and confirmed by the DCW from the processing unit when necessary or in the event of a failure. without affecting the
It becomes possible to input information necessary for troubleshooting and debugging. In particular, the trap function that can be set in a simple way from the processing device in combination with the history code has the effect of being the most effective means of analyzing soft timeout errors and fault isolation in the field where termination information is not reported. be.

[Brief explanation of drawings]

Fig. 1 is a hardware configuration diagram of an input/output control device for implementing the present invention, Fig. 2 is an explanatory diagram of DCW, Fig. 3 is a configuration diagram of the entire program of the input/output control device, and Fig. 4 is a diagram of the main program. A data processing program flowchart showing an embodiment of the history code of the invention, FIG. 5 is a table configuration diagram consisting of a history code storage area and a trap check area,
FIG. 6 is a flowchart showing an example of history code setting, FIG. 7 is a 7-flow chart showing an example of trap check, and FIG. 8A is a DCW explanatory diagram when reading memory.
FIG. 8B is a DCW explanation for setting a trap detection request,
FIG. 9 is a flowchart showing an embodiment of memory read processing, and FIG. 10 is a flowchart showing an embodiment of trap code setting processing. DESCRIPTION OF SYMBOLS 1... Input/output control device, 2... Microcomputer, 3... Control circuit, 4... Control ROM, 5...
・Processing device, 6...RAM, 8...I/O device, 9
...Input/output data, 15...FU□NcTION,
16... Additional information, 25... FUNCTION processing unit, 36... Memory table, 37... Memory write stop flag table, 38... Trap request flag table, 39... Trap code storage table , 40
...History code writing address storage table, 41...
- History code storage area. Agent Patent Attorney Masami Akimoto I Meme 2 Zume 3 Mouth 4 - Figure 5 Figure 6 '$ t Mouth Kaya 7 Go to Figure 46 $ 8 Mouth (c) (8) 17 Figure Kaya 10 □211 -L 1 animal - 1□22D 7g≦, 7/

Claims (1)

[Scope of Claims] 1. An input/output control device that is interposed between a processing device and an input/output device and performs input/output control, which stores a program and has a history of the operation route of any program. A first memory that stores a program that has a step for reading code, a second memory that is readable and writable for storing data, etc., and receives device control information (DCW) from the processing device. The program in the first memory is read and executed each time, and if there is a history code read out during the execution process, the history code is stored in the second memory as diagnostic data for the program processing process. An input/output control device with a stored processing section and extensive diagnostic functions. 2. In an input/output control device that is interposed between a processing device and an input/output device and performs input/output control, a program is stored therein, and a step of reading a history code is added to the operation route of any program. a first memory that stores a program to be executed and a program that has a trap request process in the operation route of the program or any other program; a second memory that stores data, etc.; and a second memory that stores data and the like; Each time device control information (DCW) is received from the device, the program in the first memory is read and executed, and if there is a history code read out during the execution process, the history code is used to diagnose the program process. In addition, if the trap request processing is read out during the execution process, the first
a processing unit that checks whether or not the history code read into the memory of the trap matches the trap code requested in the trap request processing, and stops writing subsequent history codes only when they match; input/output control device. 3. The trap request processing in the program having the trap request processing to be stored in the first memory is an input according to claim 2, wherein the trap request processing is stored at the time of the trap request based on the device control information from the processing device. Output control device.