US20050063242A1

US20050063242A1 - Embedded software update methods and systems for digital devices

Info

Publication number: US20050063242A1
Application number: US10/986,258
Authority: US
Inventors: Yuqing Ren
Original assignee: Individual
Current assignee: Individual
Priority date: 2001-07-16
Filing date: 2004-11-09
Publication date: 2005-03-24
Also published as: US20030084434A1; WO2003009136A1; US6760908B2; US20040237068A1; EP1410181A1; JP2004536405A; KR20040022451A; CN1529847A

Abstract

A method and apparatus of updating an embedded software operative in a digital device by a software patch comprises first preparing said embedded software. The method also comprises designating at least one Flash block of a Flash memory in said digital device as Flash update block for software update programming, designating at least one area in RAM memory in said digital device as RAM update buffer for Flash programming, preparing Flash erasing function and Flash writing function, designating a memory area in said digital device as patch area, loading said embedded software into said digital device. The method then comprises generating a software patch, adapted to provide a predetermined function, transmitting said software patch to said digital device through a communications link, receiving said software patch by said digital device, updating at least one Flash block of said embedded software in the unit of Flash block said software patch.

Description

RELATED APPLICATION (FOR US)

The present application is a continuation of a prior patent application, Ser. No. 10/876,503, filed Jun. 24, 2004, which is a continuation of application, Ser. No. 10/195,199, filed on Jul. 15, 2002, now U.S. Pat. No. 6,760,908, claiming priority from provisional applications, Application No. 60/305,704, entitled “Embedded Software Patch System”, filed on Jul. 16, 2001, and No. 60/354,915, entitled “Embedded Software Patch System”, filed Feb. 8, 2002. The prior applications are hereby incorporated into this application by reference as if fully set forth herein.

FIELD OF THE INVENTION

The present invention is related to digital electronics products with embedded software operating systems, and more particularly related to methods of updating, correcting, modifying or upgrading the embedded software in such digital devices before or after the products have been released to market.

ART BACKGROUND

For the digital devices, such as cellular phones, PDAs and set-top boxes, their digital technology is based on large-scale embedded software system. Despite improvement in various stages of digital device development and manufacturing, after a digital device has been released to the field, manufactures will sometimes go through improvement, enhancement or upgrades, which may require a change in the embedded software.
Software update systems for embedded software have been in use by industry. However, they have not provided an efficient way for updating embedded software with small amount of update data. They also have failed to teach how to transmit such software update data to the digital devices. For example, U.S. Pat. No. 5,699,275, to Beasley, teaches the use of “rewrite” to update embedded software in a digital device that uses Flash/ROM memory. Nowadays, as the size of embedded software in digital devices gets bigger and bigger, “rewrite” is both time-consuming and costly and hence not an efficient method for a real commercial system.
A software update system for digital devices is best understood from a system architecture perspective. Reference is to FIG. 1, where a simplified conventional microprocessor system is illustrated. A microprocessor system in a typical digital device may comprise a Central Processing Unit (“CPU”) 100, Random Access Memory (“RAM”) 110, Flash/ROM memory 120, and some peripheral devices 130. A software program resides in Flash/ROM memory 120, and is read by CPU 100 during execution. Flash is a type of constantly-powered nonvolatile memory that can be erased and reprogrammed in units of memory called blocks. The term “ROM” stands for “Read Only Memory”.
Similar to the microprocessor system of FIG. 1, a Digital Signal Processor (“DSP”) system in a conventional digital device may comprise a DSP core 200, RAM 210, Flash/ROM memory 220, and some peripheral devices 230, as shown in FIG. 2. A software program resides in Flash/ROM memory 220, and is read by DSP core 200 during execution.
As is well understood, a typical digital device, e.g. a digital cellular phone, normally contains a microprocessor system, and may also contain a DSP system. A typical software update system can be configured or adapted to reside in the embedded software of the microprocessor system and/or the DSP system of a digital device. A simplified drawing of a conventional software architecture of a software update system in a digital device is illustrated in FIG. 3.
Referring to FIG. 3, the patch receiving module 300 is for receiving software patch data. It may include mechanism for data receiving either from wired link or wireless link, mechanism for data error detection and/or mechanism for data security check. After the patch receiving module 300 correctly receives patch data, it will pass the patch data to the patch programming module 310. The patch programming module 310 is for writing patch data into the patch database 320 and/or some program code areas. It may include program for writing data into Flash, NVM, EEPROM memory, and/or other types of memory. The patch database 320 is a memory area in Flash memory and/or other types of memory, which is for containing patch data.
It would be desirable to have an effective patch update system for the embedded software in digital devices.

SUMMARY OF THE PRESENT INVENTION

The present invention is directed to a method of updating embedded software using software patches. This approach can separately update one or multiple parts of the embedded software without changing program code of the other parts. Such updates can be transmitted to the target digital devices through wireless or wired transmission.
In accordance with one embodiment of the present invention, a method and apparatus of updating an embedded software operative in a digital device by a software patch is disclosed. The method comprises preparing said embedded software, which comprises designating at least one Flash block of a Flash memory in said digital device as Flash update block for software update programming, designating at least one area in RAM memory in said digital device as RAM update buffer for Flash programming, preparing Flash erasing function and Flash writing function, designating a memory area in said digital device as patch area, loading said embedded software into said digital device. The method then comprises generating a software patch, adapted to provide a predetermined function, transmitting said software patch to said digital device through a communications link, receiving said software patch by said digital device, updating at least one Flash block of said embedded software in the unit of Flash block with said software patch.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

1. A method and system of updating one or multiple software functions of embedded software without changing software code in the other functions is disclosed. In the following detailed description, numerous specific details are set forth to provide a full understanding of the present invention. It will be obvious, however, to one ordinarily skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and techniques have not been shown in detail so as to avoid unnecessarily obscuring the present invention. Additionally, headings are used throughout the description as a matter of convenience and for ease of references only. It should note that what is meant by “embedded software” herein is the software program written in C/C++/Java/Assembler, or other software programming languages, as well as any executable machine code of CPU/Microprocessor or DSP (“Digital Signal Processor”), for operating the digital devices. It should also be noted that what is meant by “software patch” herein is a block of software update data for updating the embedded software in the digital devices.
2. Composition of Software Update System
The embedded software in a digital device is typically stored in ROM/Flash memory, and the present invention is directed to updating the embedded software stored in Flash memory. The software update system of the present invention can be configured or adapted to reside in the embedded software of the microprocessor system and/or the DSP system of a digital device. The software update system in accordance with one embodiment of the present invention, when it is implemented in a digital device, may be structured to comprise a software module 300 for patch receiving, a software module 310 for patch programming and a patch database 320, as illustrated by FIG. 3.
3. Software Update Methods
3.1 Flash Memory Composition
The software update methodology of the present invention will now be described first with references to a basic Flash memory composition and operation. As shown in FIG. 4, a typical Flash memory chip is composed by multiple Flash banks, Bank-1, Bank-2, . . . Bank-N, and each bank can be further separated into multiple Flash blocks. For example, Bank-1 can be separated into Block-1, Block-2, . . . , Block-M. Though some other terms, such as Flash “partition”, can also be used to represent a Flash “bank”, in this application, only the term Flash “bank” is used to represent the meaning.
The embedded software in a digital device is typically programmed into K banks of the Flash memory, Bank-1, Bank-2, . . . , Bank-K, where K is the total number of the Flash banks that the embedded software occupied, and K is less or equal to N, where N is the total number of banks allocated.
In a typical Flash memory chip, such as the Intel 28F320W30 Flash memory chip, only one Flash bank at a time can be in the state of active programming or erasing. While writing or programming data into an area in a Flash bank, for example Flash Bank-A, it is not permissible to read any data stored in that Flash Bank-A, though some values of Flash registers can be read or using some addresses in the Flash Bank-A. However, when writing data into the Flash Bank-A, it is permissible to read data stored in any other Flash banks different from Bank-A. When erasing operation is performed on a Flash bank, each Flash block in the Flash bank can be separately erased.
Flash memory has a feature that each data bit of the memory can only be changed from state “1” to state “0” during Flash programming or data writing. A data bit in Flash memory cannot be changed separately from state “0” to state “1”. It depends on Flash erasing, for example, erasing a Flash block, to reset all the data bits in the Flash block to state “1”. Therefore when a part of the program code in Flash memory needs to be updated, it is not possible, nor permissible, to directly over-write the original program code with the new updated program code, without erasing the corresponding Flash block.
3.2 Using Flash Block as the Unit for Software Update
Due to the above limitations of conventional Flash memory operation, some methods of utilizing instead the Flash bank as the unit to update embedded software have been developed by those in the art. They use the Flash bank as the basic unit, because it is possible to read data from a Flash bank and simultaneously write data into another Flash bank. They use an entire Flash bank as a “buffer” to temporarily store the updated software during software updating process. During software updating, and the embedded software is updated in the unit of Flash bank.
However, using a Flash bank as a “buffer” is not an efficient way for utilizing Flash memory, because a Flash bank can have several mega bits, which is quite a big area. In some digital devices, one entire Flash bank may not be available as a buffer just for software update purpose. Even if the bank may be available, updating an entire bank has proved to be an extremely wasteful and inefficient way of updating what may be a minor code revision.
As will be described, the present invention is directed to the use of a Flash block, which is much smaller than a Flash bank, as the “buffer” for software update, and the embedded software is updated in the unit of a Flash block, instead of the unit of a Flash bank. With this methodology, only one Flash block will be enough as the buffer for the purpose of software update programming, which is much smaller than one Flash bank. Another advantage of this methodology is that, because it becomes possible to make software update in the unit of a Flash block, software updating can be performed in a more precise and efficient way than the conventional method based on the unit of a Flash bank. Thus, the software update programming can be completed in a shorter period of time.
3.3 Updating Software Directly in Original Flash Area
When the original embedded software is located in a first Flash bank, the aforementioned Beasley's U.S. Pat. No. 5,699,275 disclosed a method of writing new program into a second Flash bank and using the second Flash bank for execution after a system reset. However, as discussed before, it is not an efficient way of using Flash memory by allocating a big blank Flash bank for containing the entire new version of the embedded software while the original is running in another Flash bank. And this problem, as well as its limitation, will be more exacerbated when the embedded software becomes big, occupying multiple Flash banks.
In order to efficiently use Flash memory, this invention is directed to a methodology to make software update directly at the original Flash area, without the need of preparing a big blank Flash bank for containing the entire new version of the embedded software. In accordance with this method, the embedded software is updated in the unit of Flash block, and the updated program code is still allocated at the original Flash blocks. Therefore, a software update system in accordance with the present invention will greatly save the Flash memory usage for software update.
The details of performing software update in the unit of Flash block are disclosed in the following sections.
3.4 Putting Flash Programming Functions Into RAM Memory
Flash programming functions, such as data writing function and flash erasing function are stored in Flash memory, for example, in a Flash bank, Bank-K. Here more specifically, the Flash programming functions refer to a “Flash-Writing-Function” and a “Flash-Erasing-Function”. The Flash-Writing-Function is a function to write or program data into Flash memory. The Flash-Erasing-Function is a function to erase a block of Flash memory.
Let us look at an example that during software update, it is necessary to update some program code in the flash Bank-K. If the Flash programming functions stored in the Bank-K are also running on the Bank-K, the CPU/DSP needs to read program instructions of the Flash programming functions from Bank-K for execution, while performing Flash programming of software-update actions, such as data writing or flash erasing, on the same Bank-K for updating some program code in the Bank-K. However, as previously discussed, it is not possible to perform reading and writing operation simultaneously on the same Flash bank. In accordance with the present invention, Flash programming functions, i.e. the Flash-Writing-Function and the Flash-Erasing-Function, are copied into RAM memory, and then run in the RAM memory. When the Flash programming functions are running in RAM memory, and it becomes possible to perform Flash data writing and Flash block erasing operations on Bank-K, for updating the embedded software located in the Bank-K, thus avoiding the otherwise prohibited simultaneous data reading and writing operations on the Bank-K during Flash programming.
Some existing program compilers can also support putting software functions into RAM memory and running those functions in RAM memory, by setting some configuration parameters for software compilation (including module linking). In this case, copying the Flash programming functions into RAM memory can be done by the compilers. If a software compiler does not support this function, some software functions can be created for achieving the similar actions, and added into the embedded software.
Note that if a digital device has enough Flash memory space, but very limited RAM memory space, the Flash programming functions can be put into a Flash bank separated from the Flash banks containing the embedded software that may need to be updated, instead of being put into RAM memory. This Flash bank is thus used for the purpose of Flash programming for the other Flash banks. This method can be used as a replacement of the above method of using RAM memory.
3.5 Using a Buffer in RAM Memory
During software update, sometimes it may be desirable to copy some program code from one block, Block-A, of a Flash bank to another block, Block-B, in the same Flash bank. However, as previously discussed, it is not possible to perform reading and writing operation simultaneously on the same Flash bank. To overcome this problem, a memory area located in RAM memory is utilized for buffering data during Flash programming. The buffer in RAM memory can be named as “RAM-Update-Buffer”. The size of RAM-Update-Buffer can be decided based on how large the space in RAM memory in the digital device can be used for software updating.
As shown in FIG. 5, when performing Flash programming with the RAM-Update-Buffer, for example, in the same Flash bank, copying some program code from Block-A to Block-B, the program code will be first copied into the RAM-Update-Buffer from Block-A, and then be programmed into Block-B by reading the data from the RAM-Update-Buffer. In this way, the otherwise prohibited simultaneous reading and writing operations on the same Flash bank can be avoided. If the RAM-Update-Buffer is no big enough to contain the whole program code that need to be copied, the program code that needs to be copied can be separated into multiple parts to ensure each part can fit into the RAM-Update-Buffer. In this case, Flash programming is performed for each part of the program code, by first copying the code into the RAM-Update-Buffer from Block-A, and then writing the code into Block-B by reading the code from the RAM-Update-Buffer.
As a summary, copying data from a Flash block, Block-A, into another Flash block, Block-B, can be performed in the following steps.
Copying Data From Block-A to Block-B:
Step1: Check the length of the data to be copied from the Block-A with the size of the RAM-Update-Buffer, and copy the amount of the data in the Block-A that can fit into the RAM-Update-Buffer into the RAM-Update-Buffer.
Step2: Run the flash programming functions in the RAM memory to read the data from the RAM-Update-Buffer and write the data into the Block-B.
Step3: If there is still data left in the Block-A that need to be copied into the Block-B, go back to Step1 for further copying, until all the data is copied into the Block-B.
3.6 Updating a Flash Block
When some part of the embedded software in a digital device needs to be updated, a corresponding software patch can be generated to contain the information of update code for updating the part of the embedded software. The software patch can be sent to the digital device via a communication link, either a wired link or a wireless link.
After correctly receiving the software patch by the patch receiving module 300 in FIG. 3, the digital device passes the patch data to the patch programming module 310. The patch programming module 310 is for writing patch data into the patch database 320 and/or the program code area of the part that needs to be updated.
As discussed on the above Section 3.1 to Section 3.5, this invention uses a Flash block as a “buffer” for software update, and performs software update in the unit of Flash block. In order to support the software update, the following preparation should preferably be performed.
Pre-Process Preparation:
(1) Reserve one Flash block as a buffer for update-programming purpose, as discussed in Section 3.2. This block can be named as “Update-Buffer-Block”. If the sizes of Flash blocks are not identical, one or multiple Flash blocks shall be reserved to ensure having enough buffer space for buffering the data of the biggest Flash block. Here for convenience, the term of “Update-Buffer-Block” is still used for the cases that multiple Flash blocks are used for data buffering, because they can be treated as a single buffer. The buffer erasing operation should be performed for each block when necessary.
(2) Reserve a RAM-Update-Buffer in RAM memory, as discussed in Section 3.5. The size of the RAM-Update-Buffer is assumed to be T bytes.
(3) Placing the Flash programming functions, i.e., the Flash-Writing-Function and the Flash-Erasing-Function, into RAM memory for running, as discussed in Section 3.4.
If the program code of in a Flash bank, more specifically in a Flash block of the bank, needs to be updated, here the Flash block is named as “Block-A”, the update programming can be performed with the following steps. Note that these steps are only for exemplary purpose to show the inventions details, implementation details may vary based on the situation of the embedded software and the digital device. FIG. 6 also shows the exemplary programming steps for illustration purposes.
Flash Block Updating Process for Updating Flash Block-A:
Step 1:
Erase the Update-Buffer-Block by running the Flash-Erasing-Function in the RAM memory, so that all the data bits in the Update-Buffer-Block are in state “1”.
Step 2:
Copy the program code of the Block-A into the Update-Buffer-Block, except the part of the program code to be updated. That means, the corresponding code area in the Update-Buffer-Block for the part of the program code to be updated, which can be named as “Update-Area”, should not be written with the original program code of Block-A. The process of copying data from the Block-A into the Update-Buffer-Block is previously described by the process of “copying data from Block-A to Block-B” in Section 3.5. If necessary, other methods of copying data from one FLASH block to another FLASH block can be used.
Step 3:
Copy the updated program code into the Update-Area of the Update-Buffer-Block. If the updated program code is stored in an area of Flash memory beforehand, the process of copying the updated program code into the Update-Area of the Update-Buffer-Block may follow the process of “copying data from Block-A to Block-B” previously described in Section 3.5, if necessary, other methods of copying data from one FLASH block to another FLASH block.
Step 4:
Erase Block-A by running the Flash-Erasing-Function in RAM memory.
Step 5:
Copy the content in the Update-Buffer-Block into Block-A. The process of copying data from the Update-Buffer-Block into the Block-A may follow the process of “copying data from Block-A to Block-B” previously described in Section 3.5, if necessary, other methods of copying data from one FLASH block to another FLASH block can be used.
With the above exemplary steps, the program code in Block-A that needs to be updated can be replaced with the new program code, while the other code in the Block-A remains unchanged and also the program code in other Flash blocks remain unchanged. Note that the above Step 3 can be skipped if a step of copying the updated program code directly into the corresponding Update-Area of the Block-A is added after the above Step 5. In this case, the Update-Area of the Update-Buffer-Block in the above Step 5 is “empty,” i.e. filled with hexadecimal “0×FF”, when the entire block is copied back to the Block-A. The program update code then overwrites the now-empty Update-Area in the Block-A, thus effecting a Block update.
If there are multiple Flash blocks in the digital device that need to be updated, the above Update-Programming steps can be carried out for each of the blocks.
In order to ensure that the Update-Programming can be performed successfully, it may be necessary to ensure that there will be no task switching happening during the process of the Update-Programming in the Real Time Operation System of the digital device. This can preferably be achieved by setting the task or thread for the Update-Programming in the Real Time Operation System to the highest priority, and disabling the interrupt functions of CPU/DSP during the Update-Programming.
As can be appreciated, the Flash Block Updating methodology described above can be done without having to pre-process or prepare any insertion or jump checkpoints into the code during initial programming. Also, the existing code in the digital device does not need to be altered to accommodate the Updating methodology, thus making it quite compatible with the goal of providing software updates to any electronic or digital devices already out in the field.
3.7 Software Update Methodology
Several software update methods are disclosed in this section, in accordance with the previously described “Method of updating Flash block” in section 3.6.
One embodiment of the software update is now described with reference to FIG. 7. Here, after a software patch or program code of update has been received, it can be programmed into an update code area or patch area in Flash memory. When CPU/DSP execution is running to the part of program that needs to be updated, the CPU/DSP execution can be directed to the place of the updated program code in the update code area, or patch area, and uses the updated program code for execution, instead of using the original part of program for execution. To redirect the CPU/DSP execution, at the beginning of the program part to be updated, a jumping instruction can be allocated for jumping to the patch area. The software modification on the original code area, such as allocating a jumping instruction over the original code, can be performed with the update method described in Section 3.6, based on the Flash block update on the corresponding Flash blocks. As such, by allocating a jumping instruction at the beginning of the program to be updated using the aforementioned Flash block update methodology, the CPU/DSP execution can be redirected to the update code area, where the software patch or program code of update has been received and programmed.
FIG. 8 shows another embodiment of the software update methodology, where some updated program code (Update Program Code Part 1) can be directly put into the program code area of the part that needs to be updated, while other updated program code (Update Program Code Part 2) can be put into the Update Code Area. When the size of the updated program code is bigger than the size of the part of the original program code that needs to be updated, Update Code Area can be used to contain the program code portion that cannot fit into the original location in the program code area. The patch programming on the original code area can be performed with the method described in Section 3.6, based on the Flash block update.
FIG. 9 shows yet another embodiment of the update methodology, where the updated program code can be directly put into the program code area of the part that needs to be updated. This can be used in the case when the size of the updated program code is not bigger than the size of the part of the original program code that needs to be updated. At the end of such update program, a jump or skip instruction is added so that CPU execution can jump over or skip the portion of the original code that is now obsolete. The patch programming on the original code area can be performed with the method described in Section 3.6, based on the Flash block update.
4. Methods of Error Recovery During Software Update
During the process of updating software, errors or interrupts, such as electricity power loss, could happen. For example, when a cellular phone, or a digital device, is performing software update using the method introduced in Section 3, and during the Step 5 of Section 3.6, there is a power loss, e.g. exhausted battery. As a result of the power loss, the program code in the Update-Buffer-Block cannot be correctly copied into Block-A. When the cell phone is turned back on, after re-charging or replacing the battery, a CPU/DSP execution error will happen at Block-A, because there is no correct program code there. In accordance with another aspect of the invention, a methodology of error recovery for patch programming is introduced, which is shown in FIG. 10.
As shown in FIG. 10, for achieving error recovery from power loss, a software routine, named “Update-Programming-Checking-Routine”, can be put at or close to the bootstrap code (program execution start point), so that when the embedded software starts to run from power-on or system reset, it will execute the Update-Programming-Checking-Routine. Though this routine is always executed from power-on or system reset, it only becomes effective after the cell phone or digital device is powered back on, after certain interruption. The Update-Programming-Checking-Routine checks whether there are any patch programming tasks that have not been completed for software update. If there are such incomplete tasks, patch programming for software update will be executed to complete the tasks. Then, the execution is back to the original program for system power-on.
In order to prevent data loss, after correctly receiving a software patch or a piece of new program code for software update, the digital device can write the new program code into Flash memory for buffering, so that even if there is a power loss during software update process, the received program code will not be lost. This area can be named as “Patch-Data-Buffer”. Some flag parameters can be used as the status indication of update-programming, which can be named as “Patch-Programming-Flag”. The Patch-Programming-Flags can be saved in an area of Flash memory. For example, a Patch-Programming-Flag composed by 5 bits, or n bits, can be reserved in an area of Flash memory to indicate the status of the 5 steps, or n steps, of the patch programming discussed in the above Section 3.6. All the bits of the flag are all in state “1” at first. When one step of the 5 steps is completed, one corresponding bit of the flag will be changed from “1” to “0”. After returning from a power loss occurring at one of the 5 steps, patch programming can be restarted by the Update-Programming-Checking-Routine. For example, if the power loss happened before Step 4, patch programming can be re-started from Step 1. And if the power loss happened after Step 4, patch programming can be re-started from Step 4 of Section 3.6.
After the update programming for a patch has been completed, the Flash area for the Patch-Data-Buffer and the Flash area for the Patch-Programming-Flags can be erased so that the next patch can reuse the same areas. In order to erase these areas, that is to set all the bits in the areas back to the state of ‘1’, the method of Section 3.6 for updating a Flash block can be used to update every bit in these areas to “1”. As discussed in Section 3.6, the update can be carried out in the unit of Flash block, and the bit values of the areas in the corresponding Flash blocks can be changed back to state of“1”.
5. Methods of Patch Code Generation
As is well understood by those skilled in the art, a software patch is the replacement of a piece of the original program code. When a programmer finishes the changes on the program source code, the program source code can be compiled into an object file. The object file includes the information of an executable command code, though some parameters, such as the offsets of function calls, need to be updated by the linker of the compiler. After linking stage of the software compilation, a “map” file of the executable embedded software can be generated by the linker software. The map file may include information of variables and function addresses.
In accordance with yet another aspect of the invention, a methodology of patch generation is introduced. A software patch can be composed by new program code and its corresponding location or memory address information in the embedded software of the digital device. The information in the object files of the new program code and the map files of both the original executable embedded software and the updated executable embedded software can be used for generating a software patch. For example, for updating an original software function with a new version of the function, the information of the corresponding executable CPU instruction code from the new object file generated based on the new version of the function, can be extracted and used as the updated program code in a patch for updating the function. Furthermore, in the map file of the original executable embedded software, the information of the function addresses can be used in the patch as the address information related to place that the patch code need to be written on.
Some software tools can also be developed for the automatic patch generation based on the information from the object file and the map file.
6. Patch Transmission and Patch Receiving
6.1 Patch Data Transmission.
First, we describe how the software patch may be transmitted from a patch server (to be described below) to digital devices. By “patch server,” it should be appreciated by those skilled in the art that it may be a system that can dispatch or transmit a software patch to one or more digital devices in the field, preferably through existing communication infrastructure or channels, such as a wireless link, or a wired connection. The patch server may have any level of automation for its operation. Upon transmission, a digital device receives patch data with its Patch Receiving Module 300 shown in FIG. 3. During or after the patch data transmission, the digital device may send signals (or messages) to the patch server for acknowledgment.
For transmitting patch data to digital cellular phones, SMS (Short Message Service) messages can be used for this purpose. SMS messages can be sent to cellular phones based on GSM, GPRS, WCDMA, CDMA or other wireless and wired technologies. Both point-to-point SMS messages and broadcast SMS messages can be used for patch transmission. Sometimes, broadcast SMS messages are also called with some other names, such as cell broadcast SMS messages. When broadcast SMS messages are used for patch transmission, some fields of the SMS messages can be set to some values, for example, some “reserved values”, so that the digital devices that have not installed the patch system can simply discard the SMS messages, and only the digital devices that have the patch system installed will process the SMS messages for software update. For example, in the SMS message defined in the GSM standard, there is a field named “Coding Group” that may have some “reserved” values not being used. In the SMS messages used for carrying patch data, the “Coding Group” can be set to one of the reserved values, so that the digital device without having patch system will simple discard the SMS messages without displaying the SMS message content to users because the digital devices cannot process the reserved “Coding Group”. But for those digital devices that have the patch system installed can process the SMS messages for software update based on a predetermined protocol.
Sometimes, the digital device needs to send a message to patch server to inquire available patches or reporting patching status of the digital device. The identification number of patch server, such as a phone number or platform number can be pre-installed into the digital device, so that the digital device can use the server number to send the necessary messages to the patch server.
Sometimes, the patch server needs to use the identification number of the digital device, such as a phone number to send update notice to the digital device. The identification number and other related information of the digital device can be registered on the patch server for this purpose. Many methods of the registration can be considered. For example the digital device information can be registered by the digital device user on a web site by entering the information of the digital device and the corresponding identification number; or the digital device user can send a message to the patch server including the product information and the product identification number.
For error detection, before patch transmission, patch data can be processed with information of CRC (Cyclic Redundancy Codes), checksum or other schemes as can readily be implemented by those skilled in the art. After the digital device receives a patch, the patch data is checked with CRC process to detect transmission errors.
In the event that a digital device cannot correctly receive patch data, the patch server shall re-send the patch data to the digital device. For example, patch retransmission can be based on a timer-based mechanism: The patch server has a timer for patch retransmission. After the patch server sends out a patch to a digital device, it will start the timer. If the patch server does not receive any corresponding reply message (e.g., patching status report) from the digital device when the timer times out, the patch server will re-send the patch data packets to the digital device. In some special cases where a patch server does not receive any reply messages from the digital device after the patch server has performed patch re-transmission for a predetermined number of times, the patch server may stop the retransmission for a while. It should be appreciated by those skilled in the art that other ways of timing the transmission and re-transmission of patches can readily be implemented in connection with the teaching of the present invention.
In the previous example of using SMS messages, there is one patch signaling message named Patch Status Report, which is sent from a digital device to a patch server and contains the current patch status information of the digital device. If the digital device receives a patch without error, it will send Patch Status Report via a reverse SMS message to the patch server at the time:

- (a) when the digital device finds out that the received patch had been already programmed successfully, or
- (b) when the digital device successfully finishes the patch programming.

6.2 Patch Data Encryption.
Before patch data is transmitted to a digital device, it can be encrypted for security protection. And after receiving the encrypted patch data, the digital device decrypts the patch data before using it. This is important to the cases such as using SMS message for patch data transmission, because SMS messages may be sent from any people to any cellular phones. This invention discloses some methods for patch encryption.
6.2.1 Dynamically Generating Encryption Keys With a Predetermined Algorithm
Before patch data is transmitted to a digital device, the patch data can be encrypt with one or multiple encryption algorithms, such as Triple-DES etc. These encryption algorithms normally need encryption keys for encryption calculation. For security protection, the encryption keys can be generated based on a highly complicated and secured software function, and can be named as “Encryption-Key-Generation-Function”. Only the patch generator, such as in a patch server, and the digital device have the Encryption-Key-Generation-Function. When this function is put into the digital device, it can be put into a safe place in the digital device, such as SIM card of cellular phones for further protection. Without understanding the Encryption-Key-Generation-Function, it is not possible to correctly generate encryption keys, and patch data cannot be encrypted correctly. With this method, encryption becomes more secure, because encryption keys are not unchangeable and saved in a digital device, instead, the encryption keys can be dynamically generated by an algorithm and can be changeable.
6.2.2 Secret-Data for Encryption
As shown in FIG. 11, the Encryption-Key-Generation-Function can have multiple input parameters, which can be named as “Secret-Data”. The Secret-Data can be some predetermined parameters. The Secret-Data can also be some dynamically generated parameters. For example, the Secret-Data can be generated based on patch identifier information of a specific patch. Because the patch identifier is different from one patch to another patch, the Secret-Data of patch identifier is also different, and thus the generated encryption keys from Encryption-Key-Generation-Function are different from one patch to another patch. And in this case, the patch identifier information can be acknowledged between patch generator and the digital device for patch encryption and patch decryption. Some other information such as date and time information can also be used as an element for dynamically generating the Secret-Data, so that the encryption keys generated by the Encryption-Key-Generation-Function becomes time-sensitive.
6.2.3 Secret-Data for Encryption Transmitted From Digital Device
As shown in FIG. 12, some Secret-Data can also be generated dynamically by digital device and sent to the patch generator for patch encryption. For example, a big random number can be generated in a digital device and sent to patch generator when the digital device inquires whether there are patches available for software update, and the patch generator can use this number for encrypting patch for this digital device. The encryption process may have the following steps.
Step 1: A digital device generates a Secret-Data.
Step 2: The generated Secret-Data is sent from the digital device to a patch generator.
Step 3: The Secret-Data is used for encrypting a patch in the patch generator.
Step 4: The encrypted patch from Step 3 is sent to the digital device.
Step 5: The digital device uses the Secret-Data generated in Step 1 to decrypt the received patch.
6.3 Patch Data Composition.
With reference to FIG. 13, the composition of patch data is now further described. Patch data is preferably separated into several patch data packets, and one patch data packet can be carried by one message.
In the exemplary use of SMS messages, one patch data packet may be carried by one SMS message. In order to identify a patch SMS message from other regular SMS messages, some characters in a patch SMS message can be set to some predefined special characters or numbers by the patch server before patch delivery.
The relation between patch data and patch data packets is shown in FIG. 13. A patch data packet can be separated into packet overhead field and payload data field. It should be appreciated by those skilled in the art that other ways of design packet overhead for transmitting patch data packets can readily be implemented in connection with the teaching of the present invention.
The payload data in the patch data packet may contain the whole or one part of patch data.
If some part in the new program code used for updating is similar or identical to some part in the original program code, some instruction of using the original code can be put into the patch, instead of the new code itself. In general, when a piece of program needs to be updated, only the information of the difference between the new code and the original code should be put into patch. In this way, the duplicated information of program code can be removed from a patch, in order to reduce the patch size. After receiving such a patch, the digital device can restore the new program code by using the information of the original program code and the difference information between the new code and the original code.
7. Collecting and Reporting Software Error Information in Digital Devices
It is preferable to collect information about the software errors existing in the embedded software of a digital device and report the information to software developer, so that the software developer can create the corresponding software patches to fix the errors in the digital device, or modify the corresponding software program to remove the errors from future digital devices. Here some methods are disclosed for collecting and reporting the information about the software errors. FIG. 14 describes a system for collecting and reporting information about software errors.
Collecting Information About Software Errors in a Digital Device
Useful information related to software errors can be collected and recorded into the error database 1430. Here two types of information—software error traces and system reset information are used 1410 to show how to collect and record the information.
When a software developer creates a software program, some software traces can be inserted into the program so that the software developer can detect how the software is running by looking at the trace output. Especially, some traces can be inserted for software error cases, so that when software problems happen, the corresponding traces can be output for software debugging purposes. The information about those errors traces can be sent to the error database 1430 for further processing.
When some fatal software errors happen and cannot be recovered, the CPU/DSP in the digital device may reset. For example, when CPU/DSP is instructed to read data from a memory address where actually there is no memory there, an internal error will happen to cause CPU reset. Any useful information related to a reset can be retrieved and recorded. For example,

- Call stack information: information of procedures, programs, and methods that are executing right before reset.
- Reset type: the information about why reset is performed.
- Time stamp: time information when error or reset occurs

Saving Error Information
The information of software errors, such as error traces and reset information can be saved in the error database 1430, which is an area of Non-Volatile memory. The information of error traces can be saved into error database when error traces is produced. The information of system reset can be saved into error database right before the system reset, or for some cases after the system reset.
Error Information Processing
When it is necessary to analyze the error information, the data saved in the error database can be retrieved for further processing 1440. For example, the data can be analyzed and summarized, so that it becomes easier for the software developer to understand. The data can be compressed to remove redundancy and un-important part before being transferred to an outside server or database.
Error Information Transmission
After the above processing step, the compressed data can be transferred 1450 to an outside server or a database, and later on, the software developer can use the data to find the software errors and make the corresponding corrections. For example, for a typical digital cellular phone, the compressed data can be put into SMS messages for transmission. To enhance security, the data can be further encrypted before transmission; and at receiver side, the received data will be decrypted.
Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the scope of the present invention. Accordingly, the invention should only be limited by the claims included below.
Glossary of Abbreviations
ASCII. American Standards Committee for Information Interchange
CPU. Central Processing Unit.
DSP. Digital Signal Processor
Flash. A type of constantly-powered nonvolatile memory that can be erased and reprogrammed in units of memory called blocks.
MCU. Micro Processor Unit.
PDA. Personal Digital Assistant
RAM. Random Access Memory.
ROM. Read-Only Memory.
SMS. Short Message Service.

Claims

1. A method of updating an embedded software operative in a digital device by a software patch, comprising:

preparing said embedded software comprising:

designating at least one Flash block of a Flash memory in said digital device as Flash update block for software update programming;

designating at least one area in RAM memory in said digital device as RAM update buffer for Flash programming;

preparing Flash erasing function and Flash writing function;

designating a memory area in said digital device as patch area;

loading said embedded software into said digital device;

generating a software patch, adapted to provide a predetermined function;

transmitting said software patch to said digital device through a communications link;

receiving said software patch by said digital device;

updating at least one Flash block of said embedded software in the unit of Flash block with said software patch.

2. The method of claim 1, wherein said updating at least one Flash block comprises at least one of the following:

allocating a jump instruction at the beginning of the program part of the embedded software to be updated, for jumping to said patch area when running a new update code in said patch area;

overwriting some part of the program part of the embedded software to be updated with a new update code, and allocating, at the end of the part, a jumping instruction for jumping to said patch area when running the new update code in said patch area;

overwriting the program part of the embedded software to be updated with the new update code.

3. The method of claim 1, wherein said step of preparing Flash erasing function and Flash writing function further comprises:

putting at least one function of said Flash erasing function and said Flash writing function into RAM memory.

4. The method of claim 3, wherein said step of putting Flash programming functions into RAM memory comprises at least one of the following:

using a software function for copying said Flash programming functions into RAM memory, and

using a software compiler for allocating said Flash programming functions into RAM memory

5. The method of claim 3, wherein said Flash function is run in one of the following ways:

a) in said RAM memory;

b) in at least one software interrupt handler routine;

c) in highest priority task of software operation system of said embedded software.

6. The method of claim 1, wherein said updating further comprises:

erasing said Flash update block;

copying data from said Flash block into said Flash update block, except the part to be updated;

writing update data into the part to be updated in said Flash update block;

erasing said Flash block;

copying data from said Flash update block into said Flash block;

7. The method of claim 1, wherein said updating at least one Flash block further comprises:

erasing said Flash update block;

copying data in from Flash block into said Flash update block, except the part to be updated;

erasing said Flash block;

copying data from said Flash update block into said Flash block;

writing update data into the part to be updated in said Flash block;

8. The method of claim 6, wherein said copying data from a first Flash block to a second Flash block comprises:

checking whether said data can fit into said RAM update buffer, and if not, separating said data into multiple parts to ensure each part of said data can fit into said RAM update buffer;

for each part, performing the steps of:

reading said data from said first Flash block and writing said data into said RAM update buffer;

reading said data from said RAM update buffer and writing said data into said second Flash block.

9. The method of claim 7, wherein said copying data from a first Flash block to a second Flash block comprises:

for each part, performing the steps of:

10. The method of claim 1, wherein said preparing said embedded software further comprises:

allocating at least one update programming checking routine at or close to the bootstrap code (program execution start point), to check whether there are any patch programming tasks that have not been completed for software update, and

if yes, executing patch programming for software update to complete the tasks;

returning execution to the original program for system power-on.

11. The method of claim 10, further comprising:

using at least one bit of Flash memory as patch programming flag to indicate patch programming status.

12. The method of claim 1, wherein said step of generating a software patch further comprises:

using at least one of the following information to generate said software patch:

Object file of the new program code;

Software function and variable map file generated by software compiler.

13. The method of claim 1, wherein said step of transmitting said software patch further comprises:

using at least one SMS message to carry data of said software patch.

14. The method of claim 1, wherein said step of preparing said embedded software further comprises:

pre-installing identification information of patch server into said digital device.

15. The method of claim 1, further comprising:

registering an identification number and other related information of the digital device on the patch server, using at least one of the following methods:

registering the digital device information by the digital device user on a web site by entering the information of the digital device and the corresponding identification number;

sending by the digital device user of a message to the patch server including the product information and the product identification number.

16. The method of claim 1, further comprising:

said digital device sending at least one message to the patch server for at least one of the following:

for reporting patching status;

for inquiring available patch information.

17. The method of claim 1, wherein said step of generating a software patch further comprises:

adding at lest one of the following data to said software patch for data error detection:

CRC (“Cyclic Redundancy Codes”) data;

Checksum data.

18. The method of claim 1, wherein said step of generating a software patch further comprises: encrypting said software patch before patch transmission.

19. The method of claim 18, further comprising:

encrypting said software patch using at least one of the following information:

identification information of said software patch;

identification information of said digital device;

time information;

dynamically generated secret data.

20. The method of claim 18, further comprising the following steps:

said digital device generating secret-data and sending said secret-data to a patch generator;

said patch generator receiving said secret-data to encrypt said software patch using said secret-data;

said patch generator sending encrypted software patch generated to said digital device;

said digital device receiving said encrypted software patch and uses said secret-data generated to decrypt said received encrypted software patch.

21. The method of claim 1, wherein said step of generating a software patch further comprises:

putting the information of the difference between the new code and the original code into said software patch to reduce transmission amount.

22. A method of updating an embedded software operative in a digital device by using a software patch, comprising:

designating at least one area in a RAM memory in said digital device as RAM update buffer for Flash programming;

designating a patch area in said digital device;

preparing said embedded software;

preparing said software patch;

loading said embedded software into said digital device;

preparing said software patch for transmission to said digital device through a communication link.

23. The method of claim 22, further comprising:

encrypting said software patch prior to transmission, with an encryption key generation function.

24. A method of updating an embedded software operative in a digital device, comprising:

receiving a software patch by said digital device through a communications link;

updating at least one predetermined Flash block of a FLASH memory of said digital device containing said embedded software, in the unit of Flash block with said software patch, by at least one of the following:

a) allocating, at the beginning of the program part to be updated, a jumping instruction for jumping to said patch area for running the new code in said patch area;

b) overwriting some part of the program part to be updated with the new update code, and at the end of the part, allocating a jumping instruction for jumping to said patch area for running the new code in said patch area;

c) overwriting the program part to be updated with the new update code.

25. The method of claim 24, wherein said software patch is encrypted and has an encryption key generation function, which is placed in a predetermined safe place for safekeeping.

26. A method of updating an embedded software operative in a digital device, comprising:

receiving a software patch by said digital device through a communication link;

designating a first Flash block in said Flash memory;

designating a second Flash block (“Update Buffer Block”) in a Flash memory of said digital device;

copying good code that does not need to be updated from said first Flash block to a first predetermined location of said Update Buffer Block;

writing said software patch (“Program Update Code”) to a second predetermined location of said Update Buffer Block;

erasing said first Flash block;

copying said entire Update Buffer Block to said first Flash block, wherein said first Flash block is now updated.

27. A method of updating an embedded software operative in a digital device, comprising:

receiving a software patch by said digital device through a communication link;

designating a first Flash block in said Flash memory;

designating a second Flash block (“Update Buffer Block”) in said Flash memory of said digital device;

copying good code from a first Flash block to a first predetermined location of said Update Buffer Block;

erasing said first Flash block;

copying said entire Update Buffer Block to said first Flash block;

writing said software patch (“Program Update Code”) to a predetermined location of said first Flash block, wherein said first Flash block is now updated with the Program Update Code.

28. A method of updating an embedded software operative in a digital device, said method comprising:

providing a Flash memory in said digital device;

storing said embedded software as program code in said Flash memory (“Program Code Area”);

designating a patch area within said Flash memory;

receiving a software patch by said digital device through a communication link;

programming said software patch into said patch area as update program code;

inserting a jump instruction to a location in said Program Code Area, which is the beginning of a portion of said program code to be updated, said jump instruction causing execution of said program code to be jumped to said update program code.

29. A method of updating an embedded software operative in a digital device, said method comprising:

providing a Flash memory in said digital device;

storing said embedded software in said Flash memory (“Program Code Area”);

designating a patch area within said Flash memory;

receiving a software patch by said digital device through a communication link;

programming a first portion of said software patch as a first portion of updated program code into said Program Code Area;

programming at least a second portion of said software patch into said patch area as a second portion of updated program code;

inserting a jump instruction to a location in said Program Code Area, which is the end of said first portion of said updated program code, said jump instruction causing execution to jump to said second portion of said updated program code after execution of said first portion of said updated program code.

30. A method of updating an embedded software operative in a digital device, said method comprising:

providing a Flash memory in said digital device;

storing said embedded software in said Flash memory (“Program Code Area”);

designating a patch area within said Flash memory;

receiving a software patch by said digital device through a communication link;

programming said software patch as updated program code into said Program Code Area;

if said updated program code can be fully contained in said Program Code Area, inserting a jump instruction to the end of said updated program code, said jump instruction causing execution to jump to the remaining of said Program Code Area after execution of said updated program code.

31. A method of managing software error information in a software program operative in a digital device, said method comprising:

allocating an area in non-volatile memory for use by an error database in said digital device;

inserting a plurality of software traces into said software program, said traces monitoring operating condition of said software program and outputting error information when encountering software errors;

transmitting said error information to said error database;

processing said error information in said error database;

retrieving said error information from said error database for analysis.

32. The method of claim 31, wherein said retrieving said error information comprises transmitting said error information via SMS messages from said digital device.

33. The method of claim 31, further comprising:

collecting reset information for system resets in said digital device;

transmitting said reset information to said error database;

processing said reset information in said error database;

retrieving said reset information from said error database for analysis.

34. The method of claim 33, wherein said retrieving said reset information comprises transmitting said reset information via SMS messages from said digital device.

35. The method of claim 33, wherein said reset information comprises at least one of the following:

call stack information;

reset type information;

time stamp.