Protection and recovery of non-redundant information stored in a memory

The present invention is a method, computer-readable medium and an apparatus for protection and recovery of non-redundant computer-readable information stored in a memory having multiple segments that features replacing computer-readable information stored in one of the multiple segments based upon a determination that computer-readable information stored in one of the remaining segments of the multiples segments is in a desired state. To that end, the memory device operates synergistically with a shelf manager, which maintains a state of computer-readable information in the differing address ranges of the memory device, so that any computer-readable information replaced in memory device may be achieved by executing uncorrupted computer-readable information stored in the memory device.

BACKGROUND

As is well known in the computer-related arts, software code is often improved resulting in additional versions, also know as updates, of the same that are backwards compatible with existing physical computer architectures designed to facilitate executing the same. Often several versions of software code occur during computer architecture development and many may occur after computer architecture has been placed in operation by an end-user, e.g., customer. The intended purpose of computer code updates is to improve the overall function of the architecture and, at times, increase the operational life of the same. As a result, reliably and efficiently providing software code updates is important in both the development and operation of computer architectures.

For example, a common impetus for generating software code updates is to ameliorate, if not obviate, problems, often referred to as “bugs”, with existing software code. Another impetus for generating software code updates is to provide existing computer architecture with additional functionality or improved functionality of an end-user-specific task. One drawback with providing software code updates is the risk of the occurrence of code corruption. Code corruption may result from a myriad of causes: operator error, power failure during update and the like. Code corruption may either result in either patent or latent functionality problems. For example, the computer architecture may become inoperative due to code corruption. Alternatively, the computer architecture may appear to be operating correctly and produce erroneous results or may produce a time-delayed patent problem, e.g., become inoperable some time after the update occurred. Therefore, there have been prior art attempts to avoid the problems associated with code corruption.

FIG. 1describes a prior art attempt to ascertain the existence of code corruption that includes comparing the value of a segment of a software code update with a predetermined value and comparing the same with an expected value. At function100, the code is downloaded to an embedded device (not shown). At function105, a previously downloaded byte is read from the embedded device (not shown). At function110, the byte is compared to the expected value. At function115, a determination is made regarding whether the byte value matches the expected value. At function120an indication that the code is corrupted is made if the byte value does not match the expected value and the process ends at function135. If the byte value matches the expected value, at function125a determination is made regarding whether there is another byte to check. This process continues until all bytes in the program have been checked. Were all of the bytes checked and determined to match their expected values, an indication that the program is valid occurs at function130.

Referring toFIG. 2, a prior art method of overcoming the existence of corrupted code is described as including redundant copies of the same in a memory space (not shown). At function301the software code update is downloaded into the memory space (not shown). At function305differing copies of the program are stored in differing addresses of the memory space (not shown). For example, a first copy of the program code is maintained in a first set of addresses in the memory space (not shown) referred to as main flash memory (not shown). An additional copy of the program code is maintained in a second set of addresses in the memory space (not shown) referred to as boot flash memory (not shown). At function310execution of the program code commences in boot flash memory (not shown), and at function315a determination is made regarding whether code stored in the main flash memory (not shown) is corrupted. Were the program code stored in the main flash memory (not shown) corrupted, the copy of the program code stored in the boot flash memory (not shown) is executed at function320. Were the program code stored in the main flash memory (not shown) not corrupted, a copy of the program code in main flash memory is executed at function325. A drawback with this recovery technique is that at least twice the amount of memory space is required to provide recovery. In addition, were the program code in both main memory and boot memory corrupted recovery would be problematic.

A need exists, therefore, for an improved technique to overcome the drawback of code corruption.

SUMMARY

The present invention is a method, computer-readable medium and an apparatus for protection and recovery of non-redundant computer-readable information stored in a memory having multiple segments that features replacing computer-readable information stored in one of the multiple segments based upon a determination that computer-readable information stored in one of the remaining segments of the multiple segments is in a desired state. Specifically, it was determined that by ensuring that information in at least one of the memory segments was in a desired state, i.e., uncorrupted, an update of information in one of the remaining segments of the memory would not pose a risk of catastrophic failure of the memory device should the segment being updated become corrupted. To that end, the memory device operates synergistically with a shelf manager, which maintains a state of computer-readable information in the differing address ranges of the memory device, so that any computer-readable information replaced in memory device may be achieved by executing uncorrupted computer-readable information stored in the memory device. Other aspects of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention. It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, or a method. Several exemplary embodiments of the invention will now be described in detail with reference to the accompanying drawings.

Referring toFIG. 3a system10in which the present invention is employed includes a shelf manager12and an application specific device referred to as a blade14. Shelf manager12includes a central processing unit (CPU)16in data communication with a memory space18. Access to shelf manager12by an end user (not shown) is achieved through a user interface20in data communication with input/output circuitry22. User interface20may include any interface known in the art including a keyboard (not shown), a mouse (not shown), a monitor (not shown) and the like. Moreover, user interface20may be integrally formed with shelf manager12or may be a separate computing system (not shown) that is operating any one or more of a number of operating systems, such as WINDOWS®, LINUX and the like. Nonetheless, user interface20includes a firmware upgrade utility21that facilitates communication between shelf manager12and blade14in accordance with the embodiments of the present invention.

Blade14includes a CPU24in data communication with an embedded device26. A random access memory space28is in data communication with CPU24. Embedded device26includes an embedded processor30and an embedded memory32in data communication therewith. Also included in embedded device26is a random access memory space29in data communication with embedded processor30. Embedded processor30and CPUs16and24may be any known in the art, including, but not limited to an H8 microcontroller available from Renesas Technology of America of San Jose, Calif. Memory space18may include any known memory device such as a hard diskette drive, floppy diskette drive, optical compact diskette drive, tape drive, volatile and non-volatile random access memories or a combination thereof. Embedded memory32may include any known memory such as electronically erasable programmable read only memory (EEPROM) or Flash memory.

Shelf manager12and blade14may be in data communication, either constantly or selectively, employing any known data communications technology via-a-vis link33. To that end, shelf manager12may communicate with blade14over a data bus or over a wide area network (WAN), such as the internet, a local area network (LAN) employing well know communication protocols. Typically used may be IPM bus (Intelligent Platform Management Bus) which is an I2C bus on a physical layer employing an IPMI protocol. Blade14is typically a sub-system of a larger system (not shown) that may facilitate any number of a myriad of operations in furtherance of one or more business models, such as telecommunications, banking transactions, manufacturing management, business accounting and the like. To that end, embedded memory32typically stores an application that is operated on by embedded processor30to carry-out a number of desired functions. The functions may be called automatically by embedded processor30in a predetermined routine with interruption vis-à-vis CPU24in response to commands/requests from shelf manager12or other subsystems (not shown) that are part of the system (not shown) in which blade14is included.

Referring to bothFIGS. 3 and 4, an important consideration implemented by the present system10is protecting information stored in embedded memory32to an extent required to maintain operation of blade14in the presence of code corruption of the application program. To that end, shelf manager12and blade14operate synergistically to ensure that no information is replaced in embedded memory32without ensuring a desired portion of the computer-readable information stored therein is uncorrupted Embedded memory32includes, in addition to the application program, additional computer-readable information mapped therein to ensure operation of blade14in the presence of code corruption. The computer-readable information is mapped into embedded memory32so as to be segmented in three ranges of addresses, a first range of addresses is referred to as a reset segment34, a second range of addresses is referred as a boot segment36and a third range of addresses is referred to as a main application segment38. Specifically, each boot segment36and main segment38is mapped as a plurality of sectors defined by sequential memory addresses, shown as40-45and50-55, respectively. It should be noted that the number of sectors shown are exemplary. Each segment34,36and38includes a pair of boundary sectors associated with a pair of spaced-apart memory addresses that demarcating the boundary for each of segments34,36and38. Boot segment36includes boundary sectors sector40and45. Each of sectors41,42and43having addresses between boundary sectors40and45are included in boot segment36. Similarly, main segment38includes boundary sectors sector50and55. Each of sectors51,52,53and54having addresses between boundary sectors50and55are included in main segment38. Finally, reset segment34may or may not include boundary sectors, as discussed above. In the present example, reset segment34does not include multiple sectors.

Boot segment36stores computer-readable information to perform power-on tests and self-test, and main segment38stores computer-readable information for application specific software. Boot segment36is associated with a different range of memory addresses from main segment38so that blade14may continue to operate in the situation where the computer-readable information in main segment38becomes corrupted. As a result, the computer-readable information contained in boot segment36, in addition to being sufficient to boot-up blade14, also communicates with shelf-manager12to, inter alia, replace the computer-readable information in main segment38should the same become corrupted or other causes blade14not to function as desired. This is referred to as a recovery operation. Should it not be possible to perform boot operations of blade14by executing computer-readable information in boot segment36, boot operations may be executed from computer-readable information in main segment38. Thus, in addition to the main application program, main segment38includes computer-readable information sufficient to perform the boot operation of blade14. This is referred to as a boot support operation. Additionally, to ensure operation of blade14, it is desired that the computer-readable information in main segment38be sufficient to communicate with shelf-manager12to, inter alia, replace the computer-readable information in boot segment36should the same be corrupted, e.g. perform a recovery operation of boot segment36computer readable-information.

Reset segment34stores hardware specific information indicating the hardware attached to blade14, as well as diagnostic code to determine whether computer-readable information in either boot segment36or main segment38is in a desired, non-corrupted state. The computer-readable information in reset segment34, at pre-assigned compute cycles during operation of blade14, determines whether the computer-readable information in one, or both, of boot segment36and main segment38become corrupted. The state of computer-readable information on both boot segment36and main segment38is typically determined upon initiation of a boot operation of blade14. Upon ascertaining corruption in the computer-readable information in one of boot segment36and main segment38, the computer-readable information in reset segment34selects computer-readable information from one of boot segment36and main segment38, which is not corrupted, from which to continue operation of blade14. Should reset segment34determine that code corruption has occurred in either one of boot segment36or main segment38, operation of blade14is transferred to the computer-readable information in non-corrupted segment to replace the computer-readable information in the segment in which code corruption is present. In this manner, there is appropriate computer-readable information present in embedded memory32to perform boot operations for blade14and to communicate with shelf manager12.

To facilitate diagnostic operations by the computer-readable information in reset segment34, each of sectors40-45and50-55includes a plurality of sub-sectors60-64, discussed with respect to sector50for sake of brevity and applicable to the remaining sectors40-45and51-55of embedded memory32. Although there are five sub-sectors60-64shown, any number may be present so long as each of sub-sectors60-64consists of no less than a range of sequential memory addresses one word (eight bits) in length. A primary sub-sector60is positioned at one terminus of sector50, and a final sub-sector64is located at a second terminus of sector50. All sub-sectors61-63having addresses between primary and final sub-sector60and64are included in sector50. Sub-sectors61-63are referred to as intermediary sub-sectors. Computer-readable information stored in primary sub-sector60has a predefined correlation with computer-readable information stored in final sub-sector64such that performance of an arithmetic operation on the same, during a diagnostic routine invoked by the computer-readable information in reset segment34, would produce a predetermined result. Should the predetermined result not occur in response to the arithmetic operation, it is ascertained that code corruption has occurred in main segment38. An exemplary diagnostic routine may include storing information in primary and final sub-sectors60and64related to the moment when the computer readable instruction in sector50were recorded, e.g., year, month, date, hour and second information concerning the last moment the computer-readable information were stored therein. An exemplary mathematical operation could consist of taking a difference between the computer-readable information stored in primary and final sub-sectors60and64, which should yield zero.

In accordance with another embodiment, the diagnostics routine may consist of implementation of what is referred to herein as a differential checksum routine. To that end, a checksum value for each of the sub-sectors60-64is determined from the computer-readable information stored therein. From this operation a plurality of checksum values is obtained. The plurality of checksum values are then summed, defining a summed checksum. Stored in intermediary sub-sector63is a value equal and opposite to the value of the summed checksum. The value stored in sub-sector63is then added to the summed checksum algorithm, with the expected value being zero. Should zero not be returned in this diagnostic routine, then code corruption would be ascertained to be present in main segment38. An advantage of this diagnostic routine is that a greater percentage of computer-readable information stored in the addresses of main segment38may be analyzed for code corruption than with previous diagnostic routines.

In response to determining that code corruption has occurred employing one of aforementioned diagnostic routines, the entire quantity of computer-readable information stored in main segment38may be replaced under operation of the computer-readable information stored in boot segment36. It should be understood that one or more of the aforementioned diagnostic routines may be implement to determine the state of computer-readable information in reset segment34.

Referring toFIGS. 5 and 6, in one embodiment of the present invention blade14executes application program stored in main segment38of embedded memory32. Commands, or instructions, entered at user interface20are communicated to blade14vis-à-vis shelf manager12. Were it desired to update computer-readable information in main segment38, a terminate-main application-program commend would be generated by shelf manager12at function140. At function142shelf manager12would determine whether the update file is valid. Were this not the case, shelf manager12would abort the update and issue a run application program command to blade14at function144. Were the update file determined to be valid at function142, then shelf manager12would determine at functions146and148whether the update file was to computer-readable instructions in main segment38or boot segment36. Were the update file for boot segment36, shelf manager would first determine whether code corruption was present in main segment38by requesting reset segment34to implement the diagnostic routine, as discussed above. Were it determined that code corruption was present in main segment38, shelf manager12would request blade14to identify the addresses in embedded memory32where stored is the computer-readable information that was the subject of the code corruption. In response, at function154, a print error message would be displayed on user interface20, e.g., a computer monitor, at function154.

Were it determined at function150that the computer-readable information stored in main segment38was in a desired state, i.e., uncorrupted, firmware update utility21via shelf manager12would issue to blade14a start update command. Upon receipt of an acknowledgement of the command from blade14, shelf manager12would transmit a select boot command to blade14. Upon receipt of an acknowledgement to the select boot command from blade14, an erase boot command would be transmitted from firmware update utility21via shelf manager12to blade14at function160. At function162, firmware upgrade utility21via shelf manager12determines whether the erase was successful by receipt of an acknowledgement from blade14. Were it determined that the erase function162was unsuccessful, firmware update utility21via shelf manager12would abort the update operation at164at which point blade14may resume execution of main application program in main segment38of embedded memory32or system10merely halt and provide an error indication at user interface20or a combination thereof. Were the erase determined to be successful at function162, the file containing the information to be written to boot segment36would be opened on shelf manager12at function166, and at function170firmware upgrade utility21via shelf manager12determines whether the file had been successfully opened. Were this not the case, an error message would be generated to user interface20at function171and the operation aborts at function164.

Upon determining that the file has been opened at function170, data packets are transmitted to blade14at function172. The data packets contain the computer-readable information from the file that is to be stored in boot segment36. In this manner, computer-readable information stored in boot segment36is replaced with the computer-readable information of the update. At function174firmware update utility21via shelf manager12determines whether all the data associated with the update had been transmitted to blade14. Were this determined not to be the case, function176occurs at which point firmware upgrade utility21via shelf manager12determines whether an error has been detected during the transfer of the update to blade14. This may be implemented employing standard error checking protocols, such as checksum protocols. If an error had been detected, the operation proceeds to function171. Were it determined that no errors occurred during the transmission of the update to blade14at function176, function172is resumed followed by function174. Upon determining that all data associated with the update has been transmitted to blade14at function174, the diagnostic routine is executed from reset segment34at function180to determine whether code corruption is present in boot segment36. Were code corruption found to be present in boot segment at function180, function152and154would occur. Were it found that no code corruption was present at function180, then shelf manager12issues an update complete command to blade at function182and the main application program resumes execution of blade14from the computer-readable instructions stored in main segment38.

An alternate embodiment, not shown may, in addition to, or in lieu of printing the error message at function154, result in firmware update utility21via shelf manager12terminating the boot segment update operation and implement a recovery operation to restore computer-readable information in main segment38under control of computer-readable information stored in boot segment36. After the computer-readable information was restored in main segment38so that the same is in a desired state, firmware update utility21via shelf manager12may return to updating the computer-readable information stored in boot segment36by returning to function142or150, as desired. As a result, of either of the previously discussed embodiments, computer-readable information in boot segment36is not replaced unless computer-readable information in main segment38is in a desired state, i.e., uncorrupted state.

Were firmware update utility21via shelf manager12to determine that the update was for the computer-readable instructions contained in main segment38, then function184would be implemented. Were the update file for main segment38, shelf manager would first determine whether code corruption was present in boot segment36by requesting reset segment34to implement the diagnostic routine, as discussed above. Were it determined that code corruption was present in boot segment36, firmware update utility21via shelf manager12would request blade14to identify the addresses in embedded memory32where stored is the computer-readable information that was the subject of the code corruption at function152followed by function154during which an error message would be generated on user interface20.

An alternate embodiment, not shown, may, in addition to or in lieu of printing the error message at function154, result in firmware update utility21via shelf manager12terminating a main segment update operation and implement a recovery operation of replace computer-readable information in boot segment36under control of computer-readable information stored in main segment38. After the computer-readable information is recovered in boot segment36so that the same stored therein is in a desired state, firmware update utility21via shelf manager12may return to updating the computer-readable information stored in main segment38by returning to function142or150, as desired. As a result of either of the previously discussed embodiments with respect to the main segment update operation, computer-readable information in main segment38is not replaced unless computer-readable information in boot segment36is in a desired state, i.e., uncorrupted state.

Were it determined at function184that the computer-readable information stored in boot segment36was in a desired state, i.e., uncorrupted, shelf manager12would issue to blade14a start update command at function186. Upon receipt of an acknowledgement of the command from blade14, shelf manager12would transmit a select main segment command to blade14at function188. Upon receipt of an acknowledgement to the select main segment command188from blade14, an erase main segment command would be transmitted from shelf manager12to blade14at function190. At function192, firmware upgrade utility21via shelf manager12determines whether the erase was successful by receipt of an acknowledgement from blade14. Were it determined that the erase function192was unsuccessful, shelf manager12would abort the update operation at194at which point blade14may resume execution of main application program in boot segment36of embedded memory32or system10merely halt and provide an error indication at user interface20or a combination thereof. Were the erase determined to be successful at function192, the file containing the information to be written to main segment38would be opened on shelf manager12at function196, and at function198firmware upgrade utility21via shelf manager12determines whether the file had been successfully opened. Were this not the case, an error message would be generated to user interface20at function199and the operation aborts at function194. Upon determining that the file has been opened at function198, data packets are transmitted to blade14at function200. The data packets contain the computer-readable information from the file that is to be stored in main segment38. In this manner, computer-readable information stored in main segment38is replaced with the computer-readable information of the update. At function202firmware upgrade utility21via shelf manager12determines whether all the data associated with the update had been transmitted to blade14. Were this determined not to be the case, function204occurs at which point firmware upgrade utility21via shelf manager12determines whether an error has been detected during the transfer of the update to blade14, as discussed above with respect to function176. If an error had been detected, the operation proceeds to function199. Were it determined that no errors occurred during the transmission of the update to blade14at function204, function200is resumed followed by function202. Upon determining that all data associated with the update has been transmitted to blade14at function202, the diagnostic routine is executed from reset segment34at function208to determined whether code corruption in present in main segment38. Were code corruption found to be present in main segment at function208, function152and154would occur. Were it found that no code corruption was present at function208, then shelf manager12issues an update complete command to blade at function182and the main application program resumes execution of blade14from the computer-readable instructions stored in main segment38.

Referring toFIGS. 3,4and6, as stated above, one embodiment of the present invention includes embedded processor30of blade14executing an application program stored in main segment38of embedded memory32, shown as function240. Were a command found to have arrived at function242, CPU24would then determine whether the same was to determine a state boot segment and main segment38at function244. Were a DETERMINE_MEMORY_STATE command found to be present at function244, embedded processor30would operate on computer-readable information in reset segment34to execute one or more of the aforementioned diagnostic routines at function246. The results of function246would be transmitted to shelf manager at function248. Functions244,246and248occur periodically so that shelf manager12maintains an accurate status of the state of boot segment36and main segment38.

Were a DETERMINE_MEMORY_STATE command not found by function244, function250would occur at which point CPU24would determine whether an access to memory is desired. If not, the command received would be executed normally at function252. Were function250to determine that an access to memory is desired, functions254and256would determine the segment of embedded memory32to be the subject of an update operation. Although function254is shown occurring first in the diagram, it is just as valid to have the sequence reversed with function256occurring before function254. At function254it is determined whether boot segment36is to be the subject of the update operation. If not, function256would determine if main segment38is the subject of an update operation. Assuming boot segment38is the subject of an update operation, embedded processor30determines at function258whether a start UPDATE command has been received from shelf manager12. If not, embedded processor30determines at function260whether an ERASE command have been received from shelf manager12. If not, embedded processor30determines at function262whether a WRITE command had been received. If not embedded processor30determines at function264whether an END_UPDATE command was received at function266. If not the command is executed normally at function252.

Were embedded processor30to determine, at function258, that a START UPDATE command was received, execution of application program would be terminated at function266. At function268a UPDATE_BOOT_SEGMENT flag would be set in RAM29by embedded processor30. Blade14would then await an ERASE command, which would be determined to arrive at function260and would result in boot segment36being erased at function270. Blade14would then await a WRITE command, which would be determined to arrive at function262and would result in boot segment36being written to with update information at function272. Thereafter, blade14would then await an END_UPDATE command at function264which, when received would result in clearing of UPDATE_BOOT_SEGMENT flag in RAM29at function274.

Were it determined at function256that main segment38was to be the subject of an update operation, embedded processor30could undertake functions276,278,280and282, which are identical to functions258,260,262and266, respectively. However, were an ERASE or WRITE command found at functions278and280, respectively, a fail completion code, at function281, would be transmitted to shelf manager12, because read/write access to main segment38is not permitted when blade14is executing computer-readable information stored in main segment38. Rather, computer-readable information stored in reset segment34first causes embedded processor30to execute from computer-readable information stored in boot segment36before read/write access is granted to main segment38. To that end, following termination of execution of application program at function282, embedded processor30, at function284sets an UPDATE_MAIN_SEGMENT flag in RAM29. Following function284, embedded processor30processor jumps to reset segment34to execute computer-readable information stored therein at function286, shown inFIG. 7.

Referring to bothFIGS. 3 and 7embedded processor30executing computer-readable information stored in reset segment34determines whether the program in main segment38is corrupted at function288, employing one or more of the aforementioned diagnostic routines. Were this the case, an UPDATE_MAIN_SEGMENT_ERROR flag would be set in RAM29by embedded processor30at function290. At function292, embedded processor30determines whether the program in boot segment34is corrupted employing one or more of the aforementioned diagnostic routines. Were this the case, an UPDATE_BOOT_SEGMENT_ERROR flag would be set in RAM29by embedded processor30at function294. Following either function292or294, embedded processor30determines at function300whether UPDATE_MAIN_SEGMENT flag is present in RAM29. If not, embedded processor30determines, at function306, whether UPDATE_BOOT_SEGMENT flag is present in RAM29. If not, embedded determines whether RAM29includes a MAIN_SEGMENT_ERROR flag. If not, the operation proceeds to function240onFIG. 6; otherwise, the operation proceeds to function340shown inFIG. 8and discussed more fully below.

Referring again to bothFIGS. 3 and 7, were it determined at function306that the UPDATE_BOOT_SEGMENT flag is present in RAM29, embedded processor30determines at function308whether a MAIN_SEGMENT_ERROR flag is present in RAM29. If not, the operation proceeds to function240onFIG. 6; otherwise the update operation is terminated at302, shown inFIG. 7, and an error occurs at function303. It should be understood that the present invention avoids operations302and303from occurring following function308. Therefore, the sequence of function308,302and303is determined to be a highly improbably condition due, inter alia, to the synergism between shelf manager12and blade14. Specifically, blade14does not allow shelf manager12to access main segment38unless an UPDATE_BOOT_SEGMENT flag is present in RAM29, thereby protecting the computer-readable information therein from inadvertently being erased, overwritten or otherwise corrupted. Function308provides double protection so that access to main segment38is prevented, in the presence of UPDATE_BOOT_SEGMENT flag in RAM29in the event that a MAIN_SEGMENT_ERROR flag were also in RAM29. In this manner, main segment36is ensured to be in a desired state so that should code corruption result from an update operation of computer-readable information in boot segment36. This makes available computer-readable information in main segment38to facilitate a recovery operation of previously existing computer-readable information in boot segment36or replacing the same with an update operation.

Referring again to bothFIGS. 3 and 7, were it determined at function300that UPDATE_MAIN_SEGMENT flag is present in RAM29, embedded processor30carries-out function304to determine whether a BOOT_SEGMENT_ERROR flag is present in RAM29. Were this the case, then the update operation would terminate at function302and an error would occur at function303. It should be understood that the present invention avoids operations302and303from occurring following function304. Therefore, the sequence of functions304,302and303is determined to be a highly improbably condition due, inter alia, to the synergism between shelf manager12and blade14. Specifically, blade14does not allow shelf manager12to access main segment38unless an UPDATE_MAIN_SEGMENT flag is present in RAM29, thereby protecting the computer-readable information therein from inadvertently being erased, overwritten or otherwise corrupted. Function304provides double protection so that access to main segment38is prevented, in the presence of UPDATE_MAIN_SEGMENT flag in RAM29in the event that a BOOT_SEGMENT_ERROR flag were also in RAM29. In this manner, boot segment36is ensured to be in a desired state so that should code corruption result from an update operation of computer-readable information in main segment38. This makes available computer-readable information in boot segment36to facilitate a recovery operation of previously existing computer-readable information in main segment38or replacing the same with an update operation. However, were a BOOT_SEGMENT_ERROR flag not present in RAM29at function304, operation340ofFIG. 8would occur, discussed more fully below.

Referring toFIGS. 3 and 8, shown is the method to obtain read/write access to embedded memory32when embedded processor30is executing computer-readable information stored in boot segment36. Nonetheless there are similar functions carried out that are common between the two methods. Specifically, functions242,244,246,248,250,252,254,256,258,260,262,264,266,276,278,280and282ofFIG. 6are identical to functions342,344,346,348,350,352,354,356,358,360,362,364,366,376,378,380and382ofFIG. 8. However, considering that embedded processor26ofFIG. 3is executing computer-readable information stored in boot segment36upon receipt of an update operation at function350, shown inFIG. 8, it becomes manifest that embedded processor32ofFIG. 3should execute computer-readable information stored in main segment38before allowing read/write access to boot segment36.

Referring to bothFIGS. 3 and 8, following function366a UPDATE_BOOT_SEGMENT flag is written to RAM29at function384and then function286occurs, shown inFIG. 7and the reset routine is carried-out as discussed above. In this manner, execution of computer-readable information stored in boot segment36, shown inFIG. 3, is terminated, and embedded processor26executes computer-readable information stored in main segment38before read/write access to boot segment36occurs. Should an ERASE or WRITE command be received while embedded processor30is executing from computer-readable information stored in boot segment, a fail completion code instructions is sent to shelf manager12at function381, shown inFIG. 8.

Referring again to bothFIGS. 3 and 8, were read/write access to main segment38desired while embedded processor30executed computer-readable information stored in boot segment36, following termination of execution of application program at function382, an UPDATE_MAIN_SEGMENT flag would be set in RAM29. Thereafter, ERASE and WRITE commands would be undertaken at functions370and372, respectively without having to invoke the reset routine.