Method of updating firmware without affecting initialization...

Electrical computers and digital processing systems: support – Digital data processing system initialization or configuration

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C713S100000, C709S222000, C710S010000

Reexamination Certificate

active

06237091

ABSTRACT:

FIELD OF INVENTION
This invention relates generally to microprocessor controlled devices and more specifically to modification of firmware without requiring the device to be shut down and without requiring an overall system reset.
BACKGROUND OF THE INVENTION
In many devices controlled by a microprocessor, there is a need for occasional modification or updates to the firmware. Historically, firmware was stored in a read-only-memory (ROM), and firmware modification was accomplished by replacing one or more ROMs. Replacement of ROMs typically required at least turning power off for a product and often required partial disassembly of a product. More recently, various types of programmable (write-once) or rewriteable nonvolatile memory is used, or sometimes battery powered volatile memory may be used. It is now common to send firmware updates electronically to a device and have the device modify or replace its own firmware. For example, modem firmware updates may be communicated over a telephone line and a modem may update its firmware without requiring opening of the modem's housing.
Typically, updating firmware in a running system may erase or change information that needs to remain unchanged until the next system reset. Typically, updating firmware in one device of a large system may require the entire system to be reset or rebooted. There is a need in some systems for the ability to update firmware within one device but to maintain integrity of some data and to continue operation without requiring an overall system reset or reboot. The following discussion provides two examples of devices where there is a need to preserve data during a firmware update. The first set of examples involves data being gathered and transmitted during initialization after a system reset. The second set of examples involves data that a device may need to communicate to other devices, or data that may affect external operation.
Many computer based systems undergo an automatic configuration process during an initialization process after power-on or during a reboot process. Typically, this requires all devices to run various initialization processes simultaneously. For example, for Intel compatible personal computers, one industry specification for automatically configuring I/O boards for the ISA bus is called the Plug and Play ISA Standards. For ISA Plug and Play, each compatible I/O card has a unique identifier that includes a vendor identifier and a serial number. Each compatible I/O card can read its own identifier. The host computer first places all the cards into a configuration mode. Then the host computer drives a line with a series of transitions indicating sequential bit positions within each identifier. As a result of interaction between the host computer and the I/O cards, one card is isolated and assigned a logical device number. The sequence is then repeated to isolate another card and so forth until all cards have been assigned a logical device number.
Another common interface standard is the Small Computer System Interface (SCSI). SCSI also requires a unique ID for each device. An industry group has proposed a set of specifications, called Plug and Play SCSI, which among other things provides automatic assignment of unique SCSI ID's. The particular protocol for assignment of unique ID's is called SCSI Configured AutoMagically (SCAM). Each SCAM compatible device has a default ID saved in a nonvolatile device memory. A SCAM master device first commands each of the other SCAM devices, one at a time, to go into an inactive state. Then, the master device uses a protocol similar to the protocol for ISA Plug and Play to isolate each device for assignment of a SCSI address.
There are other configuration protocols used by peripheral devices. If multiple devices are on one input/output port, devices may automatically configure themselves, at power-on, as primary and secondary devices. A device may need to record its own status (primary or secondary) and whether or not another device is sharing the same I/O cable.
In the second set of examples, some information that a device shares with other devices, or data that the device uses for various control functions, may change when firmware is updated. If the information is communicated to other devices only during power-on or reboot, then the information used by a device after a firmware update may be inconsistent or inappropriate. A system reboot may then be necessary. For example, consider again an identifier. Part of an identifier may indicate a firmware version or date code. Operating system software or other system devices may poll devices, at power-on or system reboot, and record a list of device identification numbers. Applications software may read such a list, and applications software may later refer to a specific device identifier. If a firmware update changes a device identifier, for example by changing a firmware version number, a system reboot may be required to update information gathered by the operating system or other system devices during system reboot. As an alternative example, consider a value, stored in firmware, that is written to a register of a control circuit during reset. If this value changes during a firmware update and the firmware is restarted, the control circuit output may change inappropriately.
From the above examples, there is a need for firmware updates that are transparent to a computer system or operator, so that a system reboot is not required.
SUMMARY OF THE INVENTION
A firmware controlled device, in accordance with the invention, saves status and configuration information in a separate portion of memory that is not affected by a firmware update. In addition, information that may change during a firmware update, and may need to remain constant, is saved in the separate portion of memory that is not affected by a firmware update. In one example embodiment, the data in the separate portion of memory are overwritten during a hard reset (power on reset or overall system reset). In a second example embodiment, data are copied to the separate portion of memory at the beginning of a firmware update.
In the first example embodiment, a reset process for the firmware controlled device is divided into two portions. In a first portion of the device reset process, the contents of the separate portion of memory are updated, either from firmware or by interaction with other devices. In a second portion of the device reset process, all other reset functions are performed. The first portion of the reset process is performed only during a power-on reset, or in response to an overall system reset. In particular, the first portion of the device reset process is not performed after a firmware update.
In the second example embodiment, data that needs to remain constant are copied to the separate portion of memory as part of a firmware update process. Then, as part of a reset process, the device checks to see if a firmware update has occurred. If a firmware update has occurred, the data in the separate portion of memory are copied to the appropriate destinations, and the data in the separate portion of memory are cleared.
As a result, for either example embodiment, the contents of the separate portion of memory are not disturbed during or after a firmware update, and a system reboot is not necessary after a device firmware update.


REFERENCES:
patent: 4799145 (1989-01-01), Goss et al.
patent: 4954941 (1990-09-01), Redman
patent: 5155837 (1992-10-01), Liu et al.
patent: 5210854 (1993-05-01), Beaverton et al.
patent: 5268928 (1993-12-01), Herh et al.
patent: 5317723 (1994-05-01), Heap et al.
patent: 5450589 (1995-09-01), Maebayashi et al.
patent: 5519869 (1996-05-01), Payne et al.
patent: 5555418 (1996-09-01), Nilsson et al.
patent: 5566335 (1996-10-01), Nash et al.
patent: 5568358 (1996-10-01), Shelton
patent: 5596738 (1997-01-01), Pope
patent: 5623604 (1997-04-01), Russell et al.
patent: 5675814 (1997-10-01), Pearce
patent: 5682533 (1997-10-01), Siljestroemer
patent: 5764992 (1998-06-01), Kullick et al.
patent: 5781921

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Method of updating firmware without affecting initialization... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Method of updating firmware without affecting initialization..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of updating firmware without affecting initialization... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2550142

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.