JPH04167139A - Program down loading system - Google Patents

Abstract

PURPOSE:To exchange the programs with no exchange of ROMs and no discontinuation of the system operation by down loading a program to a memory from the outside of a software system. CONSTITUTION:The memory contents of programs of two systems are stored in the memories EEPROM 1 and 2 respectively, and a fact whether its own system is equal to a program of a working system, or to an old program, to a new program, or to an abnormal NG state of the program data is held as a state flag. Thus a program is inputted from the outside of a software system and down loaded. Then the program is stored in a memory of a system except the working system and the self-restart is carried out with the stored program defined as a new working system. In such a constitution, it is not required to stop the operation of a new ROM storing a new program and to exchange this ROM with another. Thus the operability is improved in a program down loading system.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a program download method for inputting and executing a program from the outside into a software system.

[Conventional technology]

In conventional software systems, firmware, which is software built into devices, is an RO that cannot be rewritten.
It is mounted in the device in the form of M.

[Problem to be solved by the invention]

However, if it is necessary to change the program such as purge pin-up of the program due to user request or modification of the program due to an internal failure, a new ROM containing the new program is created and the device is stopped. It is necessary to replace the ROM. Furthermore, if the program is large-scale, it is divided into many ROMs, and therefore many ROMs need to be replaced in the same way. moreover,
When a software system has a large number of processors (CPUs) distributed, the R
There is a problem that OM replacement work is required.

[Means to solve the problem]

The program download method of the present invention includes two systems of nonvolatile memory capable of storing programs, downloads the program by inputting the program from outside the software system equipped with the memory, and transfers the program to a software system that is not currently in use. It is configured to save the program in memory and self-restart using the saved program as a new active system.

Further, the program download method of the present invention includes a plurality of processors for performing distributed processing, performs program download by inputting a program to the processor from outside a software system including the processor, and downloads the program into the system. The program is stored in an auxiliary storage device, and the stored program is transferred to the processor.

〔Example〕 Next, the present invention will be explained with reference to the drawings.

Referring to FIG. 1 showing the processing procedure in an embodiment of the first invention, program download (PD) is performed from outside the software system via a communication line etc. during normal processing.
When there is a request (step 11) of L), PDL processing (step 12) is executed. In PDL processing, program data from the outside is stored in a memory that is not currently in use.

Here, the format of the program data to be downloaded is arbitrary, but for example, a format including a checksum in Intel HEX format can be applied. When all program downloads are completed, a self-check (step 13) is performed to confirm whether the saved programs are correct as data. If the result of the self-check is abnormal (NG), notify the outside that the PDL is NG, and update the status flag (step 14) to update the status flag on the memory of the program downloaded.
(described in detail later) to "NG" and returns to normal processing. Also, if the result of the self-check is normal (OK), the status flag is updated to "new". After that, the self-restart After starting up (step 15), self-resetting (
Perform step 16). Here, steps 12, 13.
Since the process No. 14 can be performed in parallel with the normal process using the free time of the normal process, the program download can be executed without stopping the normal process. However, in order to execute the new program, it is necessary to first stop the execution of the old (currently used) program and restart it using the new program as the current program. Self-restart is a process that waits for an opportunity to safely stop the execution of the old program. The conditions for determining whether or not self-resetting is possible depend on each software system and will not be described here, but the following conditions may be considered, for example. In other words, the database is not in the process of updating, and the command/response sequence with the external system is not in progress. After self-resetting, a reset is performed (step 17), and a program startup process (step 18) is executed.

Although this startup process differs depending on the program storage method, a case will be described here in which the method shown in FIG. 2(A) is adopted. In this system, the two systems of program memory use exactly the same rewritable ROM 1, for example, EEFROM. Each memory (EEP
ROMI.

2) Inside, there is a status flag for the own system, which holds whether it is an active program, an old program, a new program that has been downloaded, and whether it is in an NG state with an abnormality in the program data. are doing. In the startup process, the contents of the status flags of these two systems are compared and determined to determine which system's program should be used.

The conditions for this determination are shown in FIG. As a general rule, new programs should be used with priority given to EEPROM1 systems to avoid NGs. In addition, the startup process sets the status flag of the system to be used to "active", and updates the status flag of the other system if necessary. Execution of the downloaded program starts as described above, and normal processing (step 19) starts. FIG. 1 shows an example of changes in the memory status flags of the two systems. If necessary, it is also possible to back up the current system by preparing a copy command from the current system to the other system.

FIG. 5 shows an example of a memory map of program data arranged on the memory. Memory is storage area 211-27
1 EEPROM section and storage areas 281 to 291 ROM
Divided into sections. In addition to this, there is of course a RAM section, etc., but their illustration is omitted. Areas 211 to 251 are data sections that can be rewritten by downloading. Usually, the program being changed is an application program, so area 2
The main changes are 31. However, since the program size is changed due to the change in area 231, the final address (area 212) and CRC (area 251) must also be updated. The check performed in the self-check process (step 13 in FIG. 1) is based on the start address (area 211
) to which the calculated value of the CRC for the address range indicated by the final address (area 212) has been sent by download.
This is done depending on whether it matches the RC (area 251). This makes it possible to detect errors even if the content becomes abnormal during downloading. In addition, the first address.

Regarding the final address, CRC, and status flag placement,
It needs to be decided in advance. In this example, the first address of the EEPROM, then the final address, the address indicated by the final address, the CRC, and the EEPROM.
A status flag is placed at the end of M. Also, depending on the software system, there may be cases where the data to be downloaded cannot be placed in a continuous address.
In that case, several pairs of starting and ending addresses.

This can be dealt with by preparing a CRC.

The explanation above assumes that there are no problems with each process and that the program runs normally, but in reality there is a possibility that there is an inherent bug in the downloaded program, and the program download process itself described above will not work. . In this case, you will not be able to download the program again, so some kind of countermeasure is required. Therefore, considering the worst case, forced PD as shown in Figure 6 is applied.
It should be possible to implement the L process (steps 51-56). In normal PDL, download processing is performed using free space in normal processing, but in this forced PDL, normal processing is stopped from the beginning (step 52), and the downloaded current program is not run at all. . Therefore, processing for normal PDL self-restart (step 15 in FIG. 1) is not necessary. The program executed in the forced PDL is a ROM portion of the memory shown in FIG. 5 that cannot be rewritten, including storage areas 281 to 291. Therefore, it is possible to operate without depending on the downloaded program.

Naturally, it is assumed that the program to be stored in ROM always works (without any fatal bugs).

The method shown in FIG. 2(A) has been explained above.
The method shown in FIG. 2(B) may also be considered as a method for realizing the system memory. In this method, if an auxiliary storage device such as a hard disk exists in the system, similar processing can be performed by using it. For systems that already include a hard disk, the latter method is advantageous in terms of storage capacity.

Next, the second invention will be explained.

Referring to FIG. 7 showing the system configuration of an embodiment of the second invention, the host system 100 includes a main device control unit (MEC).
) 110, auxiliary storage device (HD) 120, and HD 12
HD control unit (HDC) 121 that controls 0, main communication control unit (MCOM) 130 and dedicated communication unit (SCOM) 131 with lower system, and MC0M1 with external system.
40 and SC0M141. Furthermore, the lower system 150 includes an MC0M 180 and a SCOM 161 for communication with the upper system 100.

Furthermore, the external system (EXT) 170 inputs a program to the host system 100 in the form of a floppy disk 171, for example. Here, codes 110, 121
, 130, 131, 140, 141, 160, and 161 are distributed processors (CPUs), and all require programs. Note that in reality, in many cases, a plurality of the same lower systems 150 are connected, and there are many elements indicated by 130, 13L 1B0.181, but they are omitted here.

In this configuration, the CPU that plays a central role in control is the MECI
IO, and the processing procedure after the MECIIO power is turned on is shown in FIG. Further, FIG. 9 shows the processing procedure after power-on of the CPUs other than the MEC 110. each CPU
Immediately after turning on the power, the computer first checks whether it is holding the program correctly (step 802.92).

As a method of confirmation, for example, a checksum of the program is stored in advance, and it can be determined whether it is correct or not.

If your program is correct, it will stand up (step 803.93) and proceed to normal processing (step 804.
94). On the other hand, if your program is not correct, you need to load it. There are two possible ways to load the program: That is, (1) if a program is stored in the HD 120 in the system, load it. (2) If the above (1) is not possible, have the program downloaded from the EXT 170 of the external system. However, with (2) above, the downloaded program remains only in the corresponding CPU in the system and cannot be reused, so the following is done. In other words, (3) If (1) above is not possible, download the program from the external system EXT170, save it to the HD120, and (1)
Execute (1) in a state where it is possible. As a result, the necessary programs in the system are downloaded and saved on the HD 120, and then the necessary programs are saved on the HD 120 as necessary.
Uploaded from 20.

The MECIIO processing shown in FIG.
If the corresponding program is present on the HD 120 in response to a program upload (PUL) request (step 805) from the HD 120 (step 806), it is sufficient to perform a PULL from the HD 120 (step 807) and check again in step 802.

If there is no program in step 806, EXT170
A program download (PDL) request is made to (step 808), and as a result of (3) above, the program is
D120 (step 809), and then HD1
PUL is possible from 20 onwards. The PDL and PUL of the MECIIO program have been described above, but the process is similar for other programs (step 810).
~816). The only difference is EXT170 and HD120
This means that communication processing with MECIIO is performed via MECIIO. If each CPU other than MECIIO does not hold a program, it sends a PDL request (FIG. 9, step 95) to MECIIO (step 810), and MECIIO determines that the corresponding program is on the HD12.
EXT1 (steps 811, 812)
From 70, it is controlled whether to request PDL (step 815), etc. As mentioned above, the download of this invention is
Since the download process is performed in two stages centered on , it can be said to be a hierarchical download process.

In order to implement the above-mentioned processing for loading programs, each CPU must (1) hold the minimum programs necessary for PDL and PUL processing as ROM, and (2) turn on the power. It must be created in advance so that (1) will operate automatically later. The loaded program is a so-called application program, and the basic program for realizing PDL and PUL is required separately as a ROM. PDL, PUL
The programs required as ROM for this purpose are as follows.

(1) ME C: PUL processing from HD PDL request processing to EXT PDL processing to other CPUs Program saving processing to HD Self program check (2) HDC: Writing programs to HD Reading programs from HD To MEC PDL request own program check (3) MCOM: PDL request request date program check to MEC) SCOM: PDL request request date program check to MBC) EXT: PDL processing to MEC and transmission/reception processing between each is required. It is.

The above explanation is about the operation when the program is lost, but the process when changing the program from the EXT 170 can be similarly realized, and the process procedure is shown in FIG.

During normal processing by MECIIO (step 1001), E
When a PDL command is received from the XT170 (step 1
002), PDLL from EXT170 (Step 10
03), save it to the HD 120, step 1004), and send the PDL command to the corresponding CPU (step 10).
05). CPUs other than MEC use PDL from MECIIO.
Upon receiving the command (step 1012), a PDL request is sent to MECIIO (step 1013), and PDL processing via the MEC (steps 1006 and 1014) is executed. The programs that need to be added to the ROM for this process are as follows.

(1) MEC: Other CPU that receives PDL commands from EXT
(2) Other CPU: Receive PDL command from MEC (3) E
XT: PDL command to MEC It doesn't matter what memory is used for each CPU, but MECIIO, which controls the whole thing, uses EEPROM, and other than MEC, if it is necessary to withstand some power outages, it uses batteries. Backup RAM is appropriate.

〔Effect of the invention〕

As explained above, according to the first invention, it is possible to download a program to the memory from outside the software system, so there is no need to replace the ROM.
Moreover, programs can be exchanged without stopping the system.

Further, according to the second invention, since the program can be downloaded from outside the software system to all distributed processors inside the system,
Without replacing the ROM of each processor,
Can modify and update programs.

[Brief explanation of the drawing]

FIG. 1 is a diagram showing the basic processing procedure of one embodiment of the first invention, FIG. 2 is a diagram showing an example of the configuration of two systems of memory in the same embodiment, and FIGS. 3 and 4 are the same embodiment. FIG. 5 is a diagram showing the memory map in the same embodiment. FIG. 6 is a diagram showing the basic processing procedure of forced PDL in the same embodiment. FIG. 7 is an example of an implementation of the second invention. A diagram showing the system configuration in an example, FIG. 8 is the ME in FIG.
FIG. 9 is a diagram showing the processing procedure when CPUs other than MEC in FIG. 7 start up; FIG. 10 is a diagram showing the processing procedure for program loading during normal processing. It is.

Claims (1)

[Scope of Claims] 1. Two systems of non-volatile memory capable of storing programs are provided, the program is input from outside the software system equipped with the memory, the program is downloaded, and the program is downloaded from the software system that is not currently in use. A program download method characterized in that the program is saved in a memory and self-restarts using the saved program as a new active system. 2. A software system comprising a plurality of processors for performing distributed processing, inputting a program to the processor from outside the software system including the processor, downloading the program, and storing the program in an auxiliary storage device within the system; A program download method characterized in that the stored program is transferred to the processor.