JP2012146234A - Control device, and firmware update method and program thereof - Google Patents

Abstract

PROBLEM TO BE SOLVED: To avoid occurrence of trouble due to update of firmware when the firmware in operation is switched to new updated firmware.SOLUTION: When operation firmware 211 in use which is running in a core 1 is updated into new updated firmware 221, a core 2 where the operation firmware 211 is not running is selected, and the updated firmware 221 and a test program 222 are loaded in an occupation memory area (memory 220 for the core 2) of the core 2. Then the core 2 checks whether the updated firmware 221 operates normally by executing the test program 222 for the updated firmware 221. After it is determined by the check that the updated firmware operates normally, the core 2 operates the updated firmware 221, and then switches a process request to the firmware from the core 1 to the core 2 to process the request.

Description

  The present invention relates to a control apparatus, a firmware update method, and a program thereof that can avoid occurrence of a failure such as a system stop due to the firmware update when updating the firmware without stopping the system.

  Firmware that is software for performing basic control of hardware mounted on the control device is incorporated in the control device (for example, a server device). In this control device, the operation and function are affected by the firmware. Therefore, when a firmware upgrade or the like is performed, it is necessary to always update the firmware to a new version.

By the way, the following technologies are disclosed as technologies related to firmware update.
For example, there is a related control device (see Patent Document 1). The control device described in Patent Document 1 is intended to realize firmware active replacement of a control device such as a disk control device that has little influence on a host that is a host device. For this reason, in the control device described in Patent Document 1, when the firmware is operated on two CPUs and firmware update is performed on one of the two CPUs, the I / O processing request is transferred to the opposite CPU, and the firmware update is performed. The process is returned later.

  There is also a related control program update method (see Patent Document 2). An object of the control program update method described in Patent Document 2 is to provide a control program update method that does not require downloading a control program again even if a radio base station has unexpectedly restarted a device. For this purpose, two storage means for storing the downloaded control program are provided, the new control program downloaded is written in the standby storage means, and the old control program in the active storage means is activated when the apparatus is restarted before operation. When the apparatus is restarted at the start of operation or after the start of operation, the new control program in the new active storage unit that was once the standby storage unit is operated.

  There is also a related private branch exchange device (see Patent Document 3). An object of the private branch exchange apparatus described in Patent Document 3 is to provide a program update method in a private branch exchange capable of updating programs regardless of the operation status of the private branch exchange. For this purpose, the exchange control unit of the control unit defines two planes, a program area Aa1 and a program area Ba2, and switches the program area of the two planes under the control of the system monitoring unit. The program is updated without duplication and without stopping the system.

Japanese Patent No. 4456084 JP 2000-89939 A JP 2002-44238 A

  By the way, in a control device of single hardware (meaning that a plurality of the same control devices are not used), updating the firmware is already performed during the system operation, that is, without stopping the system.

  For example, in the control device described in Patent Document 1 described above, as shown in FIGS. 1 and 3 (FIGS. 1 and 3 of Patent Document 1), two CPUs and a pre-deployment firmware storage unit (operation firmware and new firmware) And a firmware storage area prepared for each CPU and a shared memory that can be simultaneously accessed from the two CPUs. Then, the new firmware to be updated is loaded into the firmware storage area of the CPU on one side, and the operation of switching the firmware from the operating firmware to the new firmware is performed in the CPU on this one side. Then, during the firmware switching operation in the CPU on this one side, the CPU on the other side substitutes for the I / O processing during this period, and then the CPU on one side operates the new firmware. Update firmware without interruption.

  However, in the control device described in Patent Document 1, since the firmware is switched without checking the operation of the update firmware in advance, there is a problem associated with the firmware update, such as a medium failure or a partial fraud when loading the memory. There is a problem that cannot be inspected. In addition, if a firmware error occurs on the side that is taking over the process during the update operation to the new firmware, there will be a period during which both firmware cannot operate until the update operation to the new firmware is completed. There is a problem that a time during which the control becomes impossible occurs.

  As a method for dealing with such a problem, an example in which the operation of the update firmware is confirmed in advance is shown in FIG. FIG. 10 is a diagram illustrating an example of a method of preparing two identical devices for firmware update, and is an example of preparing two identical devices 10 and 20 that are tightly coupled in hardware. In this method, one of the devices 10 is operated as the active system with the operating firmware, the other device 20 is replaced with the update firmware as the standby system, and the test is executed. Then, the active device 10 is changed to the standby device 20. Processing requests (processing requests for firmware) are transferred. However, in the case of the method of preparing two identical devices, interrupt control for different hardware (devices 10 and 20), data write completion waiting time, and the like are required, and control is impossible due to this switching operation time. Blank time will occur. For this reason, the method of preparing two identical devices has a problem that an uncontrollable time occurs when the firmware is replaced.

  Accordingly, an object of the present invention is to provide a control device, a firmware update method, and a program thereof that can solve the above-described problems.

  The present invention has been made to solve the above problems, and a control device according to the present invention includes a plurality of core processors arranged in a CPU, and an occupied memory area that each core processor occupies and uses on the memory. A second shared memory area shared by each core processor and a second core processor different from the first core processor that operates the operational firmware when the currently operated operational firmware is updated to a new update firmware Is selected, and the updated firmware is loaded into the memory area occupied by the second core processor, and it is checked that the updated firmware operates normally in the second core processor. The update firmware is operated in the core processor, and the processing request to the firmware Processing is switched to the second core processor from the first core processor, and wherein the.

In the control device of the present invention, the CPU has a multi-core configuration, and an occupied memory area and a shared memory area for each core are arranged on the memory. Then, when updating the currently operating firmware (also simply referred to as “active”) to a new updated firmware, a second core different from the first core that operates the currently operating firmware is selected. The update firmware is loaded into the memory area occupied by the second core, and it is checked (determined) that the update firmware operates normally in the second core, and then the update firmware is operated in the second core. The processing request to the firmware is processed by switching from the first core to the second core. In this way, when updating the firmware, it is checked in advance that the firmware to be updated operates normally.
As a result, when a firmware that is currently in operation is switched to a new update firmware without stopping the system in a single hardware control device, a failure such as a system stop may occur due to this update firmware. Can be avoided. For this reason, it is possible to improve the reliability when updating the firmware.

It is a figure which shows the structure of the control apparatus concerning the 1st Embodiment of this invention. 5 is a flowchart showing a flow of processing in a memory load unit 121. 4 is a flowchart showing a flow of processing in a program load unit 122. 6 is a flowchart showing a flow of processing in a test execution unit 123. 3 is a flowchart showing the operation of a core switching unit 124. 5 is a flowchart showing the operation of an interrupt mask unit 126. 5 is a flowchart showing the operation of an interrupt mask release unit 127. It is a sequence diagram for demonstrating operation | movement of 1st Embodiment. It is a sequence diagram for demonstrating operation | movement of 2nd Embodiment. It is a figure which shows the example of the method of preparing two same apparatuses for the update of firmware.

  When updating the firmware without stopping the operation of the system, the control device according to the present invention updates the medium in which the update firmware is stored, such as a defect in the medium storing the update firmware or a part of the load being invalid in the memory. It is an object of the present invention to provide a control device capable of inspecting (determining) a defect of this updated firmware in advance when there is a defect in the firmware. Thereby, when updating the firmware, it is possible to avoid a failure such as a system stop due to a problem of the updated firmware. Furthermore, when switching to the updated firmware, it is possible to reduce the time during which temporary control becomes impossible due to the firmware switching.

Embodiments of the present invention will be described below with reference to the accompanying drawings.
[First Embodiment]
FIG. 1 is a block diagram showing a configuration of a control device according to the first embodiment of the present invention, and shows only a part directly related to the present invention. A control device 100 shown in FIG. 1 is a single hardware control device (meaning that a plurality of the same control devices are not used) that operates by program control. The control device 100 includes a CPU 110 having a multi-core configuration, A CPU control unit 120 that controls the operation of the CPU 110 and a memory 200 that is a storage device that stores firmware, a test program, and the like.

  The CPU 110 has three cores: a core 1, a core 2, and a core 3. Each of these cores 1 to 3 is a CPU core (or also called a processor core) having a function of executing a program independently. With these cores 1 to 3, a plurality of programs can be executed simultaneously. In the example illustrated in FIG. 1, the core 1 is in a state (in operation) in which the core 1 is actually controlled (control to execute a processing request for firmware) by the control device 100 in a state before starting the firmware update. Yes, the core 2 is a core in a state where it does not affect the control of the control device 100 (sleeping), and the core 3 is switched to the real control when an error occurs in the real control of the control device 100. It is an example of (during standby operation).

In addition, the memory 200 has an occupied memory area that can be read / written by each of the cores 1 to 3 in the CPU 110 and an arbitrary core 1 to 3 as a storage area (the same data can be accessed from each core). ) A shared memory area is arranged.
In the example shown in FIG. 1, in the memory 200, a core 1 memory area (also simply referred to as “core 1 memory”) 210, a core 2 memory area (also simply referred to as “core 2 memory”) 220, A core 3 memory area (also simply referred to as “core 3 memory”) 230 and a shared memory area (also simply referred to as “shared memory”) 240 are arranged.

  In the state before the start of the firmware update, the operational firmware 211 is stored in the core 1 memory 210 and the operational firmware 231 is stored in the core 3 memory 230. The operation firmware 211 stored in the core 1 memory 210 and the operation firmware 231 stored in the core 3 memory 230 are the same. As will be described later, the update firmware 221 and a test program (a test program for checking the operation of the update firmware 221) 222 are stored in the core 2 memory 220 with the start of the firmware update operation.

  As described above, in the example illustrated in FIG. 1, in a state where the core 1 is a core (active system) that operates the operation firmware 211, and the core 3 is a core (standby system) that performs a standby operation of the operation firmware 211, This is an example in which the firmware is updated using the dormant core 2 (the same applies to the description of FIGS. 2 to 9).

  In addition, the CPU control unit 120 includes a memory load unit 121, a program load unit 122, a test execution unit 123, a core switching unit 124, and an interrupt switching unit 125. The interrupt switching unit 125 masks (inhibits) interrupt requests for the cores 1 to 3 and an interrupt mask release unit 127 for canceling masking of interrupt requests for the cores 1 to 3. And have.

The memory load unit 121 operates to read the update firmware and the test program into an exclusive memory (in the example illustrated in FIG. 1, the core 2 memory 220) that operates the update firmware.
FIG. 2 is a flowchart showing the flow of processing in the memory load unit 121. Referring to this flowchart, first, in response to an instruction from the CPU control unit 120, the memory load unit 121 reads update firmware from an external device (not shown), and loads the read update firmware into the memory 200 (write processing). For example, in the example shown in FIG. 1, the update firmware 221 is loaded into the core 2 memory 220 (step S11). Subsequently, the memory load unit 121 similarly reads a test program from an external device (not shown), and loads the read test program into the memory 200. For example, in the example shown in FIG. 1, the test program 222 is loaded into the core 2 memory 220 (step S12).

Next, the memory load unit 121 checks whether the update firmware and test program read operation (read from the external device and load processing to the core 2 memory 220) has been completed (step S13). (Step S13: YES), “normal end” is returned to the CPU control unit 120 (Step S14). On the other hand, when it cannot be completed (step S13: NO), “abnormal end” is returned to the CPU control unit 120 (step S15).
When “normal end” is returned from the memory load unit 121 in step S14, the CPU control unit 120 causes the program load unit 122 to select an arbitrary sleeping core, for example, the core 2 in the example illustrated in FIG. The update firmware 221 is loaded.

  FIG. 3 is a flowchart showing the flow of processing in the program load unit 122. With reference to this flowchart, for example, in the example shown in FIG. 1, in core 2, the program of update firmware 221 is started (step S21), and it is determined whether or not the program can start the operation (step S22). When the program can be started (step S22: YES), “normal end” is returned to the CPU control unit 120 (step S23). On the other hand, if the program could not be started (step S22: NO), “abnormal end” is returned to the CPU control unit 120 (step S24).

For example, in the example illustrated in FIG. 1, the test execution unit 123 loads the test program 222 to the sleeping core 2 and checks (determines) whether the update firmware 221 operates normally.
FIG. 4 is a flowchart showing the flow of processing in the test execution unit 123. With reference to this flowchart, first, the test program 222 is operated in the core 2 (step S31), and it is determined whether or not the test program 222 has been normally completed (terminated) (step S32), and has been completed normally. If this is the case (step S32: YES), “normal end” is returned to the CPU control unit 120 (step S33). If the normal end cannot be completed (step S32: NO), “abnormal end” is displayed. (Step S34).

  In the above-described series of processing in the memory load unit 121, the program load unit 122, and the test execution unit 123, when “abnormal end” is returned, the advance operation of the update firmware (update program) cannot be confirmed. In this case, the CPU control unit 120 stops the firmware update process. On the other hand, if the update is successfully completed, the update firmware can operate normally. Therefore, the CPU control unit 120 continues the update process, and then the core switching unit 124 determines whether the core is in an operating state or a sleep state. Switch.

  FIG. 5 is a flowchart showing the operation of the core switching unit 124. As shown in this flowchart, the core switching unit 124 turns on (ON) and off (OFF) an exclusive ON / OFF flag (not shown) that determines (controls) whether to activate or sleep the cores 1 to 3. ) To switch one core (for example, core 2) to the activated state and the other core (for example, core 1) to the dormant state (step S41).

  The interrupt switching unit 125 also includes an interrupt mask unit 126 that masks (prohibits) interrupt requests for any cores 1 to 3, and an interrupt mask release unit 127 that similarly cancels masking of interrupt requests for any cores 1 to 3. Consists of. The interrupt mask unit 126 masks acceptance of an interrupt by, for example, turning on an interrupt flag (not shown) that masks an interrupt request for any core 1 to 3 (step S51).

  Further, as shown in the flowchart of FIG. 7, the interrupt mask canceling unit 127 cancels the interrupt mask by setting an interrupt flag (not shown) to an arbitrary core 1 to 3, for example. The interrupt request is accepted (step S61). The interrupt mask unit 126 and the interrupt mask release unit 127 can switch the interrupt destinations for the plurality of cores 1 to 3 at one point (instant).

  For example, in the example shown in FIG. 1, after the core switching unit 124 makes the update firmware 221 operable in the core 2, the interrupt mask unit 126 masks the interrupt request to the operating core 1, and interrupts The interrupt notification destination (processing request destination to the firmware) can be switched from the core 1 to the core 2 by executing a process of releasing the mask for the core 2 by the mask release unit 127.

Next, the operation of the first exemplary embodiment of the present invention will be described in detail with reference to the sequence diagram of FIG.
Referring to this sequence diagram, first, assume that core 1 is performing processing while operating firmware 211 is operating (active system) (step S100). At this time, it is assumed that the core 2 is in a dormant state and is not related to system operation (step S101). At the same time, it is assumed that the core 3 is performing processing while being in a standby state (standby system) in which the operation firmware can operate (step S102).

  In this state, when the firmware update is started, the memory load unit 121 first reads the update firmware 221 and the test program 222 into the occupied memory of the sleeping core 2 (core 2 memory 220) (steps S103 and S104). ). Next, the update firmware 221 is loaded to the core 2 that has been sleeping by the program loading unit 122 (step S105). Then, the test execution unit 123 loads the test program 222 into the core 2 and executes the test program 222 in the core 2 (step S106).

  By completing a series of operations from step S103 to step S106, the test program 222 can check that the update firmware 221 can operate correctly. As a result, the preliminary operation inspection of the update firmware 221 is completed (step S107).

  Next, as the core that operates the firmware, the core 2 in which the update firmware 221 can be operated and the core 1 that is operating the operation firmware 211 are exchanged. In this case, the operation of the operation firmware 211 in the core 1 is set to the non-operating state by masking the interrupt to the core 1 by the interrupt mask unit 126 (step S108). At this stage, the core 2 is in a sleeping state in which the update firmware is not operating (step S109).

Thereafter, the operating and sleeping flags are swapped by the core switching unit 124, the core 1 is in a sleep state where the operation firmware is not operating (step S110), and the core 2 is in an operation state where the operation firmware is not operating. (Step S111). Finally, the interrupt mask cancellation unit 127 cancels the interrupt mask to the core 2, the core 2 is in the operation of the update firmware operation, and the update firmware 221 operates as an active system in the core 2 (step S113). . At this stage, the core 1 is maintained in a sleep state (step S112), and the core 3 is maintained in a standby state (step S114).
In the series of switching operations from step S108 to step S113 described above, the operating core is switched from core 1 to core 2 in a very short time, so that the firmware update can be completed at one point (instant). it can.

  If an error occurs in a series of firmware update processes, the update process is stopped until the test is completed (step S107). After the test is completed, the interrupt switching destination is sent by the core switching unit 124 and the interrupt switching unit 125. Return to the original core 1. As a result, even if an error occurs, it is possible to return to the state before the firmware update process. Further, the core 3 operating as a standby system continues the standby operation without being affected by the firmware update (Steps S102 and S114). For this reason, the redundancy as the control device 100 is not impaired even during the firmware update.

  Further, after the firmware update is completed by the above procedure, the update firmware 221 operated in the core 2 is set as the new current operation firmware when further updating to the next update firmware. Then, the update firmware 221 is loaded into the core 3 as operation firmware, and the core 3 is set as a standby system, and is updated to a new next update firmware using the sleeping core 1. The procedure for updating to the next update firmware using the sleeping core 1 is the same as the procedure when the core 1 and the core 2 are replaced in the sequence diagram shown in FIG.

  As described above, in the control device 100 according to the first embodiment, as a first effect, it is possible to check in advance that the firmware to be updated normally operates when updating the firmware. Thus, the reliability when updating the firmware can be improved. As a second effect, when the operation firmware is switched to the update firmware, switching is performed by using a means that can complete the processing in a very short time, such as switching the operation and sleep state for the core and changing the interrupt mask for the core. Thus, the blank time (time during which the control device cannot perform processing) generated when the firmware is updated can be remarkably shortened.

[Second Embodiment]
In the first embodiment described above, by loading and executing the update firmware 221 in the core 2, the core 2 is in operation (active system), the core 1 is in a sleep state, and the core 3 In the above example, the operation firmware 211 is kept in a standby (standby system) state in which the operation firmware 211 can operate. That is, for the core 3, the example in which the standby operation is continued as it is without being affected by the firmware update has been described.

  In contrast, in the second embodiment of the present invention, the update firmware 221 is loaded and executed on the core 2 to make the core 2 stand by (standby system) and to make the core 3 sleep. Thereafter, by switching between a general active system and a standby system, the core 1 is set in a standby state (standby system) in which the operation firmware 211 can be operated, and the core 2 is in a standby state (standby system) to in operation (active system). An example of setting this state will be described. That is, in the first embodiment, the core 3 loaded with the updated firmware is switched between the active system and the core 3 remains in the standby system. On the other hand, in the second embodiment, the core 2 loaded with the updated firmware is switched to the standby system (core 3) and then switched to the active system (core 1). Is a standby system, and an example in which the core 3 is switched from standby to sleep will be described.

FIG. 9 is a sequence diagram for explaining the operation of the second embodiment of the control apparatus of the present invention. The operation of the second embodiment will be described below with reference to the sequence diagram shown in FIG.
First, it is assumed that the core 1 operates the operation firmware 211 to perform processing as an active system (step S200). At this time, it is assumed that the core 2 is in a dormant state and is not related to system operation (step S201). At the same time, it is assumed that the core 3 is performing processing as a standby system capable of operating the operational firmware (step S202). In this state, when the firmware update is started, the memory load unit 121 first reads the update firmware 221 and the test program 222 into the occupied memory of the sleeping core 2 (core 2 memory 220) (step S203 and step S203). S204).

  Next, the update firmware 221 is loaded to the core 2 that has been sleeping by the program loading unit 122 (step S205). Then, the test execution unit 123 loads the test program 222 into the core 2 and operates the test program 222 in the core 2 (step S206).

  By completing the series of operations from Steps S200 to S206 described above, the test program 222 can check (determine) that the update firmware 221 can operate correctly. Thereby, the preliminary inspection of the update firmware 221 is completed (step S207).

  After the inspection of the update firmware 221 is completed, the core 2 enters a sleep state where the update firmware 221 is not operating (step S208), and the core 3 is in an operating state where the interrupt is masked by the interrupt mask unit 126 and the operation firmware is not operating. (Step S209). Subsequently, the core switching unit 124 causes the core 2 to be in a standby state where the updated firmware is not operating (step S210), and the core 3 is sleeping while the operating firmware is not operating (step S211).

  Thereafter, the interrupt mask canceling unit 127 cancels the interrupt mask of the core 2, and the core 2 is waiting for the update firmware operation (step S213). In this state, the core 1 is in operation firmware operation (step S212), and the core 3 is in sleep without operation firmware operation (step S214).

Finally, the core 2 on which the update firmware 221 is operating is in operation (active system) by a general switching operation between the active system and the standby system (step S216), and the core 1 on which the operation firmware 211 is operating Switches to standby (standby system) (step S215). The core 3 remains dormant (step S217).
With the above procedure, the control device 100 can switch from the operation firmware 211 to the update firmware 221.

  As described above, in the second embodiment, whether or not the update firmware 221 operates normally using the sleeping core 2 and operates the core 2 as an active system, The core 1 that was once the active system of the operation firmware 211 can be used as a standby system core. In addition, the core 3 that was once a standby system can be a sleeping core. As described above, in the second embodiment, the core 1 can be a standby system, and in the first embodiment, the core 3 can be a standby system. It can be selected to be a standby core.

  Here, the correspondence relationship between the present invention and the above embodiment will be supplementarily described. In the said embodiment, CPU110 respond | corresponds to CPU in this invention, and the cores 1-3 correspond to the several core in this invention. In addition, the first core in the present invention corresponds to the core 1, the second core in the present invention corresponds to the core 2, and the third core in the present invention corresponds to the core 3. Further, the memory 200 in the present invention corresponds to the memory 200, and the occupied memory area in the present invention corresponds to the core 1 memory 210, the core 2 memory 220, and the core 3 memory 230. Further, the shared memory 240 corresponds to the shared memory area in the present invention. In addition, the operation firmware in the present invention corresponds to the current operation firmware 211, the update firmware in the present invention corresponds to the update firmware 221 that is newly updated firmware, and the test program in the present invention includes the test program 222. Correspond.

  The memory load unit in the present invention corresponds to the memory load unit 121, the program load unit in the present invention corresponds to the program load unit 122, and the test execution unit in the present invention corresponds to the test execution unit 123. The core switching unit in the present invention corresponds to the core switching unit 124, the interrupt mask unit in the present invention corresponds to the interrupt mask unit 126, and the interrupt mask release unit in the present invention corresponds to the interrupt mask release unit 127. To do.

  (1) In the above-described embodiment, the control device 100 arranges the plurality of cores 1 to 3 in the CPU 110 and occupies and uses the occupied memory area (for core 1) on each of the cores 1 to 3 on the memory 200. The memory 210, the core 2 memory 220, and the core 3 memory 230) and the shared memory area (shared memory 240) shared by each core are arranged, and the currently operating operational firmware 211 is updated to the new updated firmware 221. In this case, the second core 2 different from the first core 1 that operates the operation firmware 211 is selected, and the update firmware 221 is loaded into the occupied memory area (the core 2 memory 220) of the second core 2. Then, it is checked that the update firmware 221 operates normally in the second core 2, and after this check, the update is performed in the second core 2. With operating the firmware 221 processes the processing request to the firmware from the first core 1 is switched to the second core 2.

In the control device 100 having such a configuration, when the current operation firmware 211 is updated to the new update firmware 221, the core 2 that is not operating the operation firmware 211 is selected, and the occupied memory area of the selected core 2 ( The update firmware 221 is loaded into the core 2 memory 220), and the update firmware 221 loaded in the core 2 is operated to check (determine) whether it operates normally. After it is determined that the operation is normal by this inspection, the update firmware 221 is operated in the core 2 and a processing request for the firmware is switched from the core 1 to the core 2 for processing.
Accordingly, when the operation firmware 211 is switched to the new update firmware 221 during operation (system non-stop) in the single hardware control device 100, a failure such as a system stop occurs due to this firmware update. Can be avoided, and the reliability at the time of firmware update can be improved.

  (2) In the above-described embodiment, the control device 100 updates the occupying memory area (core 2 memory 220) of the second core 2 with the update firmware 221 and the test program 222 for checking the operation of the update firmware 221. , A program load unit 122 that loads the update firmware 221 from the occupied memory area (core 2 memory 220) of the second core 2 to the second core 2, and the second core 2 A test execution unit 123 that loads the test program 222 from the dedicated memory area (the core 2 memory 220) to the second core 2 and determines whether the update firmware 221 operates normally by the test program 222; The test execution unit 123 determines that the update firmware 221 operates normally. After that, the second core 2 is set to a state in which the update firmware 221 can be operated, the core switching unit 124 that sets the first core to the sleep state, and the interrupt request acceptance to the first core 1 is prohibited. And an interrupt switching unit 125 that is set to start accepting an interrupt request for the second core 2 and switches the notification destination of the interrupt request to the firmware from the first core 1 to the second core 2.

In the control device 100 having such a configuration, the memory load unit 121 reads the update firmware 221 and the test program 222 into the core 2 memory 220. Then, the update firmware 221 is loaded into the core 2 by the program load unit 122, the test program 222 is loaded into the core 2 by the test execution unit 123, and the update firmware 221 operates normally by executing the test program 222. Inspect (determine) whether or not to do. Then, after it is determined that the update firmware 221 operates normally, the core switching unit 124 sets the core 2 to a state where the update firmware 221 can be operated, and sets the core 1 to a sleep state. Thereafter, the interrupt switching unit 125 prohibits acceptance of the interrupt request to the first core 1 and sets to start accepting the interrupt request to the second core 2, and sets the notification destination of the interrupt request to the firmware as the first destination. The first core 1 is switched to the second core 2.
Thereby, in the single hardware control device 100, when the operation firmware 211 is switched to the update firmware 221 during operation (system non-stop), it is checked in advance whether the update firmware 221 operates normally. Therefore, it is possible to improve the reliability when the operation firmware is switched to the new update firmware.

  (3) In the embodiment, the control device 100 is in a standby state in which the operation firmware 211 can be operated in place of the first core 1 in addition to the first and second cores 1 and 2. When the operating firmware 211 is updated to the updated firmware 221, the core switching unit 124 sets the second core 2 to a state in which the updated firmware 221 can be operated, The core 1 is set to a sleep state, and the third core 3 is kept in a standby state.

In the control device 100 having such a configuration, when the operation firmware 211 is updated to the update firmware 221, the core switching unit 124 sets the second core 2 in a state in which the update firmware 221 can be operated, The core 1 is set to a sleep state, and the third core 3 is kept in a standby state.
Thereby, in addition to the effect of improving the reliability when the operation firmware 211 is switched to the new update firmware 221, it is possible to maintain the standby system (core 3) capable of operating the operation firmware 211 as it is. it can. For this reason, the redundancy as the control device 100 is not impaired even during the firmware update.

  (4) In the above embodiment, the control device 100 is in a standby state in which the operation firmware 211 can be operated in place of the first core 1 in addition to the first and second cores 1 and 2. When the operation firmware 211 is updated to the update firmware 221, the core switching unit 124 sets the second core 2 to a standby state in which the update firmware 221 can be operated. The third core 3 is set to the sleep state, and the interrupt switching unit 125 is set to prohibit the acceptance of the interrupt request to the third core 3 and to start accepting the interrupt request to the second core 2. The first core 1 is set to a standby state in which the operation firmware 211 can be operated by switching between the general operating system and the standby system, and the second core 2 is updated. Firmware 221 is set to the state of the running to operate.

In the control device 100 having such a configuration, when the operation firmware 211 is updated to the update firmware 221, the core switching unit 124 sets the second core 2 in a state in which the update firmware 221 can be operated, The core 3 is set to a sleep state, and the first core 1 is set to a standby state in which the operation firmware 211 can be operated.
As a result, in addition to the effect of improving the reliability when switching the operation firmware to the new update firmware, the core 1 in which the operation firmware has been operating is in a standby state where the operation firmware 211 can be operated. Can be set to state. In this way, either the core 1 or 3 can be selected to be a standby system.

As mentioned above, although embodiment of this invention was described, the control apparatus of this invention is not limited only to the above-mentioned example of illustration, A various change can be added in the range which does not deviate from the summary of this invention. Of course.
For example, in the example illustrated in FIG. 1, the example in which the CPU 110 is configured by the three cores 1 to 3 has been described. However, the CPU 110 can be configured by the two cores 1 and 2. Further, the CPU 110 can be configured with four or more cores. When the CPU 110 is composed of two cores 1 and 2, the procedure shown in the sequence diagram of FIG. 9 is performed (however, the procedure for the core 3 is omitted), and the core 2 is replaced by the update firmware 221. The operating system may be used, and the core 1 may be used as a standby system for the operation firmware 211.

1 ... Core 1
2 ... Core 2
3 ... Core 3
100 ... Control device 110 ... CPU
DESCRIPTION OF SYMBOLS 120 ... Control part 121 ... Memory load part 122 ... Program load part 123 ... Test execution part 124 ... Core switching part 125 ... Interrupt switching part 126 ... Interrupt mask part 127 ... Interrupt mask cancellation part 200 ... Memory 210 ... Memory 1 for core 1 ... Operation firmware 220 ... Core 2 memory 221 ... Update firmware 222 ... Test program 230 ... Core 3 memory 231 ... Operation firmware 240 ... Shared memory

Claims (6)

  A plurality of core processors are arranged in the CPU, and an occupied memory area occupied and used by each core processor and a shared memory area shared by each core processor are arranged on the memory, and the currently operating firmware is newly added. When updating to the update firmware, a second core processor different from the first core processor running the operation firmware is selected, and the update firmware is loaded into the occupied memory area of the second core processor, The second core processor checks that the update firmware operates normally, and after the check, operates the update firmware in the second core processor, and sends a processing request for the firmware from the first core processor. Switch to the second core processor for processing The control device, characterized in that. A memory load unit that reads the update firmware and a test program for inspecting the operation of the update firmware into an occupied memory area of the second core processor;
A program load unit that loads the updated firmware from the occupied memory area of the second core processor to the second core processor;
A test execution unit that loads the test program from the occupied memory area of the second core processor to the second core processor, and determines whether the update firmware operates normally by the test program;
After the test execution unit determines that the update firmware operates normally, the second core processor is set to a state where the update firmware can be operated, and the first core processor is set to a sleep state. A core switching unit;
An interrupt request for the first core processor is prohibited from being accepted, and an interrupt request for the second core processor is set to be started, and a notification destination of the interrupt request to the firmware is sent from the first core processor to the first core processor. An interrupt switching unit for switching to the second core processor;
The control device according to claim 1, further comprising: In addition to the first and second core processors, the control device further includes a third core processor in a standby state in which the operation firmware can be operated in place of the first core processor,
When updating the operational firmware to the updated firmware,
The core switching unit is
The second core processor is set to a state where update firmware can be operated, the first core processor is set to a sleep state, and the standby state is continued as it is for the third core processor. ,
The control device according to claim 2. In addition to the first and second core processors, the control device further includes a third core processor in a standby state in which the operation firmware can be operated in place of the first core processor,
When updating the operational firmware to the updated firmware,
The core switching unit is
Setting the second core processor to a state in which the update firmware can be operated, setting the third core processor to a sleep state,
The interrupt switching unit
The acceptance of the interrupt request to the third core processor is prohibited and the acceptance of the interrupt request to the second core processor is set to start, and the first core processor is switched by switching between the active system and the standby system. Setting the standby state in which the operation firmware can be operated, and setting the second core processor to the operation state in which the update firmware operates;
The control device according to claim 2. A method for updating firmware in a control device, comprising:
A procedure for arranging a plurality of core processors in a CPU;
A procedure for allocating an occupied memory area occupied by each core processor and a shared memory area shared by each core processor on the memory;
When updating the currently operating firmware to a new update firmware,
Selecting a second core processor different from the first core processor that operates the operational firmware, and loading the updated firmware into an occupied memory area of the second core processor;
A procedure for checking that the update firmware operates normally by the second core processor;
A procedure for operating the updated firmware in the second core processor after the inspection and switching a processing request for the firmware from the first core processor to the second core processor;
A firmware update method comprising: Control device computer,
Means for arranging a plurality of core processors in a CPU;
Means for allocating an occupied memory area that is occupied and used by each core processor and a shared memory area shared by each core processor on the memory;
When updating the currently operating firmware to a new update firmware,
Means for selecting a second core processor different from the first core processor that operates the operation firmware, and loading the updated firmware into an occupied memory area of the second core processor;
Means for checking that the updated firmware is operating normally by the second core processor;
Means for operating the updated firmware in the second core processor after the inspection, and processing a processing request for the firmware by switching from the first core processor to the second core processor;
A program characterized by functioning as

Images