JPS62271152A - Testing method for hardware with rom - Google Patents

Abstract

PURPOSE:To easily conduct the test without replacing a ROM and requiring any special device by adopting a ROM for a processor module to be tested in the hardware test having a ROM only for the common software and for the operating software and test software and applying IPL (initialize program load) the test software into the said module at the test. CONSTITUTION:A ROM is used fro the IPL loader being a common function for the operating software and the test software in a processor module to be tested and the operating system only, and the remaining software is stored in a battery backup memory in the system. In conducting the test, the stored test software is subject to IPL to a tested processor module by the IPL loader being a part of the software in the ROM and a test personnel starts the system from a console, then a test scheduler reads a test scenario sequentially to execute the test program.

Description

Detailed Description of the Invention 3. Detailed Description of the Invention [Field of Industrial Application] The present invention relates to a method for testing ROM-mounted hardware of a processor module having a ROM.

[Conventional technology]

Normally, when creating test software for a microprocessor module and performing a hardware test, the operating software in the module must be replaced with the test software. If the operating software is stored in ROM, a method for conducting hardware tests without replacing the ROM is as follows:
For example, there is a method using a microcomputer development support device shown in FIG.

In the figure, 24 is a microcomputer support device;
5 is the main part that controls the entire device, and 26 is the probe 2 for the target flosser connected to the user system.
The emulator section 26 is an emulator section that performs the control of No. 7, tracing during execution of the HY processor, and emulation of the memory and I10 port.The emulator section 26 is provided with a memory for emulation. As the software of the device, the main unit 25 stores an operating system and a debug monitor. The debug monitor includes commands for simple checks of memory and Ilo, and has debug commands and auxiliary commands used for control in debug programs created using the debug commands. . Furthermore, the debug program can control the execution of programs created by users. 28 is a FROM programmer, 29 is a keyboard, 30 is a CRT display, 31
is a floppy disk.

Next, the operation will be explained. First, step 3 in Figure 7
Create a test program in step 2 and register it as a user program. Next, in step 33, a debug program is created. As explained later, this debug program calls the user program and builds a program to execute it. By activating the debug program in step 34, a test according to the test program is executed in step 35.

Figure 8 shows the debug file created in step 33 of Figure 7.
It is a flowchart showing an example of a program. 8th
Each step from step 36 to step 43 in the figure is
It corresponds to each debug command written in the debug program. First, after displaying a message announcing the test in step 36, various preprocessing is performed in steps 37 to 40, and then in step 41, the ROM9 area of the memory of the processor module to be tested is transferred to microcomputer development support. Allocate to device emulation memory. Thereafter, in step 42, the test program, which is the user program, is loaded into the area allocated to the emulation memory, and in step 43, the test program is executed.

[Problem that the invention seeks to solve]

Conventionally, the testing method for ROM-mounted hardware has been carried out as described above, so that the test software can be stored in the relevant module and a hardware test can be performed without replacing the ROM of the processor module under test. )L requires a processor development support device, and it takes time to connect the device and module during testing.
In addition to diminishing the advantage of not having to replace the OM, there were also other problems, such as the fact that K, which tests multiple processor modules under test in parallel, required paying for expensive equipment.

This invention was made to solve the above-mentioned problems, and it is possible to easily load test software into a processor module under test and start the test software during hardware testing. An object of the present invention is to provide a method for testing ROM-mounted hardware that can automatically perform a hardware test without connecting a special device or replacing the ROM.

[Means for solving problems]

The ROM-mounted hardware testing method according to the present invention is based on IPL, which is a shared function of operational software and test software in the processor module under test.
(In1tialize Program Load
) Only the software and operating system parts are stored in ROM, and the remaining software parts are stored in the system's battery-backed memory.

In addition, regarding the test software, there is a test scenario that describes the test program such as memory check, commands and parameters, and the selection of the test program and its execution control, and the test scenario that describes the selection of the test program and its execution control. It consists of a test scheduler that starts test programs.

[For production]

In the ROM-mounted hardware testing method of the present invention, during testing, the test software stored in the memory with battery backup is loaded onto the processor under test using an IPL loader that is part of the software in the ROM area.
After IPLing the module, the tester then starts up the console, and the test scheduler sequentially reads out the test scenarios and executes the test program. During operation, the operating software stored in the battery-backed memory is IPLed to the corresponding processor module.

〔Example〕

An embodiment of the present invention will be described below with reference to the drawings. First, FIG. 1 is a configuration diagram of a processor module under test that performs a hardware test.

In the figure, the processor under test module (pROC)
)l has a memory unit with battery backup (
MMU) 2 and examiner's console (C8) 3 are connected. Processor module under test (PROC) 1
Inside, there is a CPU 1a and R as resident memory.
There is OM1b and RAM1c. The ROM 1b stores an initial [phase] program loader 4 and an operating system 5, which are shared software for operation software and test software. Also, 几AM
Of the test software, a test scheduler 6 and a test program 7 are stored in 1c.

In the memory unit (MMU) 2, among the test software, a test scenario 8, an original record of the previous test scheduler 6, and an original record of the test program 7 are placed.

FIG. 2 shows the configuration of the test program 7 shown in FIG. As shown in the figure, it is a collection of test routines that are independent modules in the form of test commands such as memory read 9a+memory◆write 9b. Standard test commands 9 are prepared in advance that are likely to be used frequently during testing, and in addition to these, extended test commands 10 can be created and added as necessary for testing.

FIG. 3 shows the form of test scenario 8 in FIG. 1. Test scenario 8 is a chronological arrangement of scenario 11. The 11th format of the scenario is
First, select test commands 9 and 10 that make up test program 7 in Figure 2 as test commands, % 11 a
flag 11b1 for test execution control; error code 11C used as a scenario identification code when notifying test results; repeat count 11d indicating the number of repetitions of the scenario; and test command waste 11a.
Specify the parameter size 11e, parameter data 11f, etc. regarding the test command selected in step.

Next, the operation of the above embodiment will be explained with reference to FIGS. 4 and 5. First, the steps for performing hardware testing are explained in step 4.
As shown in the figure. First, in step 12, a test scenario that meets the purpose of the test is created.

In step 13, the test software consisting of the test scenario, test scheduler, and test program thus prepared is stored in the battery-backed memory unit (MMU) 2 shown in FIG. Thereafter, in step 14 of FIG. 4, the test scheduler 6 and test program 7 are transferred to the AM 1c of the processor module under test (PROC) 1 using the initial program loader 4 of the shared software in the ROM 1b of FIG. do.

As a result of this operation, the test software is placed as shown in FIG. Therefore, the test can be executed at step 15 in FIG. If returning to operational status, step 16. The operational software is stored in a memory unit (M
In step 17, the operating software is IPLed onto the RAM of the processor module (PROC) in the same way as the test software. Thereafter, in step 18, this operational software is started.

Next, regarding the execution of the test in step 15, an execution flowchart is shown in FIG. 5, focusing on the process flow of the test scheduler 6 in FIG. 1. In step 19, the test scheduler starts operating by inputting a start command to the console. The test scheduler first refers to the test scenarios in the memory unit (MMU) in step 20 and sequentially searches for scenarios. A predetermined test command is executed in accordance with the instructions of the searched scenario in the next step 21, and the progress of the test is displayed on the console in step 22 as necessary. Repeat steps 20 to 22 above for each scenario, and when the scenario is finished, step 2
Step 3 displays the test result pass/fail notification on the console.

In the above embodiment, the test software is a memory unit with battery backup (MMU) 2 shown in FIG.
I have shown what is stored in this, but instead of this it is 70 tsupi.
It may also be stored in an auxiliary storage device such as a disk.

Further, in the above embodiment, the case of a processor module unit test has been described, but the present invention can also be applied to a case of a combination test in a multi-processor system.

〔Effect of the invention〕

As described above, according to the present invention, the ROM of a processor module under test in a hardware test having a ROM
Since the software is only shared between the operational software and the test software, and the test software is IPL'ed into the corresponding module during the test, there is no need to replace the ROM and no special equipment is required. can be easily tested. In addition, by creating a test scenario in advance as part of the test software, the test scheduler automatically starts test commands according to the test scenario, making it possible to perform routine tests. effective.

[Brief explanation of drawings]

Fig. 1 is a block diagram of a processor module under test in a hardware test according to an embodiment of the present invention, Fig. 2 is a block diagram of a test program, Fig. 3 is a block diagram of a test scenario, and Fig. 4 is a test procedure. 5 is a test execution flowchart mainly explaining control by the test scheduler, FIG. 6 is a block diagram of a conventional microcomputer development support device used for hardware testing of processor modules, and FIG. FIG. 8 is a flowchart of a test procedure regarding a test method using the apparatus, and is a diagram showing an example of a 70-chart of a debug program. In the figure, 1 is the processor under test φ module, 1b
is ROM, Ic is RAM, 4 is initial program loader, 5 is operating/patent applicant Mitsubishi Electric Corporation 9: Temperature test F command Figure 6 Figure 8 σ Power procedural amendment (voluntary)

Claims (2)

[Claims] (1) Microprocessor and ROM connected to the microprocessor and RAM with battery backup
In the ROM-mounted hardware testing method for testing a processor module under test having the RO
The initial program loader and operating system of the shared software part of the operational software and test software are stored in the ROM in the processor module under test that tests the M-implemented hardware;
When testing the hardware, the test program is initially loaded into the RAM in the processor module under test from a memory unit with battery backup that stores the test program in advance, and the ROM is replaced. 1. A method for testing ROM-mounted hardware, characterized in that a hardware test is executed without any problems. (2) A test scheduler for the processor module under test refers to a test scenario created in accordance with the test purpose and controls the execution of a test program that is initially loaded from the battery-backed memory unit. 2. A method for testing ROM-mounted hardware according to claim 1, wherein the ROM-equipped hardware is automatically tested.