JP2005173888A - Information processor, method and program for restoring program, and recording medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To easily solve problems that might be caused by an interruption during program updates, thereby restoring a device or a program. <P>SOLUTION: An information processor includes an update interruption determining means (step S11) for determining whether or not a program update by a program update means was interrupted the last time the information processor was started; an operating system starting means (step S12 or step S17) for starting a corresponding operating system according to the result of determination by the update interruption determining means (step S11); a first program restoration means for restoring programs stored in a program storage means; and a screen control means for performing control about a screen according to the operating system started by the operating system starting means. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to an information processing apparatus, a program recovery method, a program recovery program, and a recording medium.

  Conventionally, devices such as printers, copiers, facsimiles, scanners and the like are generally arranged as separate housings. However, recently, an image forming apparatus in which the functions of these devices are housed in a single housing is known. This image forming apparatus is provided with a display unit, a printing unit, an imaging unit, and the like in one casing, and four types of software corresponding to a printer, a copy, a scanner, and a facsimile device, respectively. Are operated as a printer, a copy, a scanner, and a facsimile apparatus.

  In such a conventional image forming apparatus, a controller board equipped with a non-rewritable ROM (Read Only Memory) in which software is incorporated for each function of a printer, a copy, a scanner, and a facsimile is provided to realize a plurality of functions. Was configured.

  Therefore, in the conventional image forming apparatus, when changing or adding each function, a hardware operation of preparing a new ROM incorporating a program reflecting the function addition or function change and replacing the ROM together. Was necessary, and the labor of the update work was excessive.

  For this reason, recent image forming apparatuses incorporate a program that includes printer, copy, scanner, and facsimile functions into a ROM that can be electrically rewritten, such as a flash memory, and realize multiple functions as a combined service. ing.

  In such an image forming apparatus, when each function is changed or added, a program in which the function is added or changed is recorded as update data in a flash card, and this flash card is stored in the flash card interface of the image forming apparatus. And restarting the image forming apparatus.

  At this time, the image forming apparatus reads the update data from the flash card by the update program, and the program recorded in the flash memory is updated by the read update data. As described above, in recent image forming apparatuses, the ROM update is performed in software by utilizing the characteristic of the flash memory that is electrically rewritable.

  For example, Japanese Patent Laid-Open No. 2004-228561 describes a technology that has a problem of flexibly dealing with software changes and additions.

  By the way, the applicant has hardware resources used in image forming processing such as a display unit, a printing unit, and an imaging unit, and performs an application specific to each user service such as a printer, a copy, a scanner, and a facsimile. When providing a user service by interposing between these applications and hardware resources, management, execution control and image formation of hardware resources commonly required by at least two of the applications An image forming apparatus provided with a platform including various control services for processing has been invented (see Patent Document 2).

  The user service is a service related to image formation provided to the user. The control service refers to a service that provides hardware resources related to image formation to an application.

  According to this image forming apparatus, a configuration including a hardware resource management, execution control, and image forming process that are commonly required by at least two applications is compared with a normal image forming apparatus. Therefore, software development such as future application addition and control service addition can be easily performed, and the scalability is high. For this reason, in the image forming apparatus having such a configuration, the necessity of program update due to function addition or function change is much higher than that of the conventional image forming apparatus.

  For example, in an image forming apparatus usage contract, an image forming apparatus was introduced and operated under a contract that uses only the functions of a printer, a copy, and a scanner. It can also be used. In this case, the addition of a facsimile function necessitates the addition of a facsimile application and the accompanying addition or change of a platform.

  In the case of an image forming apparatus having a configuration including a plurality of applications and a platform for performing common processing, there are many cases where such a request for function change and function addition occurs irregularly and frequently. Therefore, as in the conventional program update method, every time a program is updated, a flash card is obtained, and update data is read from the flash card and the program stored in the ROM is updated. In addition, it cannot respond quickly to frequent program update needs. In addition, the program update method using a flash card has a problem that the update work becomes very complicated and the work efficiency is poor.

Accordingly, the applicant has invented an image forming apparatus, a program update method, and a recording medium that receive program update data via a network and perform program update using the update data (see Patent Document 3).
JP 2001-268306 A JP 2002-82806 A JP 2003-182191 A

  However, for example, in an image forming apparatus that receives program update data via the above-described network and updates the program using the update data, the next time the program is updated, if a power failure, outlet disconnection, artificial power OFF occurs, etc. When the image forming apparatus is turned on, some or all of the functions of the image forming apparatus become unusable.

  Hereinafter, an example in which a part of the functions of the image forming apparatus becomes unusable after the program update is interrupted will be described with reference to FIG. FIG. 1 is a diagram for explaining an example in which some of the functions of the image forming apparatus become unusable after the program update is interrupted. Details of the configuration of the image forming apparatus will be described with reference to FIG.

  FIG. 1A shows an example of an image forming apparatus before the platform is updated. On the other hand, FIG. 1B shows an example of the image forming apparatus after the power is turned off artificially and restarted, for example, during the platform update.

  In FIG. 1B, SRM, SCS, and NCS are different from those in FIG. 1.00 to v. Although the program has been updated to 1.10, for example, the ECS is activated in FIG. 1B because the power of the image forming apparatus was turned off during the update of the program related to ECS, which is one of the processes constituting the platform. The copy application, the printer application, and the like cannot be used.

  Further, for example, in an image forming apparatus that receives program update data via the network and updates the program using the update data, the image forming apparatus after the program update performs the update with the updated program. Even when some or all of the functions of the image forming apparatus cannot be used or the operation becomes unstable due to a combination with a program that does not exist, there is a problem that the image forming apparatus cannot be easily restored.

  Hereinafter, an example in which a part of the functions of the image forming apparatus cannot be used due to version mismatch will be described with reference to FIG. FIG. 2 is a diagram for explaining an example in which some of the functions of the image forming apparatus become unusable due to version mismatch.

  FIG. 2A illustrates an example of the image forming apparatus before the copy application is updated. On the other hand, FIG. 2B shows the copy application v. 2.00 and ECSv. A combination of 1.00 shows an example in which the copy application does not operate normally.

  The present invention has been made in view of the above points, and it is an object of the present invention to easily solve problems associated with program update and restore the apparatus and / or program. Another object of the present invention is to display a screen related to restoration of an apparatus and / or program and provide information to a user.

  Therefore, in order to solve the above problem, the present invention is based on program storage means for storing a program, update data receiving means for receiving update data relating to the program stored in the program storage means, and the update data. An information processing apparatus having a program update means for updating a corresponding program stored in the program storage means, when the information processing apparatus has been activated last time, the program update means in the program update means Update interruption determination means for determining whether or not the program update has been interrupted, operating system activation means for activating a corresponding operating system in accordance with the determination result in the update interruption determination means, and stored in the program storage means The first program to restore the existing program And stage, in response to said operating system activated in the operating system boot device, and having a screen control means for performing control relating to the screen, the.

  The present invention also provides a program storage means for storing a program, an update data receiving means for receiving update data relating to the program stored in the program storage means, and the program storage means based on the update data. An information processing apparatus that updates a corresponding program stored therein, and restores the program stored in the program storage means when the information processing apparatus was last activated Therefore, a reboot determination unit that determines whether or not a reboot has occurred, an operating system activation unit that activates a corresponding operating system according to a determination result in the reboot determination unit, and a program stored in the program storage unit are restored Second program recovery means to Depending on the operating system activated in the operating system boot device, characterized by having a a screen control means for performing control related to the screen.

  The program storage means corresponds to, for example, a flash memory 204 described later.

  According to the present invention, it is possible to easily solve a problem caused by updating a program and restore the apparatus and / or program. Further, according to the present invention, it is possible to display a screen related to the restoration of the apparatus and / or program and provide information to the user.

  Further, as means for solving the above problems, a program recovery method, a program recovery program, and a recording medium may be used.

  According to the present invention, it is possible to easily solve a problem caused by updating a program and restore the apparatus and / or program. Further, according to the present invention, it is possible to display a screen related to the restoration of the apparatus and / or program and provide information to the user.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 3 is a block diagram (No. 1) showing a configuration of an image forming apparatus (hereinafter referred to as a multifunction peripheral). FIG. 3 shows an example of the configuration of the multifunction machine when the general-purpose OS 121 is activated by the ROM monitor 410 described later.

  As shown in FIG. 3, the MFP 100 includes a plotter 101, a scanner 102, an FCU (Fax Control Unit) 103, other hardware resources 104, a general-purpose OS (Operating System) 121, and a platform 120. And a software group 110 composed of an application 130, and a multifunction machine starting unit 140 that is executed when the power is turned on.

  The MFP activation unit 140 is first executed when the MFP 100 is turned on, and when update information is not stored in update suspension information described below and / or when a maintenance flag is stored in update suspension information, The general-purpose OS 121, the platform 120, and the application 130 shown in FIG.

  The platform 120 interprets a processing request from the application 130 and generates a hardware resource acquisition request, and a system resource that manages one or a plurality of hardware resources and arbitrates the acquisition request from the control service. A manager (SRM) 123.

  The control service is formed of a plurality of service modules, and includes an SCS (system control service) 122, an ECS (engine control service) 124, an MCS (memory control service) 125, an OCS (operation panel control service) 126, and an FCS. (Fax Control Service) 127 and NCS (Network Control Service) 128. The platform 120 has an application program interface (API) that can receive a processing request from the application 130 using a predefined function.

  The general-purpose OS 121 is a general-purpose operating system such as UNIX (registered trademark), and executes the software of the platform 120 and the application 130 in parallel as processes. Note that the general-purpose OS 121 illustrated in FIG. 3 first executes the normal mode thread of each process when the normal mode thread and the ROM update mode thread exist in the process.

  The MCS 125 is activated as a process for controlling the memory. The process of the MCS 125 includes normal mode threads for performing complex services such as acquisition and release of image memory, use of a hard disk drive (HDD), copying and compression of image data, printers, facsimiles, scanners, etc., and a remote ROM described later A ROM update mode thread that performs processing such as securing an update data area in the SDRAM 203 or the like for storing update data developed from the update data packet by the update application 117;

  The process of the OCS 126 displays a normal mode thread for controlling an operation panel (operation panel 1310) serving as information transmission means between the operator and the main body control, information on ROM update, and the like on the operation panel (operation panel 1310). A ROM update mode thread for performing processing and the like.

  The process of FCS 127 includes facsimile transmission / reception using PSTN / ISDN network from each application layer of the system controller, registration / quotation of various facsimile data managed by BKM (backup SRAM), facsimile reading, facsimile reception printing, and complex transmission / reception. It has a normal mode thread that performs processing such as providing an API for performing, and a ROM update mode thread that is simply activated without executing such a function.

  The NCS 128 is a process for providing a service that can be used in common for applications that require network I / O. Data received from the network side according to each protocol is distributed to each application, and data from the application is networked. It has a normal mode thread that performs processing such as mediation when transmitting to the side. Further, in the normal mode thread of the NCS 128, the ROM update data packet of the flash memory is further received from a remote host such as a host computer of the multifunction device developer or a third vendor of the application developer connected to the network.

  The NCS 128 process also has a ROM update mode thread for performing processing such as passing update data included in the ROM update data packet of the flash memory to the remote ROM update application 117 described later.

  The process of the SRM 123 performs system control and resource management together with the SCS 122. The SRM123 process uses the hardware resources of the scanner, printer, etc. engines, memory, HDD files, and host I / O (Centronics I / F, IEEE 1394 I / F, USB I / F, NIC I / F, etc.). It has a normal mode thread that performs processing such as arbitration and execution control according to a request from an upper layer to be used, and a ROM update mode thread that is simply activated without executing such resource management. Specifically, the normal mode thread of the SRM 123 determines whether the requested hardware resource is available (whether it is not used by another request), and if so, the requested hardware resource is requested. Tell the upper layer that the hardware resource is available. In addition, the normal mode thread of the SRM 123 performs use scheduling of hardware resources in response to a request from an upper layer, and directly requests contents (for example, paper conveyance and image forming operation, memory allocation, file generation, etc. by the printer engine). We are carrying out.

  The process of the SCS 122 has a normal mode thread that performs processing such as application management, operation unit control, system screen display, LED display, resource management, and interrupt application control.

  Further, the normal mode thread of the SCS 122 is based on a request from the remote ROM update application 117 described later, the printer application 111, the copy application 112, the fax application 113, the scanner application 114, the net file application 115, the ECS 124, the MCS 125, and the OCS 126. , Notifies the ROM update mode thread activation request to FCS 127, NCS 128, and the like.

  The process of the SCS 122 also has a ROM update mode thread. The ROM update mode thread corresponds to the configuration of the application 130 operating on the multifunction peripheral 100 and the platform 120 from the update data expanded in the SDRAM 203 or the like. A process of selecting update data or a process of starting a ROM update unit 430 described later is performed.

  The process of the ECS 124 is simply started without performing such engine control, and a normal mode thread that performs processing such as engine control of the plotter 101, the scanner 102, the FCU (Fax Control Unit) 103, and other hardware resources 104. And a ROM update mode thread that can only be done.

  As described above, all the ROM update mode threads of the SRM 123, the ECS 124, and the FCS 127 are simply activated, but this is activated to indicate the existence of a control service that operates inside the MFP during the ROM update process. It has come to be. On the other hand, the ROM update mode threads of the SCS 122, MCS 125, OCS 126, and NCS 128 are also activated to indicate the existence of a control service that operates inside the multi-function peripheral and performs processing necessary for ROM update. .

  The application 130 includes a printer application 111 that is a printer application having a page description language (PDL), PCL, and PostScript (PS), a copy application 112 that is a copy application, and a fax application 113 that is a facsimile application. The scanner application 114 as a scanner application, the network file application 115 as a network file application, and the update data packet received via the network by the NCS 128 are expanded into update data, and the update data is read into the ROM update mode thread of the MCS 125. Remote ROM update application (hereinafter referred to as RRU application) 117 that performs processing to be stored in an update data area such as SDRAM 203 secured by , The has.

  Each of these apps is also started as a process, like the platform 120, and each app other than the RRU app 117 is started to indicate a normal mode thread that performs the processing as described above and the presence of the app itself. ROM update mode thread.

  Hereinafter, an example of a hardware configuration of the multifunction peripheral 100 will be described with reference to FIG. FIG. 4 is a block diagram illustrating a hardware configuration of the multifunction machine.

  As illustrated in FIG. 4, the multifunction peripheral 100 includes an operation panel 1310, a FAX control unit (FCU) 103, an engine unit 1350 (to which the scanner 102 and the like are connected), a plotter 101, and an ASIC 1301 of the controller 1300 connected to a PCI (Peripheral Component). An interconnect) bus 1309 is connected.

  The controller 1300 connects the NVRAM 208, SDRAM 203, flash memory 204, HDD (Hard Disk Drive) 1303, and the like to the ASIC 1301, and connects the ASIC 1301 and the CPU 1304 via the NB 1305 of the CPU chip set. Thus, the reason for connecting via the NB 1305 is that the interface of the CPU 1304 itself is not disclosed.

  Here, the ASIC 1301 and the NB 1305 are not connected via the PCI, but are connected via the AGP 1308. The reason for the connection via the AGP 1308 is that the MFP 100 is connected to the platform 120 and the application 130 shown in FIG. This is because performance decreases.

  The CPU 1304 controls the entire MFP 100. Specifically, the SRM 123 and the SCS 122, ECS 124, MCS 125, OCS 126, FCS 127, and NCS 128 forming the platform 120 are started as processes on the general-purpose OS 121, respectively. At the same time, the printer application 111, the copy application 112, the fax application 113, the scanner application 114, the net file application 115, and the RRU application 117 forming the application 130 are activated and executed. For example, when the MFP 100 has a configuration as shown in FIG. 10 described later, the CPU 1304 activates and executes the SRM 123, the SCS 122 and the MCS 125 forming the platform 120 as processes on the general-purpose rescue OS 131, respectively.

  The NB 1305 includes a CPU 1304, a system memory 1306, an SB 1307, a NIC (Network Interface Card) 1341, a USB (Universal Serial Bus) 1330, an IEEE 1394 1340, a Centronics 1342, a driver I / F 1343, an ASIC 1301, and an ASIC 1301. It is a bridge to do.

  A system memory 1306 is a memory used as a drawing memory or the like of the multifunction peripheral, and an SB 1307 is a bridge for connecting the NB 1305 and peripheral devices. The SB 1307 has an RTC (Real Time Clock) that measures time in the controller 1300. The SB 1307 has a USB host inside, and can capture image data by connecting a USB-connected camera, for example, and can also receive data from other USB targets.

  The driver I / F 1343 is an I / F that is used to read a program or application from an inserted recording medium in which the program or application is stored and mount the program or application on the multifunction peripheral 100. Examples of the recording medium include an SD memory card, smart media, multimedia card, and compact flash (registered trademark).

  The SDRAM 203 is a non-volatile memory that secures an update data area for storing update data developed from the received update data packet when the update data packet is received via the network.

  The NVRAM 208 is a non-volatile memory that stores, for example, update interruption information described later.

  A flash memory (hereinafter referred to as “flash ROM”) 204 stores the above-described applications, the control services constituting the platform, and the programs of the SRM 123. The MFP 100 is shipped with each of these programs pre-installed in the flash ROM 204, and a remote ROM update process is executed in which the program in the flash ROM 204 is updated upon receipt of the ROM update data packet. It has become.

  The HDD 1303 is a storage that stores image data, programs, font data, forms, and documents. The operation panel 1310 receives input operations from the operator and displays them for the operator. It is an operation part which performs.

  The ASIC 1301 is provided with a RAM interface for connecting the NVRAM 208 and the SDRAM 203, a ROM interface for connecting the flash ROM 204, and a hard disk interface for connecting the HDD 1303. When inputting / outputting data, the input / output destination is switched to the RAM interface, ROM interface, or hard disk interface.

  The AGP 1308 is a bus interface for a graphics accelerator card that has been proposed for speeding up graphics processing. The AGP 1308 speeds up the graphics accelerator card by directly accessing the system memory 1306 with high throughput.

  Hereinafter, an example of the entire remote ROM update process will be described with reference to FIGS. FIG. 5 is a diagram (part 1) for explaining the entire process of remote ROM update.

  As shown in FIG. 5, when the multifunction peripheral 100 is executing a normal composite service operation, each application, each control service, and the like having a normal mode thread and a ROM update mode thread are In both cases, a normal mode thread is executed.

  In this state, when an update data packet is transmitted from a remote host such as the host computer of the multifunction device developer or the third vendor host computer of the application developer via the network, the normal mode thread of the NCS 128 transmits the update data packet. Receive (sequence SQ1).

  The normal mode thread of the NCS 128 determines the content of the received packet, and if it is determined that it is an update data packet, notifies the RRU application 117 that the ROM update data packet has been received (sequence SQ2).

  The RRU application 117 that is notified that the ROM update data packet has been received from the normal mode thread of the NCS 128 requests the normal mode thread of the SCS 122 to issue a ROM update mode thread transition request notification (sequence SQ3). ).

  The normal mode threads of the SCS 122 requested to issue the ROM update mode thread transition request notification from the RRU application 117 are the printer application 111, the copy application 112, the fax application 113, the scanner application 114, the net file application 115, the ECS 124, the MCS 125, A ROM update mode thread transfer request is notified to each of the OCS 126, FCS 127, and NCS 128 normal mode threads (sequence SQ4).

  FIG. 6 is a diagram (part 2) for explaining the entire process of remote ROM update.

  According to the sequence SQ4 of FIG. 5, the printer application 111, the copy application 112, the fax application 113, the scanner application 114, the net file application 115, the ECS 124, the MCS 125, which are notified of the transfer request of the ROM update mode thread from the normal mode thread of the SCS 122. The OCS 126, FCS 127, and NCS 128 each shift from the normal mode thread to the ROM update mode thread as shown in FIG.

  Further, the RRU application 117 requests the ROM update mode thread of the MCS 125 to secure an update data area in order to obtain an area necessary for developing the update data packet (sequence SQ5).

  The ROM update mode thread of the MCS 125 requested to secure the update data area by the RRU application 117 secures the update data area on the SDRAM 203, for example, and the start address of the update data area and the area size of the update data area Are returned to the RRU application 117 (sequence SQ6).

  The RRU application 117, which has received the start address of the update data area and the area size of the update data area from the ROM update mode thread of the MCS 125, removes the network information and decompresses the compressed data packet. Are expanded from the start address of the update data area notified from the ROM update mode thread of the MCS 125.

  Hereinafter, an example of the update data packet expanded in the update data area will be described with reference to FIG. FIG. 7 is a data structure diagram after development of the update data packet received by the multifunction machine.

  As shown in FIG. 7, the expanded update data packet includes a header portion 302 and a data portion 303.

  The header section 302 is divided into header blocks for each module so as to correspond to the module to be updated. Each header block includes a next header offset that is an offset to the next header block, an update data offset that is an offset to module update data, a size of the update data, a module ID that is module identification information, The update destination address indicating the relative address on the flash ROM 204 of the module and the update destination area length which is the size of the module are included.

  The data unit 303 stores update data for each module. The head of the update data of each module can be referred to by the update data offset of the header block corresponding to the module.

  Returning to FIG. 6, the RRU application 117 notifies the normal mode thread of the SCS 122 of the start address of the update data area in which the update data packet is expanded, and requests selection of update data (sequence SQ8).

  The normal mode thread of the SCS 122 that has received the update data selection request from the RRU application 117 activates the ROM update mode thread of the SCS 122, performs processing as shown in FIG. 12 to be described later, and selects update data (sequence SQ9). ).

  Further, the ROM update mode thread of the SCS 122 activates a ROM update unit 430 shown in FIG. 9 described later, and performs a ROM update process as shown in FIG. 13 described later (sequence SQ10).

  Hereinafter, an example of the configuration of the multifunction machine starting unit 140 will be described with reference to FIG. FIG. 8 is a block diagram illustrating an example of a configuration of the multifunction machine starting unit.

  As illustrated in FIG. 8, the multifunction machine starting unit 140 includes a ROM monitor 410 and a program starting unit 420.

  The ROM monitor 410 activates the general-purpose OS 121 shown in FIG. 3 when update information is not stored in update suspension information, which will be described later, and / or when a maintenance flag is not stored in update suspension information. When update information is stored and / or when a maintenance flag is stored in the update interruption information, the general-purpose rescue OS 131 is activated as shown in FIG.

  The program activation unit 420 is called from the general-purpose OS 121 or the general-purpose rescue OS 131, and includes a service layer activation unit 422, an application activation unit 423, and an activation information setting unit 424.

  When the program activation unit 420 is called from the general-purpose OS 121, the service activation unit 422 acquires the activation information of the general-purpose OS 121 and activates the platform 120. On the other hand, when the program activation unit 420 is called from the general-purpose rescue OS 131, the service activation unit 422 acquires the activation information of the general-purpose rescue OS 131 and, as illustrated in FIG. 10 described later, for example, the SRM 123, the MCS 125, and the SCS 122. And so on.

  The application activation unit 423 is executed when the program activation unit 420 is called from the general-purpose OS 121, acquires activation information of each application, and activates each application. Note that, as shown in Example 4 described later, the application activation unit 423 is executed even when the program activation unit 420 is called from the general-purpose rescue OS 131, and acquires activation information of the RRU application 117 to obtain the RRU. The application 117 may be activated.

  The activation information setting unit 424 is activated when the ROM update mode thread of each control service, SRM 123, and application 130 included in the platform 120 is executed. The activation information setting unit 424 activates each control service, SRM 123, and each application. Acquire information and set the acquired startup information in the environment variable. The activation information setting unit 424 is activated also when a rescue mode thread of each application included in each control service, SRM 123, and application 130 described later is executed, and activation information of each control service, SRM 123, and each application. May be acquired, and the acquired activation information may be set as an environment variable.

  Hereinafter, an example of the ROM update unit 430 included in the SCS 122 will be described with reference to FIG. FIG. 9 is a block diagram illustrating an example of the configuration of the ROM update unit.

  As illustrated in FIG. 9, the ROM update unit 430 includes an update information storage unit 431, an area data storage unit 432, a ROM update unit 433, and an update information deletion unit 434. In the case of Examples 2, 3, and 4 to be described later, a display control unit 435 is further included. In the case of a fourth embodiment described later, a transmission control unit 436 is further included.

  The update information storage unit 431 stores the update information such as the module ID and the update destination address as shown in FIG. 7 in the update interruption information.

  The area data storage unit 432 stores the updated area data in a secondary storage device such as the HDD 1303.

  Based on the update data, the ROM update unit 433 updates the corresponding program in the flash ROM 204 with the program included in the update data.

  The update information deletion unit 434 deletes the update information stored in the update information storage unit 431 from the update interruption information.

  For example, the display control unit 435 determines whether the OCS 126 is activated. If the OCS 126 is activated, for example, the display control unit 435 creates a recovery-in-progress screen of the flash ROM 204 and displays it on the operation panel 1310 via the OCS 126. An error screen is created and displayed on the operation panel 1310 via the OCS 126.

  For example, the transmission control unit 436 determines whether or not the NCS 128 is activated. When the transmission control unit 436 determines that the NCS 128 is activated, the transmission control unit 436 transmits information related to the recovery of the flash ROM 204 via the NCS 128 via the network. It is sent to a remote host such as a host computer or a host computer of a third vendor of the application developer.

  Hereinafter, an example of the configuration of the multifunction peripheral 100 when the general-purpose rescue OS 131 is activated by the ROM monitor 410 will be described with reference to FIG. FIG. 10 is a block diagram (part 2) of the configuration of the multifunction machine.

  As shown in FIG. 10, when the general-purpose rescue OS 131 is activated, rescue mode threads of the SRM 123, the MCS 125, and the SCS 122 are executed.

  The rescue mode thread of the SCS 122 performs a rescue method determination as will be described later, and based on the determination result, information and data related to program updates are received from the secondary storage device such as the HDD 1303 via the rescue mode thread of the MCS 125. The ROM update unit 430 is activated.

  Based on a request from the rescue mode thread of the SCS 122, the rescue mode thread of the MCS 125 acquires information and data related to the program update from the secondary storage device such as the HDD 1303 and provides the information or data to the rescue mode thread of the SCS 122, or the ROM Based on a request from the update unit 430, the data of the area to be updated is accumulated in a secondary storage device such as the HDD 1303.

  Hereinafter, the OS switching process at the time of boot will be described with reference to FIG. FIG. 11 is a flowchart for explaining the OS switching process at the time of booting.

  When the power is turned on, the multifunction device 100 activates the ROM monitor 410 in step S10.

  Progressing to step S11 following step S10, the ROM monitor 410 determines whether update information is stored in the update interruption information. If ROM monitor 410 determines that update information is stored in update interruption information (YES in step S11), it proceeds to step S16 and determines that update information is not stored in update interruption information (NO in step S11). ), Go to step S12.

  In step S12, the ROM monitor 410 activates the general-purpose OS 121.

  Progressing to step S13 following step S12, the general-purpose OS 121 activated in step S12 activates the program activation unit 420.

  Progressing to step S14 following step S13, the service activation unit 422 included in the program activation unit 420 activates the platform 120.

  Progressing to step S15 following step S14, the application activation unit 423 included in the program activation unit 420 activates the application 130.

  On the other hand, in step S16, the ROM monitor 410 stores a rescue boot flag in the startup information.

  Progressing to step S17 following step S16, the ROM monitor 410 activates the general-purpose rescue OS 131.

  Progressing to step S18 following step S17, the general-purpose rescue OS 131 activated in step S17 activates the program activation unit 420.

  Progressing to step S19 following step S18, the service activation unit 422 included in the program activation unit 420 refers to the activation time information, and if the rescue boot flag is stored, the rescue mode option is added and the platform 120 Start up.

  Proceeding to step S20 following step S19, the SCS 122 activates a rescue mode thread.

  Hereinafter, an example of update data selection processing by the ROM update mode thread of the SCS 122 described in the sequence SQ9 of FIG. 6 will be described with reference to FIG. FIG. 12 is a flowchart (part 1) for explaining update data selection processing executed by the SCS ROM update mode thread.

  In step S30, the ROM update mode thread of the SCS 122 seeks the header block at the head of the update data based on the head address of the update data area in which the update data packet notified from the RRU application 117 is expanded.

  Progressing to step S31 following step S30, the ROM update mode thread of the SCS 122 acquires the module ID from the header block.

  Progressing to step S32 following step S31, the ROM update mode thread of the SCS 122 compares the module ID acquired in step S31 with the module ID included in the startup information of the platform 120 or the application 130 set in the environment variable. Then, it is determined whether or not they match.

  If the ROM update mode thread of the SCS 122 determines that the module ID acquired in step S31 matches the module ID included in the startup information of the platform 120 or the application 130 set in the environment variable (YES in step S32), step In S33, if it is determined that the module ID acquired in Step S31 does not match the module ID included in the activation information of the platform 120 or the application 130 set in the environment variable (NO in Step S32), the process proceeds to Step S35. .

  In step S33, the ROM update mode thread of the SCS 122 acquires an update destination address, an update data offset, an update data size, and the like from the header block.

  Progressing to step S34 following step S33, the ROM update mode thread of the SCS 122 sets update information including a module ID, an update destination address, an update data offset, an update data size, and the like as a variable to be updated.

  In step S35, the ROM update mode thread of the SCS 122 refers to the update data area in which the update data packet is expanded, and determines whether the next header block exists. If the ROM update mode thread of the SCS 122 determines that the next header block exists (YES in step S35), the process proceeds to step S36, and if it determines that the next header block does not exist (NO in step S35), the process proceeds to step S37. .

  In step S36, the ROM update mode thread of the SCS 122 seeks the next header block and repeats the processing from step S31.

  On the other hand, in step S37, the ROM update mode thread of the SCS 122 refers to the variables to be updated and determines whether update information is set. If the ROM update mode thread of the SCS 122 determines that the update information is set in the variable to be updated (YES in step S37), the process proceeds to step S38, and the update information is not set in the variable to be updated. If determined (NO in step S37), the process is terminated.

  In step S38, the ROM update mode thread of the SCS 122 accumulates the corresponding update data stored in the update data area where the update data packet is expanded in the secondary storage device such as the HDD 1303.

  In this way, by storing the update data in the secondary storage device such as the HDD 1303, the update data stored in the secondary storage device such as the HDD 1303 even if the power is turned off during the program update. Can be used to re-execute and restore program updates.

  Progressing to step S39 following step S38, the ROM update mode thread of the SCS 122 activates the ROM update unit 430 of the SCS 122.

  Hereinafter, an example of ROM update processing by the ROM update unit 430 of the SCS 122 will be described with reference to FIG. FIG. 13 is a flowchart (part 1) for explaining the ROM update processing by the ROM update unit of the SCS.

  In step S50, the ROM update unit 430 of the SCS 122 stores update information such as a module ID, an update destination address, an update data offset, and an update data size in the update interruption information.

  Progressing to step S51 following step S50, the ROM update unit 430 of the SCS 122 accumulates data in a corresponding area of the flash ROM 204 updated by the update data in a secondary storage device such as the HDD 1303.

  Thus, by storing the data of the area to be updated in the secondary storage device such as the HDD 1303, even if the power is turned off during the program update, the data is stored in the secondary storage device such as the HDD 1303. Using the data in the updated area, it is possible to restore the state before the program is updated.

  Progressing to step S52 following step S51, the ROM update unit 430 of the SCS 122 reads the corresponding update data from the update data area in which the update data packet is expanded, and rewrites the update data from the update destination address of the flash ROM 204 with the update data. Do.

  Progressing to step S53 following step S52, the ROM update unit 430 of the SCS 122 compares the update data read in step S52 with the updated module data in the flash ROM 204 after rewriting in step S52. Then, it is determined whether or not rewriting has been performed correctly. If the ROM update unit 430 of the SCS 122 determines that the rewriting has been correctly performed (YES in step S53), the process proceeds to step S55. If the ROM updating unit 430 determines that the rewriting has not been performed correctly (NO in step S53), the process proceeds to step S54.

  In step S54, the ROM update unit 430 of the SCS 122 performs error processing. For example, the ROM update unit 430 of the SCS 122 displays an error screen on the operation panel 1310 via the ROM update mode thread of the OCS 126 when called from the ROM update mode thread of the SCS 122 as described in FIG. . Further, as will be described later, the ROM update unit 430 of the SCS 122 stores error information in a log file stored in the HDD 1303 or the like when called from the SCS rescue mode thread.

  On the other hand, in step S55, the ROM update unit 430 of the SCS 122 refers to the variable to be updated and determines whether the next update information is set. If the ROM update unit 430 of the SCS 122 determines that the next update information is set in the update target variable or the like (YES in step S55), the process from step S50 is repeated, and the update target variable or the like is updated next. If it is determined that the information is not set (NO in step S55), the process proceeds to step S56.

  In step S56, the ROM update unit 430 of the SCS 122 deletes the update information stored in the update interruption information.

  Hereinafter, an example of update data selection processing by the rescue mode thread of the SCS 122 activated in step S20 of FIG. 11 will be described with reference to FIG. FIG. 14 is a flowchart (No. 1) for explaining update data selection processing executed in the SCS rescue mode thread.

  In step S60, the rescue mode thread of the SCS 122 selects a rescue method set in advance with reference to, for example, a definition file of the multifunction peripheral 100 stored in the HDD 1303 or the like. The rescue mode thread of the SCS 122 proceeds to step S63 when “Re-execute interrupted update” is selected as the rescue method, and proceeds to step S61 when “return to the previous state for update” is selected. .

  In step S61, the rescue mode thread of the SCS 122 obtains the data of the updated area of the flash ROM 204 accumulated in step S51 of FIG. 13 from the secondary storage device such as the HDD 1303.

  Progressing to step S62 following step S61, the rescue mode thread of the SCS 122 acquires the update information stored in step S50 of FIG.

  On the other hand, in step S63, the rescue mode thread of the SCS 122 acquires the update data accumulated in step S38 of FIG. 12 from the secondary storage device such as the HDD 1303.

  Progressing to step S64 following step S63, the rescue mode thread of the SCS 122 seeks the header block at the head of the update data acquired in step S63.

  Progressing to step S65 following step S64, the rescue mode thread of the SCS 122 acquires the module ID from the header block.

  Progressing to step S66 following step S65, the rescue mode thread of the SCS 122 determines whether the module ID acquired in step S65 matches the module ID included in the update information stored in step S50 of FIG. Determine.

  If the rescue mode thread of the SCS 122 determines that the module ID acquired in step S65 matches the module ID included in the update information stored in step S50 of FIG. 13 (YES in step S66), the process proceeds to step S67. If it is determined that the module ID acquired in step S65 does not match the module ID included in the update information stored in step S50 of FIG. 13 (NO in step S66), the process proceeds to step S69.

  In step S67, the rescue mode thread of the SCS 122 acquires an update destination address, an update data offset, an update data size, and the like from the header block.

  Progressing to step S68 following step S67, the rescue mode thread of the SCS 122 sets update information including a module ID, an update destination address, an update data offset, an update data size, and the like as a variable to be updated.

  In step S69, the rescue mode thread of the SCS 122 determines whether the next header block exists. If the rescue mode thread of the SCS 122 determines that the next header block exists (YES in step S69), the process proceeds to step S70, and if it determines that the next header block does not exist (NO in step S69), the process proceeds to step S71.

  In step S70, the rescue mode thread of the SCS 122 seeks the next header block and repeats the processing from step S65.

  On the other hand, in step S71, the rescue mode thread of the SCS 122 refers to a variable to be updated and determines whether update information is set. If the rescue mode thread of the SCS 122 determines that the update information is set in the update target variable or the like (YES in step S71), the process proceeds to step S72 and determines that the update information is not set in the update target variable or the like. Then (NO in step S71), the process ends.

  In step S <b> 72, the rescue mode thread of the SCS 122 activates the ROM update unit 430 of the SCS 122.

  The ROM update unit 430 of the SCS 122 activated by the rescue mode thread of the SCS 122 performs the process shown in FIG. 13 and updates the flash ROM 204.

  Hereinafter, an example of the memory structure of the multifunction peripheral 100 will be described with reference to FIG. FIG. 15 is a diagram for illustrating an example of a memory structure.

  As shown in FIG. 15, for example, the update interruption information is included in the NVRAM space, and the ROM space corresponds to a program corresponding to the ROM monitor 410 or a program of the software group 110 as shown in FIG. 10. A rescue system, a normal system corresponding to the program of the platform 120 as shown in FIG. 3, an application 1, an application 2, and the like corresponding to each application program are included.

  Hereinafter, as shown in FIG. 15, an example of the layout of the update interruption information when the update interruption information is stored in the NVRAM space will be described with reference to FIG. FIG. 16 is a diagram (No. 1) for explaining the layout of the update interruption information when the update interruption information is stored in the NVRAM.

  As illustrated in FIG. 16, the update interruption information includes, for example, a 16-byte module ID and a 4-byte update destination address.

  Hereinafter, an example of the directory and file structure of the HDD 1303 will be described with reference to FIG. FIG. 17 is a diagram (part 1) for explaining the directory and file structure of the HDD.

  As shown in FIG. 17, the HDD 1303 has a backup directory as a directory for holding update data, and the backup directory includes backup.data as update data and / or data of an area to be updated. A bin file is stored.

  Hereinafter, another example of the directory and file structure of the HDD 1303 will be described with reference to FIG. FIG. 18 is a diagram (part 2) for explaining the directory and file structure of the HDD.

  As shown in FIGS. 15 and 16, instead of storing the update interruption information in the NVRAM 208, a ROM directory is provided in the HDD 1303 as a directory for holding the update interruption information as shown in FIG. The update interruption information file may be stored as a file including the update interruption information.

  Hereinafter, an example of the contents of the update interruption information file will be described with reference to FIG. FIG. 19 is a diagram for explaining an example of the contents of the update interruption information file.

  As illustrated in FIG. 19, the update interruption information file includes a module ID and an update destination address.

  In the first embodiment described above, for example, even if the power of the multifunction device 100 is turned off during the update of the flash ROM 204 in step S52 of FIG. 13, if the power of the multifunction device 100 is turned on next time, the general-purpose rescue OS 131 is activated. The program can be restored by restarting the update of the flash ROM 204 or returning the flash ROM 204 to the state before the update, but nothing is displayed on the operation panel 1310 of the multi-function peripheral 100. There is a problem that it is impossible to know whether or not the rescue OS 131 is activated and the program is restored (ROM update).

  Therefore, in the second embodiment, even when the general-purpose rescue OS 131 is activated, a screen related to the update of the flash ROM 204 is displayed on the operation panel 1310 to solve the above problem. In the following, points different from the first embodiment will be described, and description of the same points as the first embodiment will be omitted.

  Hereinafter, another example of the configuration of the multifunction peripheral 100 when the general-purpose rescue OS 131 is activated by the ROM monitor 410 will be described with reference to FIG. FIG. 20 is a block diagram (part 3) illustrating the configuration of the multifunction machine.

  The configuration of the multifunction device 100 illustrated in FIG. 20 includes a rescue mode thread of the OCS 126 as compared to the configuration of the multifunction device 100 illustrated in FIG. 10 according to the first embodiment.

  The rescue mode thread of the OCS 126 controls an operation panel (operation panel 1310) serving as information transmission means between the operator and the main body control, and displays, for example, a screen described later on the operation panel 1310.

  Hereinafter, an example of the OS switching process at the time of boot in the second embodiment will be described with reference to FIG. FIG. 21 is a flowchart (part 2) for explaining the OS switching process at the time of booting.

  The process from step S100 to step S109 in FIG. 21 is the same as the process from step S10 to step S19 in FIG.

  Progressing to step S110 following step S109, the rescue mode thread of the OCS 126 displays a startup screen on the operation panel 1310 (see FIG. 22).

  As shown in FIG. 22, by displaying a startup screen on the operation panel 1310, for example, the user can be informed that the startup is in the rescue mode.

  Proceeding to step S111 following step S110, the SCS 122 activates a rescue mode thread.

  The rescue mode thread of the SCS 122 performs processing as shown in FIG. 14 and activates the ROM update unit 430 of the SCS 122.

  Hereinafter, another example of ROM update processing by the ROM update unit 430 of the SCS 122 will be described with reference to FIG. FIG. 23 is a flowchart (part 2) for explaining the ROM update processing by the ROM update unit of the SCS.

  In step S120, the ROM update unit 430 of the SCS 122 stores update information such as a module ID, an update destination address, an update data offset, and an update data size in the update interruption information.

  Progressing to step S121 following step S120, the ROM update unit 430 of the SCS 122 accumulates data in the corresponding area of the flash ROM 204 updated by the update data in a secondary storage device such as the HDD 1303.

  Thus, by storing the data of the area to be updated in the secondary storage device such as the HDD 1303, even if the power is turned off during the program update, the data is stored in the secondary storage device such as the HDD 1303. The flash ROM 204 can be restored to the state before the program is updated using the data in the updated area.

  Progressing to step S122 following step S121, the ROM update unit 430 of the SCS 122 reads the corresponding update data from the update data area in which the update data packet is expanded, and rewrites the update data from the update destination address of the flash ROM 204 with the update data. Do.

  Progressing to step S123 following step S122, the ROM update unit 430 of the SCS 122 determines whether or not the rescue mode thread of the OCS 126 is activated.

  If the ROM update unit 430 of the SCS 122 determines that the rescue mode thread of the OCS 126 is activated (YES in step S123), the process proceeds to step S124, and determines that the rescue mode thread of the OCS 126 is not activated (in step S123). NO), the process proceeds to step S125.

  The ROM update unit 430 of the SCS 122 determines whether or not the rescue mode thread of the OCS 126 is activated with reference to, for example, environment variables.

  In step S124, the ROM update unit 430 of the SCS 122 displays a recovering screen on the operation panel 1310 via the rescue mode thread of the OCS 126 (see FIG. 24).

  As shown in FIG. 24, by displaying a screen during recovery of the flash ROM 204 on the operation panel 1310, the user should update the ROM and update the ROM, so do not turn off the power. You can be notified.

  In step S125, the ROM update unit 430 of the SCS 122 compares the update data read in step S122 with the updated module data in the flash ROM 204 after the rewrite in step S122, so that the rewrite is performed correctly. Judge whether or not. If the ROM updating unit 430 of the SCS 122 determines that the rewriting has been correctly performed (YES in step S125), the process proceeds to step S128. If the ROM updating unit 430 determines that the rewriting has not been performed correctly (NO in step S125), the process proceeds to step S126.

  In step S126, the ROM update unit 430 of the SCS 122 determines whether the rescue mode thread of the OCS 126 is activated.

  When the ROM update unit 430 of the SCS 122 determines that the rescue mode thread of the OCS 126 is activated (YES in step S126), the ROM update unit 430 proceeds to step S127 and determines that the rescue mode thread of the OCS 126 is not activated (in step S126). NO), the process is terminated.

  In step S127, the ROM update unit 430 of the SCS 122 displays an error screen on the operation panel 1310 via the rescue mode thread of the OCS 126 (see FIG. 25).

  As shown in FIG. 25, an error screen is displayed on the operation panel 1310 to notify the user that an error has occurred during ROM update and that the service center needs to be contacted. it can.

  On the other hand, in step S128, the ROM update unit 430 of the SCS 122 refers to the variable to be updated and determines whether the next update information is set. If the ROM update unit 430 of the SCS 122 determines that the next update information is set in the update target variable or the like (YES in step S128), the process from step S120 is repeated, and the update target variable or the like is updated next. If it is determined that the information is not set (NO in step S128), the process proceeds to step S129.

  In step S129, the ROM update unit 430 of the SCS 122 deletes the update information stored in the update interruption information.

  In the above-described first and second embodiments, the recovery method when the update of the flash ROM 204 is interrupted has been described. However, in the third and fourth embodiments, the update is performed after the flash ROM 204 is updated. A description will be given of a recovery method and the like when a part or all of the functions of the multifunction peripheral 100 are unusable or unstable due to a combination of a program that has been performed and a program that has not been updated. . Hereinafter, differences from the first and second embodiments will be described, and the same points as the first and second embodiments will not be described.

  Hereinafter, another example of the configuration of the multifunction machine 100 when the general-purpose rescue OS 131 is activated by the ROM monitor 410 will be described with reference to FIG. FIG. 26 is a block diagram (part 4) illustrating the configuration of the multifunction machine.

  The configuration of the MFP 100 shown in FIG. 26 includes an NCS 128 rescue mode thread and an RRU application 117 as compared to the configuration of the MFP 100 shown in FIG.

  The rescue mode thread of the NCS 128 receives a ROM update data packet of the flash memory connected to the network, for example, from a host computer of a multifunction device developer or a third vendor of an application developer.

  Further, as described above, the RRU application 17 expands the update data packet received via the network by the NCS 128 into update data, and stores the update data in an update data area such as the SDRAM 203 secured by the rescue mode thread of the MCS 125. The processing to do is performed.

  Hereinafter, an example of the OS switching process at the time of boot in the third embodiment will be described with reference to FIG. FIG. 27 is a flowchart (part 3) for explaining the OS switching process at the time of booting.

  When the power is turned on, the multifunction peripheral 100 activates the ROM monitor 410 in step S200.

  Progressing to step S201 following step S200, the ROM monitor 410 determines whether a maintenance flag is stored in the update interruption information. If ROM monitor 410 determines that the maintenance flag is stored in the update interruption information (YES in step S201), it proceeds to step S210 and determines that the maintenance flag is not stored in the update interruption information (NO in step S201). ), The process proceeds to step S202.

  In step S202, the ROM monitor 410 activates the general-purpose OS 121.

  Progressing to step S203 following step S202, the ROM monitor 410 determines whether or not the general-purpose OS 121 started in step S202 has started normally. If the ROM monitor 410 determines that the general-purpose OS 121 has started normally (YES in step S203), the process proceeds to step S204. If the ROM monitor 410 determines that the general-purpose OS 121 has not started normally (NO in step S203), the process proceeds to step S208.

  In step S <b> 204, the general-purpose OS 121 activates the program activation unit 420.

  Progressing to step S205 following step S204, the service activation unit 422 included in the program activation unit 420 activates the platform 120.

  Progressing to step S206 following step S205, the application activation unit 423 included in the program activation unit 420 activates the application 130.

  Progressing to step S207 following step S206, the program activation unit 420 determines whether or not all the programs to be activated by the platform 120 and the application 130 activated in steps S205 and S206 have been activated normally. If the program activation unit 420 determines that all the programs to be activated by the platform 120 and the application 130 activated in steps S205 and S206 have been activated normally (YES in step S207), the program is terminated, and steps S205 and S206 are completed. If it is determined that all the programs to be started by the platform 120 and the application 130 that have been started in step S1 have not started normally (NO in step S207), the process proceeds to step S208.

  In step S208, the ROM monitor 410 or the program activation unit 420 stores the maintenance flag in the update interruption information.

  Progressing to step S209 following step S208, the ROM monitor 410 or the program activation unit 420 reboots the multi-function device 100.

  On the other hand, in step S210, the ROM monitor 410 stores a rescue boot flag in the startup information.

  Progressing to step S211 following step S210, the ROM monitor 410 activates the general-purpose rescue OS 131.

  Progressing to step S212 following step S211, the general-purpose rescue OS 131 activated in step S211 activates the program activation unit 420.

  In step S213 following step S212, the service activation unit 422 included in the program activation unit 420 refers to the activation time information. If the rescue boot flag is stored, the service activation unit 422 adds a rescue mode option to the platform 120. Start up.

  Progressing to step S214 following step S213, the rescue mode thread of the OCS 126 displays a recovery menu screen shown in FIG. 28 described later on the operation panel 1310. In the following description, it is assumed that “perform” is selected by the user on the screen shown in FIG.

  Progressing to step S215 following step S214, the rescue mode thread of the OCS 126 stores the maintenance content flag in the update interruption information according to the recovery content (recovery method) selected on the screen of FIG.

  Progressing to step S216 following step S215, the SCS 122 performs a maintenance content flag check process as shown in FIG. 29 described later.

  Hereinafter, an example of the recovery menu screen will be described with reference to FIG. FIG. 28 is a diagram for showing a recovery menu screen.

  As shown in FIG. 28A, the rescue mode thread of the OCS 126 first displays on the operation panel 1310 a selection screen as to whether or not to perform the dissemination work. When the rescue mode thread of the OCS 126 determines that the user has selected “perform”, the recovery content selection screen as shown in FIG. 28B is displayed on the operation panel 1310, and the user selects “not perform”. If it is determined that the restoration work has been performed, a screen indicating that the restoration work is to be stopped as shown in FIG.

  Hereinafter, an example of the maintenance content flag check process by the SCS 122 will be described with reference to FIG. FIG. 29 is a flowchart for explaining maintenance content flag check processing by the SCS.

  In step S220, the SCS 122 checks the maintenance content flag stored in the update interruption information in step S215 of FIG. When the SCS 122 checks the maintenance content flag and determines that the user has selected “send update data packet from remote host” as the recovery content on the screen (B) of FIG. 28, the process proceeds to step S222, and FIG. If it is determined on the screen (B) that the user has selected “return to software stored in the device” as the recovery content, the process proceeds to step S221.

  In step S221, the SCS 122 activates the rescue mode thread of the SCS 122.

  On the other hand, in step S222, the SCS 122 determines whether an update data selection request has been received from the RRU application 117. If SCS 122 determines that an update data selection request has been received from RRU application 117 (YES in step S222), it proceeds to step S223, and determines that no update data selection request has been received from RRU application 117 (NO in step S222). ), The process of step S222 is repeated.

  In step S223, the SCS 122 activates the ROM update mode thread of the SCS 122.

  Although omitted from FIG. 29, if the SCS 122 determines in step S220 that the user has selected “send update data packet from remote host” as the recovery content on the screen (B) of FIG. The rescue mode thread may display a reception standby screen on the operation panel 1310 (see FIG. 30).

  Hereinafter, an example of update data selection processing executed in the rescue mode thread of the SCS 122 activated in step S221 of FIG. 29 will be described with reference to FIG. FIG. 31 is a flowchart for explaining update data selection processing executed in the SCS rescue mode thread.

  In step S230, the rescue mode thread of the SCS 122 acquires a shipping program that operates normally from the HDD 1303 or the like.

  Progressing to step S231 following step S230, the rescue mode thread of the SCS 122 obtains module information such as a module ID, an update destination address, and an update data size of a shipping program operating normally from the HDD 1303 or the like.

  Progressing to step S232 following step S231, the rescue mode thread of the SCS 122 activates the ROM update unit 430 of the SCS 122.

  As shown in FIG. 31, the program at the time of shipment is acquired, the ROM update unit 430 of the SCS 122 is activated, and the flash memory 204 is updated to return the program to the state at the time of shipment that was operating normally. be able to.

  Hereinafter, an example of update data selection processing executed in the ROM update mode thread of the SCS 122 activated in step S223 of FIG. 29 will be described with reference to FIG. FIG. 32 is a flowchart (part 2) for explaining the update data selection process executed by the SCS ROM update mode thread.

  In step S240, the ROM update mode thread of the SCS 122 seeks the header block at the beginning of the update data based on the start address of the update data area in which the update data packet notified from the RRU application 117 is expanded.

  Progressing to step S241 following step S240, the ROM update mode thread of the SCS 122 acquires the module ID from the header block.

  Progressing to step S242 following step S241, the ROM update mode thread of the SCS 122 acquires an update destination address, an update data offset, an update data size, and the like from the header block.

  Progressing to step S243 following step S242, the ROM update mode thread of the SCS 122 sets update information including a module ID, an update destination address, an update data offset, an update data size, and the like as a variable to be updated.

  Progressing to step S244 following step S243, the ROM update mode thread of the SCS 122 determines whether or not the next header block exists. If the ROM update mode thread of the SCS 122 determines that the next header block exists (YES in step S244), the process proceeds to step S245, and if it determines that the next header block does not exist (NO in step S244), the process proceeds to step S246. .

  In step S245, the ROM update mode thread of the SCS 122 seeks the next header block and repeats the processing from step S241.

  In step S246, the ROM update mode thread of the SCS 122 refers to a variable to be updated and determines whether update information is set. If the ROM update mode thread of the SCS 122 determines that update information is set in the update target variable or the like (YES in step S246), the process proceeds to step S247, and update information is not set in the update target variable or the like. If determined (NO in step S246), the process is terminated.

  In step S247, the ROM update mode thread of the SCS 122 accumulates the corresponding update data stored in the update data area in which the update data packet is expanded in the secondary storage device such as the HDD 1303.

  Proceeding to step S248 following step S247, the ROM update mode thread of the SCS 122 activates the ROM update unit 430 of the SCS 122.

  As shown in FIG. 29 and FIG. 32, the update data is acquired from the remote host, the ROM update mode thread of the SCS 122 and the ROM update unit 430 of the SCS 122 are activated, and the flash memory 204 is updated to update the program. It can be corrected.

  Hereinafter, another example of ROM update processing by the ROM update unit 430 of the SCS 122 will be described with reference to FIG. FIG. 33 is a flowchart (No. 3) for explaining the ROM update process by the ROM update unit of the SCS.

  In step S250, the ROM update unit 430 of the SCS 122 stores update information such as a module ID, an update destination address, an update data offset, and an update data size in the update interruption information.

  Progressing to step S251 following step S250, the ROM update unit 430 of the SCS 122 accumulates data in a corresponding area of the flash ROM 204 updated by the update data in a secondary storage device such as the HDD 1303.

  Progressing to step S252 following step S251, the ROM update unit 430 of the SCS 122 reads the corresponding update data from the update data area in which the update data packet is expanded, and rewrites the update data from the update destination address of the flash ROM 204 with the update data. Do.

  Progressing to step S253 following step S252, the ROM update unit 430 of the SCS 122 displays a recovery screen on the operation panel 1310 via the rescue mode thread of the OCS 126 (see FIG. 24).

  Progressing to step S254 following step S253, the ROM update unit 430 of the SCS 122 compares the update data read in step S252 with the updated module data in the flash ROM 204 after rewriting in step S252. Then, it is determined whether or not rewriting has been performed correctly. If the ROM update unit 430 of the SCS 122 determines that the rewriting has been performed correctly (YES in step S254), the process proceeds to step S256. If the ROM updating unit 430 determines that the rewriting has not been performed correctly (NO in step S254), the process proceeds to step S255.

  In step S255, the ROM update unit 430 of the SCS 122 displays an error screen on the operation panel 1310 via the rescue mode thread of the OCS 126 (see FIG. 25).

  On the other hand, in step S256, the ROM update unit 430 of the SCS 122 refers to a variable to be updated and determines whether the next update information is set. If the ROM update unit 430 of the SCS 122 determines that the next update information is set in the update target variable or the like (YES in step S256), the process from step S250 is repeated, and the update target variable or the like is updated next. If it is determined that the information is not set (NO in step S256), the process proceeds to step S257.

  In step S257, the ROM update unit 430 of the SCS 122 deletes the update information stored in the update interruption information.

  Note that the ROM update unit 430 of the SCS 122 performs processing for determining whether or not the rescue mode thread of the OCS 126 is activated as illustrated in FIG. 23 of the second embodiment, and if the rescue mode thread of the OCS 126 is activated, You may make it perform the process of step S253 or step S255. In FIG. 33, for the sake of simplification of explanation, it is assumed that the rescue mode thread of the OCS 126 is activated.

  Hereinafter, an example of processing in the case where there is an application 130 or the like that is not operating normally after the MFP 100 is normally activated and the mode is shifted to the rescue mode will be described with reference to FIG. FIG. 34 is a flowchart for explaining the rescue mode transition processing after normal startup.

  In step S260, the normal mode thread of the OCS 126 determines whether or not the rescue button on the screen (see FIG. 35) displayed on the operation panel 1310 has been pressed. If the normal mode thread of the OCS 126 determines that the rescue button on the screen displayed on the operation panel 1310 has been pressed (YES in step S260), the process proceeds to step S261 and determines that the rescue button has not been pressed (step S260). NO), the process of step S260 is repeated.

  In step S261, the normal mode thread of the OCS 126 displays a confirmation screen for entering the rescue mode on the operation panel 1310 (see FIG. 36).

  Progressing to step S262 following step S261, the normal mode thread of the OCS 126 determines whether or not the execution button on the rescue mode transition confirmation screen of FIG. 36 has been pressed. If the normal mode thread of OCS 126 determines that the execute button on the rescue mode transition confirmation screen of FIG. 36 has been pressed (YES in step S262), the process proceeds to step S263, and if it is determined that the cancel button has been pressed (NO in step S262). The screen shown in FIG. 35 is displayed on the operation panel 1310, and the processing from step S260 is repeated.

  In step S263, the normal mode thread of the OCS 126 notified that the execution button on the rescue mode transition confirmation screen has been pressed, for example, the normal mode thread of the SCS 122 stores the maintenance flag in the update interruption information.

  Progressing to step S264 following step S263, for example, the ROM monitor 410 or the program activation unit 420 that has received the notification from the normal mode thread of the SCS 122 reboots the multi-function device 100.

  The multifunction peripheral 100 rebooted by the process shown in FIG. 34 performs the process as shown in FIG.

  Hereinafter, another example of the layout of the update interruption information when the update interruption information is stored in the NVRAM space will be described with reference to FIG. FIG. 37 is a diagram (No. 2) for explaining the layout of the update interruption information when the update interruption information is stored in the NVRAM.

  As shown in FIG. 37, the update interruption information includes, for example, a 16-byte module ID, a 4-byte update destination address, a 1-byte maintenance flag, and a 1-byte maintenance content flag.

  As shown in FIGS. 18 and 19, when the update interruption information is stored in the HDD 1303, a maintenance flag or a maintenance content flag may be included in the update interruption information file, for example.

  Hereinafter, another example of the directory and file structure of the HDD 1303 will be described with reference to FIG. FIG. 38 is a diagram (No. 3) for explaining the directory and file structure of the HDD.

  As shown in FIG. 38, the HDD 1303 has a store directory as a directory for storing normally operating shipping data (programs), and each module constituting the application 130, the platform 120, and the like is stored in the store directory. The data (program) at the time of shipment corresponding to the above and the module information file related to the module are stored.

  Hereinafter, as an example of the module information file, an example of the contents of the module information file of the printer application at the time of shipment that operates normally will be described with reference to FIG. FIG. 39 is a diagram for explaining an example of the contents of the module information file of the printer application at the time of shipment that operates normally.

  As shown in FIG. 39, the module information file includes a module ID, an update destination address, and a module size.

  In FIG. 28B of the third embodiment, when only “return to the software stored in the device” can be displayed or selected, the NCS 128 in the configuration of the multifunction peripheral 100 shown in FIG. The rescue mode thread and the RRU application 117 may not be included.

  In the third embodiment described above, as illustrated in FIG. 33, the ROM update unit 430 of the SCS 122 displays the recovery information on the operation panel 1310 as a recovery-in-progress screen via the rescue mode thread of the OCS 126. However, the recovery information may be displayed on the operation panel 1310, and the ROM update unit 430 of the SCS 122 may transmit the recovery information to the remote host via the rescue mode thread of the NCS 128.

  Hereinafter, another example of ROM update processing by the ROM update unit 430 of the SCS 122 will be described with reference to FIG. FIG. 40 is a flowchart (part 4) for explaining the ROM update process by the ROM update unit of the SCS.

  In step S300, the ROM update unit 430 of the SCS 122 stores update information such as a module ID, an update destination address, an update data offset, and an update data size in the update interruption information.

  Progressing to step S301 following step S300, the ROM update unit 430 of the SCS 122 accumulates the data in the corresponding area of the flash ROM 204 updated by the update data in a secondary storage device such as the HDD 1303.

  Progressing to step S302 following step S301, the ROM update unit 430 of the SCS 122 reads the corresponding update data from the update data area in which the update data packet is expanded, and rewrites the update data from the update destination address of the flash ROM 204 with the update data. Do.

  Progressing to step S303 following step S302, the ROM update unit 430 of the SCS 122 displays a recovery screen on the operation panel 1310 via the rescue mode thread of the OCS 126 (see FIG. 24).

  Progressing to step S304 following step S303, the ROM update unit 430 of the SCS 122 determines whether or not the rescue mode thread of the NCS 128 is activated.

  If the ROM update unit 430 of the SCS 122 determines that the rescue mode thread of the NCS 128 is activated (YES in step S304), the process proceeds to step S305, and determines that the rescue mode thread of the NCS 128 is not activated (in step S304). NO), the process proceeds to step S306.

  The ROM update unit 430 of the SCS 122 determines whether or not the rescue mode thread of the NCS 128 is activated with reference to, for example, environment variables.

  In step S305, the ROM update unit 430 of the SCS 122 transmits the recovery information to the remote host via the rescue mode thread of the NCS 128.

  In step S306, the ROM update unit 430 of the SCS 122 compares the update data read in step S302 with the updated module data in the flash ROM 204 after the rewrite in step S302, and the correct rewrite is performed. Judge whether or not. If the ROM update unit 430 of the SCS 122 determines that the rewriting has been correctly performed (YES in step S306), the process proceeds to step S308. If the ROM updating unit 430 determines that the rewriting has not been performed correctly (NO in step S306), the process proceeds to step S307.

  In step S307, the ROM update unit 430 of the SCS 122 displays an error screen on the operation panel 1310 via the rescue mode thread of the OCS 126 (see FIG. 25).

  On the other hand, in step S308, the ROM update unit 430 of the SCS 122 refers to the variable to be updated and determines whether the next update information is set. If the ROM update unit 430 of the SCS 122 determines that the next update information is set in the variable to be updated (YES in step S308), the process from step S300 is repeated to update the variable to be updated next. If it is determined that the information is not set (NO in step S308), the process proceeds to step S309.

  In step S309, the ROM update unit 430 of the SCS 122 deletes the update information stored in the update interruption information.

  Note that the ROM update unit 430 of the SCS 122 performs processing for determining whether or not the rescue mode thread of the OCS 126 is activated as illustrated in FIG. 23 of the second embodiment, and if the rescue mode thread of the OCS 126 is activated, You may make it perform the process of step S303 or step S307. In FIG. 40, for the sake of simplification of description, it is assumed that the rescue mode thread of the OCS 126 is activated.

  The preferred embodiments of the present invention have been described in detail above, but the present invention is not limited to such specific embodiments, and various modifications can be made within the scope of the gist of the present invention described in the claims.・ Change is possible.

FIG. 10 is a diagram for explaining an example in which some of the functions of the image forming apparatus become unusable after the program update is interrupted. FIG. 4 is a diagram for explaining an example in which some of the functions of the image forming apparatus are disabled due to version mismatch. FIG. 2 is a block diagram (part 1) illustrating a configuration of a multifunction machine. FIG. 2 is a block diagram illustrating a hardware configuration of a multifunction machine. FIG. 6 is a diagram (part 1) for describing the entire process of remote ROM update; It is FIG. (2) for demonstrating the whole process of remote ROM update. FIG. 10 is a data structure diagram after development of an update data packet received by the multi-function peripheral. 3 is a block diagram illustrating an example of a configuration of a multifunction machine starting unit. FIG. It is a block diagram which shows an example of a structure of a ROM update part. FIG. 3 is a block diagram (part 2) illustrating the configuration of the multifunction machine. It is a flowchart for demonstrating OS switching processing at the time of booting. It is a flowchart (the 1) for demonstrating the update data selection process performed with the ROM update mode thread | sled of SCS. It is a flowchart (the 1) for demonstrating the ROM update process by the ROM update part of SCS. It is a flowchart (the 1) for demonstrating the update data selection process performed with the rescue mode thread | sled of SCS. It is a figure for showing an example of a memory structure. FIG. 11 is a diagram (part 1) for describing a layout of update interruption information when update interruption information is stored in NVRAM; FIG. 3 is a diagram (part 1) for explaining a directory and file structure of an HDD. FIG. 6 is a diagram (part 2) for explaining the directory and file structure of the HDD; It is a figure for demonstrating an example of the content of the update interruption information file. FIG. 6 is a block diagram (part 3) illustrating the configuration of the multifunction machine. It is a flowchart (the 2) for demonstrating OS switching processing at the time of boot. It is a figure for showing a screen at the time of starting. It is a flowchart (the 2) for demonstrating the ROM update process by the ROM update part of SCS. It is a figure for showing the in-restoration screen. It is a figure for showing an error screen. FIG. 10 is a block diagram (part 4) illustrating the configuration of the multifunction machine. 12 is a flowchart (part 3) for describing OS switching processing at the time of booting; It is a figure for showing a recovery menu screen. It is a flowchart for demonstrating the maintenance content flag check process by SCS. It is a figure for showing a reception waiting screen. It is a flowchart for demonstrating the update data selection process performed with the rescue mode thread | sled of SCS. It is a flowchart (the 2) for demonstrating the update data selection process performed with the ROM update mode thread | sled of SCS. It is a flowchart (the 3) for demonstrating the ROM update process by the ROM update part of SCS. It is a flowchart for demonstrating the rescue mode transfer process after normal starting. It is a figure for showing the screen after normal starting. It is a figure for showing a rescue mode transfer confirmation screen. FIG. 10 is a diagram (part 2) for explaining the layout of update interruption information when update interruption information is stored in NVRAM; FIG. 6 is a third diagram for explaining the directory and file structure of the HDD; It is a figure for demonstrating an example of the content of the module information file of the printer application at the time of shipment which operates normally. It is a flowchart (the 4) for demonstrating the ROM update process by the ROM update part of SCS.

Explanation of symbols

100 MFP 111 Printer application 112 Copy application 113 Fax application 114 Scanner application 115 Net file application 117 Remote ROM update application (RRU application)
121 General-purpose OS
122 SCS
123 SRM
124 ECS
125 MCS
126 OCS
127 FCS
128 NCS
131 General-purpose rescue OS
410 ROM monitor 420 Program activation unit 422 Service layer activation unit 423 Application activation unit 424 Activation information setting unit 430 ROM update unit 431 Update information storage unit 432 Area data storage unit 433 ROM update unit 434 Update information deletion unit 435 Display control unit 436 Transmission Control unit

Claims (27)

Program storage means for storing a program, update data receiving means for receiving update data relating to the program stored in the program storage means, and corresponding correspondence stored in the program storage means based on the update data An information processing apparatus having program update means for updating a program,
An update interruption determination means for determining whether or not the update of the program in the program update means was interrupted when the information processing apparatus was activated last time;
An operating system activation unit that activates a corresponding operating system according to a determination result in the update interruption determination unit;
First program recovery means for recovering a program stored in the program storage means;
Screen control means for controlling the screen according to the operating system started by the operating system start means;
An information processing apparatus comprising:   The information processing apparatus according to claim 1, wherein the screen is a recovering screen indicating that the program stored in the program storage unit is being recovered.   The information processing apparatus according to claim 1, wherein the screen is an error screen indicating that restoration of a program stored in the program storage unit has failed.   The information processing apparatus according to claim 1, wherein the screen is a startup screen indicating that the operating system is started. Program storage means for storing a program, update data receiving means for receiving update data relating to the program stored in the program storage means, and corresponding correspondence stored in the program storage means based on the update data An information processing apparatus having program update means for updating a program,
A reboot determination unit that determines whether the information processing apparatus has been rebooted in order to restore the program stored in the program storage unit when the information processing apparatus was previously activated;
In response to the determination result in the reboot determination unit, an operating system activation unit that activates a corresponding operating system;
Second program recovery means for recovering the program stored in the program storage means;
Screen control means for controlling the screen according to the operating system started by the operating system start means;
An information processing apparatus comprising:   The information processing apparatus according to claim 5, wherein the screen is a selection screen that allows a user to select whether or not to restore a program stored in the program storage unit.   The information processing apparatus according to claim 5, wherein the screen is a recovery content selection screen that allows a user to select a recovery content of a program stored in the program storage unit.   The information processing apparatus according to claim 5, wherein the screen is a recovery stop screen indicating that the service center is desired to stop the recovery work.   The information processing apparatus according to claim 5, wherein the screen is a reception waiting screen indicating that the update data is waiting to be received.   The information processing apparatus according to claim 5, wherein the screen is a screen after the information processing apparatus is normally activated.   6. The information processing apparatus according to claim 5, wherein the screen is a recovery mode transition confirmation screen for allowing the user to confirm that the mode is shifted to a recovery mode for recovering the program stored in the program storage unit. .   The information processing apparatus according to claim 5, wherein the screen is a recovering screen indicating that the program stored in the program storage unit is being recovered.   6. The information processing apparatus according to claim 5, wherein the screen is an error screen indicating that restoration of a program stored in the program storage unit has failed.   The information processing apparatus according to claim 1, wherein the information processing apparatus is an image forming apparatus that forms an image. An update data receiving stage for receiving update data relating to a program stored in the program storage means, and a corresponding program stored in the program storage means based on the update data received in the update data receiving stage A program recovery method in an information processing apparatus having a program update stage to be updated,
An update interruption determination stage for determining whether the update of the program was interrupted when the information processing apparatus was activated last time;
In response to the determination result in the update interruption determination step, an operating system startup step of starting the corresponding operating system,
A startup screen display stage for displaying a startup screen indicating that the operating system has been started; and
A first program recovery stage for recovering the program stored in the program storage means;
A program recovery method comprising:   16. The program restoration method according to claim 15, further comprising a restoring screen display step of displaying a restoring screen indicating that the program stored in the program storage means is being restored.   16. The program recovery method according to claim 15, further comprising an error screen display step of displaying an error screen indicating that the recovery of the program stored in the program storage means has failed. An update data receiving stage for receiving update data relating to a program stored in the program storage means, and a corresponding program stored in the program storage means based on the update data received in the update data receiving stage A program recovery method in an information processing apparatus having a program update stage to be updated,
A reboot determination stage for determining whether the information processing apparatus has been rebooted in order to restore the program stored in the program storage means when the information processing apparatus was last activated;
In response to the determination result in the reboot determination step, an operating system start step for starting the corresponding operating system,
A second program recovery stage for recovering the program stored in the program storage means;
A selection screen display step for displaying a selection screen for allowing the user to select whether or not to restore the program stored in the program storage means;
A program recovery method comprising:   19. The program recovery method according to claim 18, further comprising a recovery content selection screen display step of displaying a recovery content selection screen for allowing a user to select a recovery content of a program stored in the program storage means.   19. The program recovery method according to claim 18, further comprising a recovery cancellation screen display step for displaying a recovery cancellation screen indicating that the service center is desired to be canceled in order to cancel the recovery operation.   19. The program recovery method according to claim 18, further comprising a reception standby screen display step of displaying a reception standby screen indicating that the update data is waiting to be received.   19. The program restoration method according to claim 18, further comprising a screen display step after normal startup for displaying a screen after normal startup of the information processing apparatus.   The system further comprises a recovery mode transition confirmation screen display step for displaying a recovery mode transition confirmation screen for allowing the user to confirm the transition to the recovery mode for recovering the program stored in the program storage means. Item 19. The program recovery method according to Item 18.   19. The program restoration method according to claim 18, further comprising a restoring screen display step of displaying a restoring screen indicating that the program stored in the program storage means is being restored.   19. The program recovery method according to claim 18, further comprising an error screen display step of displaying an error screen indicating that the recovery of the program stored in the program storage means has failed.   A program recovery program for causing a computer to execute the program recovery method according to any one of claims 15 to 25.   A computer-readable recording medium on which the program recovery program according to claim 26 is recorded.

Images