WO2001050261A2

WO2001050261A2 - Updating non volatile memory in a data processing system

Info

Publication number: WO2001050261A2
Application number: PCT/IB2000/001579
Authority: WO
Inventors: Gilles MAIGNÉ
Original assignee: Sun Microsystems, Inc.
Priority date: 1999-12-29
Filing date: 2000-10-31
Publication date: 2001-07-12
Also published as: WO2001050261A3; AU7939800A

Abstract

The invention is applied in a data processing system which have a processor and a memory. This memory may be a flash memory (2A, 2B) being erasable in memory units before being rewrittable. This flash memory comprises designated data with at least one memory unit address, and corresponding update data. This flash memory also comprises an updating code cooperating with designated data for erasing the memory unit having said address, and writing the corresponding update data in this memory unit.

Description

Updating non volatile memory in a data processing system.

The invention relates to memory update in data processing systems.

Many data processing systems use non-volatile memories, at least to store program data. It is desirable that such memories allow a quick reading of the data they contain. By contrast, writing in the memory is more sophisticated and may be significantly slower.

Such non-volatile memories, include, inter alia, the so called "flash memories". They are erasable in units termed "erase unit" (or, alternatively, "memory unit"), and an erase unit must be completely erased before being rewritten. Usually, the system has a program memory area for storing program data. When one or more program data blocks need to be updated, the whole erase unit comprising those blocks is firstly erased. Then, it is rewritten with new program data blocks, and the remainder is rewritten with the original prior data in the erase unit. Various error circumstances, e.g. a power failure, may occur before the update is co ple- ted. In such cases, control on the exact data condition of the erase unit is lost, as described in more detail hereinafter. These data will likely be inconsistent, which raises problems in many fields of application, e.g. in business transaction devices. Where program data are concerned, especially in the operating system, the problems become particularly severe, especially for unattended devices.

The purpose of the invention is to propose advances to overcome such drawbacks .

The invention is applicable to a data processing system, having a processor and a memory, in which the memory comprises a non volatile memory, erasable by units before being rewrittable. In accordance with a first feature of the invention, the memory comprises : designated data comprising at least one memory unit address, and corresponding update data, and - an updating code, capable of cooperating with said designated data for erasing the memory unit having said address, and writing the corresponding update data in such memory unit.

Preferably, the updating code is further capable of finally altering at least a portion of said designated data, upon its normal completion.

In an embodiment of the invention, the non volatile memory comprises a program memory area and a data memory area, and the program memory area is a flash memory authorizing execution in place. The aforesaid designated data comprises one or more addresses in the program memory area. The program memory area comprises at least a portion of an operating system for the data processing system.

Preferably, the updating code, located in a reserved portion of the non volatile memory, is part of the boot code of the system. The updating code is executed in response to the presence of a predefined portion of the designated data. The system further has a random access memory for loading the boot code in the random access memory.

According to another feature of the invention, the designated data comprise a sequence of unit changing commands, each having a memory unit address, and a pointer to corresponding update data. The system preferably has a file system and the sequence of unit changing commands is a script file having a predefined file name, and said pointer to corresponding update data comprises a file name.

Preferably, the update code further comprises preparing code, capable of organizing the distribution of update data amongst designated memory units in said memory area. The above features of the invention may also be defined in terms of a method of managing data in a system having a processor and a memory, said memory comprising a non volatile memory being erasable in memory units before being rewrittable. In a version, the method comprises the steps of : a) designating at least one memory unit address and corresponding update data, b) erasing the memory unit having said address, and c) writing the corresponding update data in such memory unit.

Other features will be found in the claims appended to this specification.

Still other features and advantages of the invention will appear in the light of the detailed description below and the associated drawings in which :

- figure 1 is a general diagram of a data processing system in which this invention is applicable ;

- figure 2 shows an exemplary memory organisation in the system of figure 1 ;

- figure 3 is a flow chart of a preparatory phase which is optionally used in this invention ;

- figure 4 shows a command list file structure, stored in the memory and adapted to be used by an update monitoring code in accordance with this invention ;

- figure 5 is a flow chart of an exemplary embodiment of this invention ; and

- figure 6 is a flow chart showing in detail an exemplary update code. The appended drawings include graphical information, which may be useful to define the scope of this invention.

This invention may be applicable to various stand alone devices, like banking terminals, portable electronic devices, mobile telephones, entry systems, or domestic appliances, e.g. washing machines including those based on the JINI concept. Such devices may include non-volatile memory for various reasons :

- at least, some of the data clearly need to be kept even if the power supply is turned off ;

- program data, for example the operating system or a portion thereof must remain resident whether the power supply is on or off.

Another aspect of such devices is that they are generally unattended. This means that it is highly desirable that they can recover from many error situations without human intervention. This aspect also extends to updating data in general, and also to upgrades in the program and/or the operating system of the devices. The tendency now is to download upgraded program portions through a network to the device, and to have the device manage program upgrade itself.

Generally, as shown in figure 1, such a device comprises a processor 1 and a memory 2. The memory 2 is subdivided into a program memory area 2A and a data memory area 2B. The processor is interconnected with the memory through a bus 5. The bus 5 may also be connected to various devices 4, as usual in many practical applications.

In a specific exemplary embodiment (Fig. 2), which illustra- tively encompasses a variety of possibilities, the memory 2 comprises :

- a non volatile program memory 2A,

- a non volatile data memory 2B,

- a random access memory or RAM 2C, and - a read only memory 2C, e.g an epROM.

The respective sizes of the memory areas on figure 2 are merely exemplary.

The memory sections or areas 2A and 2B may be based on "flash" memory chips, as known in the art. The memory section 2A is preferably based e.g. on flash memory chips of the NOR type, which offer parallel read access, and are more convenient for "execution in place" of programs, where appropria- te. The memory section 2B may be based e.g. on flash memory chips of the NAND type, which offer serial read access, and are convenient for use as a disk-like memory.

As also known, such memory chips are erasable only by whole "erase units", which are shown on figure 2 e.g. as EU0...EUn for memory area 2A. Similar erase units, not shown, exist in memory area 2B.

In accordance with an aspect of the invention, a reserved unit EUO ( "RU" ) contains executable updating code, noted UPDA. Although the updating code may be source code, binary code is preferable in many applications. Reserved unit EUO may also include other information, e.g. pointers to other areas in memory 2.

The update code UPDA and/or its controlling data are suitably arranged not to make any update in reserved unit EUO . Program memory 2A may also contain application programs AP.PRG.

The data memory portion 2B may include various types of data, as necessary in the device, including application data AP.DATA. In accordance with another aspect of this invention, when an update is to be made, memory area 2B includes update defining data, which are preferably designated data, in the sense that such data are accessible using a predefined direct or indirect pointer. The designated data comprises one or more erase unit addresses, to be at least partially updated; it also comprises corresponding update data, to be written in the erase units having the one or more addresses, or a representation of such update data.

A file system may be instituted in at least certain portions of memory 2. If so, memory area 2B may include a script file SCR including one or more commands, and one or more data files Ul-Un (generically Ui), each corresponding e.g. to a whole new content of a respective one of erasable units EU1- EUn (generically EUi). The one to one correspondence between the EUi and the Ui is not necessary, and other schemes of association of a command with one or more files (or file portion) may be used. As a whole, data files Ul-Un define update data UPBD. Of course, the sizes of blocks Ul-Un may be larger than illustrated. Together, the script SCR and its data files define designated data, which are accessible using only the name "SCR" of the script file, which is reserved in the file system. Where no file system is available, a similar organization may be instituted using direct or indirect addresses .

It is now assumed that the stand-alone device is in the following condition : the non volatile memory, here memory 2B, contains a script file SCR and new data files UPDB which match each other.

This condition may be established by an operator using e.g. a portable computer suitably connected to the stand alone device. In a number of applications, it will be preferable to download the designated data to the stand alone device through a network, e.g. from a server.

The server may directly download a new script file SCR and associated data files to the stand alone device, e.g. if the server knows the exact memory mapping of the data to be updated in the stand alone device.

Alternatively, the server may download a simpler definition of the update to be performed, e.g. a representation of the new data, and of their locations within the existing data. In this case, the update code comprises preparatory operations, which will now be described with reference to figure 3, in an example. After label step 300, step 301 uses the downloaded data which have been received for updating memory 2 , in the example for upgrading a portion of the Operating System contained in memory 2A. Then, step 302 organizes the upgrade data into a script file named 'SCR', and a plurality of files, e.g. a file for each erase unit designated in the script file for being rewritten. This can be done using the image of the operating system (e.g. as used in ChorusOs, a product and trademark of SUN MICROSYSTEMS). If the data to be updated is other than OS data, the location of such data in memory is normally known to the system.

As schematically shown in Figure 4, the result is a script file SCR, containing a sequence of commands, designated as COMMAND-1 to COMMAND-n. Various command formats may be used, enabling each command to define:

- an operation <operation>, - parameters <parameters>,

- one or more check values <checksum>.

Generally, the <operation> may be seen as a macro command for erasing an erase unit, and subsequently writing data in it.

The <parameters> comprises at least :

- an identifier of the erase unit Eui to be processed, e.g. its physical address in memory 2A, and

- a pointer to the location in the working or data memory area 2B where the new data to be written in the erase unit will be found, e.g. the name of a file Ui.

The <checksum> designates at least one of: the checksum of the erase unit before it is updated (CKi_before) , and the checksum of the erase unit after it has been updated (CKi_af- ter). These values may be calculated during step 302.

Alternatively, the script file SCR may use a multi-line command format: each command comprises an operation of erasing the erase unit and one or more subsequent operations of writing new data in the erase unit (several successive write steps may be performed, provided they do not overlap each other). The parameter structure is adapted as necessary. The checksum value may be omitted in the line for erasing the erase unit, or, alternatively, comprise the checksum of the old program data (CKi_before) . The writing operation (or at least the last one of them) may comprise, or be followed with the checksum of the updated program data (CKi_after), i.e. the checksum value which corresponds to the updated data, when rewritten in the corresponding memory unit. This enables to check whether the update defined in the current command has been performed, and, if desired, to check whether the erase unit being considered still contains the unmodified old data.

Where lower level operations (closer to assembler) are desirable, a command may have the following format (the line sections after the symbol && are comments): BEGIN <CKi_before>

LOAD <Ui> && load the update data from file Ui into RAM ERASE <EUi>

WRITE <Ui> && implicitly, from RAM into erase unit EUi END <CKi_after>

WRITE_BLOCK operations may be used where different portions of the erase unit EUi are sequentially rewritten. MOVE_BLOCK operations may also be used to avoid empty memory locations, if desired, for example by copying old data into RAM, and rewriting the same at a different position in erase unit EUi (the old data will be subsequently erased). With WRITE_BLOCK and MOVE_BLOCK operations, certain portions of the erase unit may remain erased, without being rewritten thereafter.

One aspect of this invention is to render each command atomic, in the sense it can be considered either as executed, either as not executed. A crash may occur at any time between the BEGIN and the END of a command. In the above example: - if a crash occurs before the ERASE, then the checksum CKi of the erase unit EUi will be Cki_before;

- if a crash occurs during or immediately after the ERASE, then the checksum CKi of the erase unit EUi will be neither Cki_before, neither Cki_after;

- if a crash occurs during the WRITE (or a MOVE), then the checksum CKi of the erase unit EUi will also be neither Cki_before, neither Cki_after.

Thus, each operation is restartable or re-executable, in the sense that the system will keep the initial condition for executing one or more of these operations in the last command before the crash. In other words, the update routine will behave as a state machine at least at the level of each successive command.

The updating process will now be described with reference to figure 5, in the particular example of updating OS portions. In this case, the system is re-booted, e.g. at END step 303 of figure 3.

Label step 500 is a usual initial boot jump. Step 510 is a primary boot routine, producing a minimal hardware initialization, which comprises enabling access to memories as required, and creating a file system, at least in memory 2B. Preferably no external interrupt is enabled, and a single thread is executed (subject to the watchdog timer, if necessary) .

Thereafter begins a secondary boot routine 520, which comprises the update code, as it will be seen. Step 522 comprises self-loading the secondary boot routine in RAM 2D, and launching the same. This is preferable, in that most of the memory areas 2A and 2B will remain free. Then, step 524 reads the file system data concerning flash data memory 2B. Step 526 tests whether a file named 'SCR' is present. If so, step 528 launches the update code per se, an example of which will be described with reference to figure 6 (normally finishing with a reboot as redundantly indicated in figure 5 at step 530); otherwise, the secondary boot routine terminates, and step 540 performs the required normal subsequent boot steps in the stand alone device, until the end of boot at step 550. It is assumed that these normal subsequent boot steps re- organize the memory, as required for proper operation of the stand alone device, and thus delete any residual files pursuant to a completed update. The normal boot may include the OS, a Java Virtual Machine, and application programs.

An example of the update code per se will now be described with reference to figure 6. In this example the same routine is used both for a first execution of the update, and for subsequent re-executions after an uncompleted update.

After initial or label step 600, step 602 will read the 'SCR' file, thus gaining access to the one or more commands it contains. The file as read (or successive portions thereof) is stored in RAM 2D. Step 604 sets the current command CMDi to be the first command in the SCR file.

The next steps within frame 610 form a loop sequentially scanning the SCR file, to determine its first command having not yet been executed. Each command includes the address of the erase unit EUi it concerns. In the example, step 612 calculates the checksum CKi of the actual data as existing in the erase unit EUi. Then, step 614 tests whether Cki equals Cki_before, as stored in current command CMDi. If so, CMDi is the first non-executed command in the script. Otherwise, step 616 tests whether Cki equals Cki_after, as stored in current command CMDi. If not so, CMDi is also considered to be the first non-executed command in the script. Otherwise, step 618 makes the next command to be the current command CMDi . Optionally, various error processing may be implemented at this stage, e.g. : - if the end of the SCR file is reached, with no unexecuted command, indicating an update which has unduly been considered as uncompleted, or

- using differently the comparison steps 612 and 614, or only one of them, depending upon the reliability of write com- mands, when applied to the particular type of memory being updated. Considering for example flash memory chips, step 616 alone, or step 614 a Lone, may be sufficient in certain cases.

Then, the next steps within frame 620 form a loop sequentially scanning the SCR file, from the first non executed command (or from the beginning, in the case of the first execution of the update routine).

Step 622 determines whether the last command in the SCR file has been reached and executed.

Normally, at least one current command CMDi remains to be executed when entering frame 620. That command is executed at step 624, and step 626 (the same as 618) makes the next command to be the current command CMDi .

This is repeated until the end of the SCR file has been reached. If so, step 630 deletes the SCR file. Alternatively, or additionally, step 630 may reset an "update flag" which would have been set for example within step 600 or 602. Finally, step 640 (the end of the update) reboots the system. Rebooting the system is presently preferred, at least where OS data are being updated. However, other suitable continua tions may be contemplated.

In case of power failure, the update routine will be unduly interrupted. Very likely, the power failure will result into system reboot, either by itself, or e.g. under effect of a timer watchdog thread, or due to voluntary power cut-off or reboot, upon abnormal operation of the stand alone device. Alternatively, or additionally, a reboot command may be built in the update routine in case of abnormal execution of any of its operations.

Such a reboot without deleting the 'SCR' file (and/or without resetting the update flag) will result into the routine of figure 6 to be executed again, until reaching the first unexecuted or incorrectly executed operation therein. The update is executed again, starting with that operation. Since the risk that another power failure again occurs is small, the update should now be correctly completed.

Otherwise, various error processing schemes may be again contemplated here, depending upon the memory technology, inter alia.

Normally, the update is correctly completed either at its first execution, or at the second one; the reboot after deletion of the SCR file (or reset of the update flag) will skip step 528 of figure 5, and step 540 will delete the residual data files Ui. These files may also be deleted at step 630. Thus, the data memory 2B is freed for normal operation of the stand alone device.

In other words, if an error of any kind, for example a power supply failure, occurs during the implementations of the steps of figure 5 or 6, then the update will not be comple- ted, and the condition of the memory will be incorrect or uncertain. This is a serious drawback in many circumstances, especially with program data (code or auxiliary data), more especially if the update relates to the operating system, without which the device cannot work, and would necessitate maintenance. As indicated, in many fields, it would be unacceptable for the device to be out of order for long periods .

In the above example, the same update code is used for the first execution of the update, and for possible subsequent re-executions, starting at the last non executed command. Alternatively, the first execution could use a simplified code, in which the steps within frame 610 are skipped, or do not exist.

Alternatively, or as a complementary precaution, the rank i of the current command in execution could also be stored in non volatile memory, e.g. 2B, at least in certain applications. Another very simple alternative to the algorithm of figure 6 would be to systematically re-execute all commands. However, this is not preferred, since certain operations (e.g. a MOVE operation) may loose their "restartable" character. But this would be feasible for example if the definition of the new data to be written always encompasses the whole content of each erase unit to be updated.

Generally, the script file is also sequentially organized to keep the "restartable" character of the commands it contains.

The checksum value is a statistically safe tool for implementing the invention, in that it is very unlikely that different contents of an erase unit have the same checksum. Precautions may be taken to avoid this; also, if this happens, maintenance would be exceptionally called. Other check values, safer or less safe, may be used as well, depending upon the applications.

Although this invention may apply to other kinds of memories, its application to flash memories is advantageous.

Also, the roles of memories 2A and 2B may be at least partially reciprocated, in certain cases. Although the invention is of particular interest in updating program data, it may also be used for updating pure data.

This invention also covers the software code to implement the invention, especially when made available on any appropriate computer-readable medium. The expression "computer-readable medium" includes a storage medium such as magnetic or optic, as well as a transmission medium such as a digital or analog signal. Such software code may include:

- the code for implementing the steps within frame 620 of figure 6, and/or

- the code for implementing the steps within frame 610 of figure 6, or

- the code for implementing all steps of figure 6, or - the combination of any of the preceding codes with code implementing steps 520-526 of figure 5 (or more extensively the whole code of figure 5 ) , or

- the combination of any of the preceding codes with accompanying designated data (or at least a portion thereof), or

- the combination of any of the preceding codes with the code of figure 3 for preparing the designated data, or

- any equivalent of those codes performing similar functions, especially as defined in this description.

Claims

1. A data processing system, having a processor and a memory, said memory comprising a non volatile memory being erasable in memory units before being rewrittable, wherein said memory comprises : designated data comprising at least one memory unit address, and corresponding update data, and an updating code, capable of cooperating with said designated data for erasing the memory unit having said address, and writing the corresponding update data in such memory unit.

2. The system of claim 1, wherein said updating code is further capable of finally altering at least a portion of said designated data, upon its normal completion.

3. The system of claim 1, wherein said non volatile memory is a flash memory.

4. The system of claim 1, wherein said non volatile memory comprises a program memory area and a data memory area, and said program memory area is a flash memory authorizing execution in place.

5. The system of claim 4, wherein said designated data are stored in said data memory area, and said designated data comprises one or more addresses in said program memory area.

6. The system of claim 5, wherein said program memory area comprises at least a portion of an operating system for said data processing system.

7. The system of claim 1, wherein said updating code is located in a reserved portion of the non volatile memory.

8. The system of claim 1, wherein said updating code is part of the boot code of the system.

9. The system of claim 8, further having a random access memory, wherein said boot code is loaded in said random access memory.

10. The system of claim 8, wherein said updating code is executed in response to the presence of a predefined portion of said designated data.

11. The system of claim 1, wherein said designated data further comprises at least one check data for each memory unit identifier, and said updating code is arranged for testing the update of a memory unit, using the corresponding at least one check data.

12. The system of claim 11, wherein said at least one check data comprises a check data before update, and said updating code is arranged to update a memory unit having the corresponding check data before update.

13. The system of claim 12, wherein said at least one check data comprises a check data after update, and said updating code is arranged to skip update a memory unit already having the corresponding check data after update.

14. The system of claim 1, wherein said designated data comprise a sequence of unit changing commands, each having a memory unit address, and a pointer to corresponding update data.

15. The system of claim 14, having a file system, wherein said sequence of unit changing commands is a script file having a predefined file name, and said pointer to corresponding update data comprises a file name.

16. The system of claim 14, wherein said updating code is arranged for deleting said script file upon its normal completion.

17. The system of claim 1, wherein said update code further comprises preparing code, capable of organizing the distribution of update data amongst designated memory units in said memory area.

18. Method of managing data in a system having a processor and a memory, said memory comprising a non volatile memory being erasable in memory units before being rewrittable, wherein the method comprises the steps of : a) designating at least one memory unit address and corresponding update data, b) erasing the memory unit having said address, and c) writing the corresponding update data in such memory unit.

19. The method of claim 18, wherein said non volatile memory comprises a program memory area and a data memory area, and step a) comprises designating addresses in said program memory area.

20. The method of claim 18, wherein an updating code is provided for implementing steps b) and c), and said updating code is located in a reserved portion of the non volatile memory.

21. The method of claim 18, wherein step a) further comprises an operation of storing in said memory a designated data comprising said at least one memory unit address and corres ponding update data, and step c) further comprises a final operation of altering at least a portion of said designated data, upon normal implementation of steps b) and c).

22. The method of claim 21, wherein said non volatile memory comprises a program memory area and a data memory area, and said designated data are stored in said data memory area.

23. The method of claim 20, wherein said updating code is part of the boot code of the system, and steps b) and c) are implemented during a boot of the system.

24. The method of claim 23, wherein step a) further comprises operations of reading the contents of said data memory area and checking whether one or more memory unit addresses and corresponding update data are present.

25. The method of claim 18, wherein step a) further comprises a preliminary operation of organizing the distribution of update data amongst designated memory units in said non volatile memory.