JP2016099937A - Method for back-up activation processing - Google Patents

Abstract

PROBLEM TO BE SOLVED: To activate a program with a back-up program if an abnormality is in an activation program storing region after update of programs.SOLUTION: A program region for storing a program-updating program is set in a first program region and a second program region. The updating program is written into the first program region and a checksum is stored into an update management region, while the updating program is written into the second program region and a checksum is stored into an update management region. A boot program is used for calculating a checksum in processing of a normal activation program. The obtained checksum and the checksum stored in each of the update management regions are compared. If the obtained checksum is not the same as the checksum stored in one of the update management regions, activation is done using the update program stored in the other update management region.SELECTED DRAWING: Figure 5

Description

  Embodiments described herein relate generally to a backup activation processing method.

  If the power supply is interrupted while updating the program, writing will fail and it will not be possible to start again. In order to avoid this, a method of writing a backup program in the Flash ROM is generally adopted.

  Such a conventional method is effective when writing cannot be completed to the end due to an abnormality such as a momentary power interruption during program update.

  However, if the program area of the Flash ROM is damaged due to static electricity or the like after writing, the backup program is not effective and cannot be started again.

  Normally, when the activation program area is damaged, the boot process cannot detect the corruption of the program area and executes the activation program and may run away.

JP 2008-40924 A

  The problem to be solved by the present invention is to provide a backup activation processing method that makes it possible to utilize a backup program even if there is an abnormality in the activation program storage area after updating the program.

  The backup activation processing method according to the embodiment includes a step of setting a program area for storing an update program in a first program area and a second program area, and the update program is stored in the first program area. A step of storing a checksum for the first program area in the update management area of the first program area at the time of writing, and a second program at the time of writing the update program in the second program area A step of storing the area checksum in the update management area of the second program area, and a step of calculating a checksum at the time of normal boot program processing by the boot program. Checksum and before storing in each update management area When the comparison result for the checksum stored in one of the update management areas is inconsistent with the step of comparing the checksum, the update program stored in the other update management area is activated. Steps.

It is a figure which shows the example of arrangement | positioning of Flash ROM after the checksum storage of each area | region of a program. It is a figure which shows the example of arrangement | positioning of Flash ROM after the checksum calculation of the starting program (in the case of A surface) at the time of booting. It is a figure which shows the example of arrangement | positioning of Flash ROM showing a comparison with the checksum calculated in the update management area | region (in the case of A surface). It is a flowchart which shows the flow of an update process (in the case of A surface). It is a flowchart which shows the flow of a boot process.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In the drawings, the same portions are denoted by the same reference numerals, and redundant description is omitted.

  In this embodiment, a checksum is used to check whether there is an abnormality in the normal program area at the time of activation, and a backup program is activated if there is an abnormality.

  FIG. 1 is a diagram illustrating an arrangement example of the Flash ROM after storing the checksum of each program area. As shown in FIG. 1, when writing a program, the checksum for A side and the checksum for B side are stored in the management area of each side corresponding to the program area: A side and the program area: B side. Keep it. Program areas for storing program update programs are set in a first program area: A side and a second program area: B side. For example, the update program written on the program area A side and the update program written on the program area B side may be the same version. Alternatively, the update program to be written on the program area A side may be a version before the update program to be written on the program area B side. As will be described later, the version management is preferably performed by the number of updates to the update management area.

  FIG. 2 is a diagram illustrating an arrangement example of the Flash ROM after the checksum calculation of the startup program (in the case of the A side) at the time of booting. As shown in FIG. 2, the boot program calculates the checksum of the startup program.

  FIG. 3 is a diagram showing an arrangement example of the Flash ROM that represents a comparison between the calculated checksum and the checksum in the update management area (in the case of A side). As shown in FIG. 3, a checksum match is confirmed.

<Update process>
FIG. 4 is a flowchart showing the flow of the update process of the program area A surface.

  First, update data is acquired (step S401).

  Next, checksum data is acquired (step S402).

  Subsequently, a checksum is calculated from the update data (step S403).

  Next, it is determined whether or not the calculated checksum is equal to the checksum data (step S404).

  If they are equal (Yes in step S404), the program area on side A is rewritten (step S405).

  Next, the checksum is stored in the management area of side A (step S406).

  Subsequently, the A-side update management area is rewritten (step S407).

  Next, after resetting the software (step S408), the process proceeds to boot processing.

  On the other hand, if No in step S404 (the calculated checksum and the checksum data are not equal), the update process is terminated.

  The same processing is performed on the program area B surface.

<Boot process>
Next, the boot process will be described. FIG. 5 is a flowchart showing the flow of the boot process.

  First, the update management area on side A is confirmed (step S501).

  Next, the A-side checksum stored at the time of update is acquired from the management area (step S502).

  Subsequently, the B side update management area is confirmed (step S503).

  Next, the B-side checksum stored at the time of update is acquired from the management area (step S504).

  Next, it is determined whether or not the number of updates on side A is greater than the number of updates on side B (step S505).

  If the number of updates on side A is greater than the number of updates on side B (Yes in step S505), side A is set as the startup program area (step S506).

  Subsequently, the checksum of the A surface is calculated (step S507).

  Next, it is determined whether or not the acquired A-side checksum is equal to the calculated A-side checksum (step S508).

  If they are equal (Yes in step S508), the process jumps to the top of the startup program area.

  On the other hand, if they are not equal (No in step S508), the checksum of side B is calculated (step S509).

  Subsequently, it is determined whether or not the acquired B-side checksum is equal to the calculated B-side checksum (step S510).

  If they are equal (Yes in step S510), the process jumps to the top of the startup program area.

  On the other hand, if they are not equal (No in step S510), a boot error occurs.

  If the number of updates on side A is not greater than the number of updates on side B (No in step S505), side B is set as the activation program area (step S511).

  Subsequently, a checksum of the B surface is calculated (step S512).

  Next, it is determined whether or not the acquired B-side checksum is equal to the calculated B-side checksum (step S513).

  If they are equal (Yes in step S513), the process jumps to the top of the startup program area.

  On the other hand, if they are not equal (No in step S513), the checksum of the A side is calculated (step S514).

  Subsequently, it is determined whether or not the acquired A-side checksum is equal to the calculated A-side checksum (step S515).

  If they are equal (Yes in step S515), the process jumps to the top of the startup program area.

  On the other hand, if they are not equal (No in step S515), a boot error occurs.

  According to the present embodiment, the backup program can be used as the startup program even if there is an abnormality in the startup program storage area after the update.

  Although several embodiments of the present invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

Claims (4)

Setting program areas for storing program update programs in a first program area and a second program area;
Storing the first program area checksum in the update management area of the first program area when the update program is written to the first program area;
Storing the second program area checksum in the update management area of the second program area when the update program is written to the second program area;
In the boot program, calculating a checksum during normal startup program processing;
Comparing the checksum obtained by calculation with the checksum stored in each of the update management areas;
A backup activation processing method comprising: a step of using the update program stored in the other update management area when the comparison result for the checksum stored in the one update management area does not match.   2. The backup activation processing method according to claim 1, wherein the update program written in the first program area and the update program written in the second program area are the same version.   2. The backup activation processing method according to claim 1, wherein the update program to be written to the first program area is a version previous to the update program to be written to the second program area.   The backup activation processing method according to claim 2 or 3, wherein the version is managed by the number of updates stored in the update management area.

Images