WO2007079110A2

WO2007079110A2 - Communication device programming failure recoverability scheme

Info

Publication number: WO2007079110A2
Application number: PCT/US2006/049350
Authority: WO
Inventors: David R. Hentrich; Jose J. Gonzalez
Original assignee: Motorola, Inc.
Priority date: 2005-12-28
Filing date: 2006-12-27
Publication date: 2007-07-12
Also published as: WO2007079110A3

Abstract

A method for programming a communication device, and specifically for recovering from a programming failure, is disclosed. In one embodiment, at least one restore point at a location in a program is identified. Once the programming process is executed, a register value is set to a first value and is incremented after successfully reaching a next restore point in the programming process. Further, the register value corresponds to a specific restore point location in the programming process. At least one piece of critical data from the communication device is backed up, a program is programmed into the communication device, and the critical data that was backed up is restored in the communication device. If a failure is detected when executing the programming process, the execution of the programming process is aborted and the programming process is re-executed, starting at the location of the restore point corresponding to the register value.

Description

COMMUNICATION DEVICE PROGRAMMING FAILURE RECOVERABILITY SCHEME

CROSS REFERENCE TO RELATED APPLICATIONS

[oooi] This application is related to applications attorney docket number IS02086TC, entitled "Programming an Embedded System in a Vehicle using Dynamic Provisioning of Program Control Operations," and attorney docket number ISO2089TC, entitled "Arrangement for Programming an Embedded System in a Vehicle," which are both concurrently filed herewith, and both of which are incorporated herein by reference.

FIELD OF THE INVENTION

[ooo2] This invention relates to methods for addressing the problem of a programming failure in a communication device, and specifically how to recover the device from such a problem so that programming may continue.

BACKGROUND

[ooo3] Wireless and wired communication devices, such as cellular telephones, vehicular telematics systems, etc., will from time to time require software to be downloaded to the communication device. Such software downloads may comprise software to be downloaded by the manufacture at a dealership, add-on software that the user has purchased to add additional functionality to the communication device, or may comprise updates for the software already present in the communication device.

[ooo4] Communication devices are_-susceptible to failures during programming. Wireless communication devices are especially susceptible to programming failures due to the nature of wireless communication; for example, transmission of the software from a wireless transmitter can be cut off due to out-of-range conditions or due to excess noise on the communication channel. Alternatively, the software may simply fail to properly install for one reason or another, even if programming is not achieved wirelessly. For example, a network access device (NAD), a type of embedded cellular telephone used in vehicular telematics units, may be programmed at a car dealership via a cable that is coupled to a vehicle's on-board diagnostic (OBD) connector (e.g., OBD-II) or any other suitable connector. In this example, a programming failure may result from an interruption of power or interruption of communication. For instance, the operator could trip over a cord or inadvertently press a button that is critical to the programming process.

£0005) Should the NAD fail to program properly, the result may be a complete and irretrievable failure of the communication device in the telematics unit. If the problem is sufficiently severe, the only way to fix it may be to replace the telematics unit in the vehicle. While such a solution may be feasible if the communication device is a mere hand-held cellular telephone, as applied to a telematics unit, such a solution is an expensive and logistically-difficult proposition.

[0006] In short, improved solutions are needed for the programming of communication devices, and specifically for recovering the communication device if a programming failure has occurred so that programming can reliably continue.

BRIEF DESCRIPTION OF THE DRAWINGS

[ooo7] Embodiments of the inventive aspects of this disclosure will be best understood with reference to the following detailed description, when read in conjunction with the accompanying drawings, in which:

[ooo8] Figure 1 illustrates an embodiment of a process for programming a communication device, which includes various restore points at which programming can recommence should there be a programming failure;

[0009] Figure 2 illustrates a system in which the process of Figure 1 can function, which includes a communication device and its associated programmer;

[ooio] Figure 3 illustrates the process of Figure 1 in flow chart form; and

[ooii] Figure 4 illustrates alternative embodiments of the process of Figure 1.

DETAILED DESCRIPTION

[ooi2] A method for programming a communication device, and specifically for recovering from a programming failure, is disclosed. The communication device can be used to communicate audio, data, video and/or a combination thereof. Programming failure is defined as an event that interrupts the process of programming a communication device. The interruption event can be caused by, but not limited to, power glitches/interruptions, communication corruption/interruptions, single event upsets (SEU), memory errors, device errors, and programming image validation failure (i.e., checksum failures). Essentially, the interrupt event can occur due to causes internal and causes external to the programming process.

[ϋoi3] In one embodiment, restore points are used to define the beginning of back-up, programming, and restore phases. During the back-up phase, certain critical data in the communication device is read and stored. Should a failure occur during this backup phase, the back-up phase is started again from its beginning until successfully completed. After the back-up phase is successfully completed, the restore point is set to the beginning of the programming phase, such that a programming failure during the programming phase cues the process to recover from the failure by beginning the programming phase again from its beginning. If the programming phase is successful, the restore point is updated to the beginning of the restore phase. After the programming phase is successfully completed, the critical data is re- written to the communication device during the restore phase, and if a failure occurs during the restore phase, the restore phase restarts at its beginning.

rooi4] It should be noted that the location and number of the restore points are application specific and design configurable. The examples described herein have the restore points located at the beginning of each phase. However, there can be more or less restore points in a given embodiment depending on system design. For example, in one embodiment there may be a restore point at the beginning of the back-up phase, a restore point at the beginning of the programming phase, but no restore point at the restore phase. In this case, a failure during the restore phase would cause the programming session to start again at the beginning of the programming phase.

[ooi5] One reason why incomplete programming can cause a catastrophic failure is that the communication device includes certain critical data necessary for the communication device to perform its basic functions, such as its telephone number, phasing data, security codes, and other similar data usually programmed at the manufacturer of the communication device. If such critical data is deleted at any point during programming, this critical data may be forever lost. On the other hand, if such critical data is left untouched in the communication device (i.e., not overwritten) during programming, the old program and the new program may not interact with the critical data in exactly the same way (i.e., the critical data may be left in a format that the new program does not understand). As a result, the new program may not operate correctly or reliably.

[0016] An embodiment of a process 10 for addressing such concerns is set forth in pictorial form in Figure 1. An exemplary system 70 in which the process may be used is shown in Figure 2, which is discussed first so that the process 10 may be better understood. Shown in Figure 2 is the communication device 30 to be programmed, and as mentioned earlier, may be wired or wireless, and may comprise, for example, but is not limited to, a cellular telephone or a vehicular telematics unit. Also shown is the programmer 20 used to write (i.e., program) the new application and/or data (collectively referred to herein as a "program" 25) into the communication device 30 via communication link 55, which may be wired or wireless. For example, the programmer 20 may comprise or be coupled to a wireless transmitter such as those used in satellites, cellular communications, or short-range implementations like 802.11 or Bluetooth. As an alternative example, it may comprise a computer at a car dealership.

[ooi7] Both the programmer 20 and the communication device 30 would normally contain a processing element (e.g., a microprocessor, a microcontroller, a programmable logic device (such as a programmable array logic (PAL), a programmable logic device (PLD), or a field programmable gate array (FPGA)), an application specific integrated circuit (ASIC), discrete control logic, or the like) for running logic functions and memory for storing programming code and programming data, but in one embodiment of the invention, an additional processing element 40 and an auxiliary memory 50 are included in the programmer 20, the communication device 30, or both. Thus, the processing element 40 executes the disclosed process 10, which can be run from either the programmer 20 or the communication device 30. The auxiliary memory 50 comprises the code for the disclosed process 10, as well as provides additional memory for backing up and/or logging certain data during the process, as will be described in more detail with respect to Figures 1 and 3. Of course, the processing element 40 and the auxiliary memory 50 need not be discrete and specifically dedicated to use with the disclosed process 10, and instead, the memory 50 may be merged with the microcontroller and memory already resident in either device.

fooiβ] Referring now to Figure 1, shown are the various steps in the programming process 10, which proceed from left to right. Figure 3 also illustrates the programming process 10 in flow chart form, and is simultaneously discussed with Figure 1. As will be seen, one important aspect of the disclosed invention is the establishing of various restore points during the programming process. These restore points provide a position (or alternatively referred to as "location") in the programming process from where programming should be reinitiated should the programming process fail prior to completion. As a result, in a first step in the process, a restore point register 51 (Fig. 2) portion of the auxiliary memory 50 is consulted to see if programming had been attempted, and failed. If the programming process had been attempted and failed, the restore point register 51 contains a logged restore point, and the programming process is directed to resume at the position referenced in the restore point (Fig. 3). If programming had not been attempted and/or had not failed, the restore point is set to '0' in the restore point register 51 (i.e., RP=O). In a commercial implementation, the actual contents of the restore point register 51 are application specific, but will refer to a location in the programming process. In the above example, RP=O refers to the beginning of the back-up phase, as will be discussed further below.

[ooi9] There is a plurality of ways to implement a restore point register 51. In one embodiment, the restore point register 51 can be implemented as a piece (or pieces) of memory whose contents symbolically refer to a location in the programming process. In another embodiment, the restore point register 51 can be implemented as a piece (or pieces) of memory whose contents point to a physical location that is being programmed, or points to a piece of executable code associated with the programming position. In yet another embodiment, the restore point register 51 may not be directly implemented, but indirectly implemented based on the state (context) of the backed- up data in memories 50 and/or memories 52; the programming data in main memory 35; and/or the restored data in memory 35. In other words, the actual restore point can be inferred by looking at the contents, state, and/or configuration of the memories in the programmer 20 and/or the communication device 30. In essence, the restore point is logged contextually by the programming process 10, rather than centrally logged by the programming process 10. In the following paragraphs, the restore point register 51 will be referred to as a specific memory location that is written explicitly with the programming position as a counter value that is incremented as it is updated. This is done to ease the discussion of the embodiment of Figure 1 and is not intended to limit the implementation of the restore point register 51 as an explicitly written position.

10020J At this point, and assuming that the restore point register 51 reads RP=O, the first phase of programming can begin. This first phase is referred to as the back-up phase, and in the back-up phase, critical data that is necessary for basic functionality of the communication device 30 is read from the communication device 30 and stored in a back-up memory 52 (Fig. 2) portion of the auxiliary memory 50. As noted earlier, such critical data can comprise, but is not limited to, the telephone number of the communication device, phasing data, security codes, and other similar data usually programmed at the manufacturer of the communication device 30. Ultimately, what data is considered "critical" and worthy of backing-up is application specific and is a matter of particular engineering judgment; hence, the examples of critical data provided are merely exemplary.

[002i] As shown in Figure 3, as each piece of critical data is read and stored (i.e. backed up) in the back-up memory 52, it is preferably verified, for example, using checksum or other error detection techniques. Ultimately, each piece of critical data can be verified in any number of different ways, and hence such ways are not particularly important to the invention. If verification of a particular piece of critical data is correct, then a next piece of critical data is read, backed-up, etc. If a particular piece of data cannot be verified, this indicates an error in the process 10. At this point, and as shown in Figure 3, the programming process 10 is aborted, and is reinitiated at the position last recorded in the restore point register 51. As noted earlier, initiating (or reinitiating) of programming first involves checking the position contained in the restore point register 51. In this example, it is noted that the restore point had last been set to the beginning of the back-up phase (RP=O). Accordingly, the programming process 10 once again commences starting at beginning of the backup phase (RP=O). This means in one embodiment that all critical data are once again read and backed up, although in more sophisticated embodiments, perhaps the programming process 10 can commence by reading and backing up only the particular pieces of critical data that earlier failed to verify by placing a restore points at each critical piece of data. In any event, for reliability and simplicity of design, this example returns to the beginning of the back-up phase and re-reads and re-backs up all the pieces of critical data.

[0022] Assuming that all the pieces of critical data have been read, backed up, and verified, the process can now determine that the entirety of the back-up phase has been successfully and reliably completed. Accordingly, the programming process 10 updates the restore point to the beginning of the programming phase (i.e., RP=I) in the restore point register 51, and the programming process 10 proceeds to the programming phase of the programming process 10. In case of future failure during the execution of the programming phase of the programming process 10, this new restore point setting (RP=I) indicates that the programming process 10 has successfully completed the back-up phase, and programming should recommence at the beginning of the programming phase.

[0023] During the programming phase, the communication device 30 is programmed by the programmer 20 with various sub-modules of programming data, i.e., with program 25 (Fig. 2). For example, if the communication device 30 is a telematics unit, the programming phase might include various sub-modules, such as a program boot, device configuration data, and the primary device software. It should be appreciated by a skilled person in the art that the programming phase, as with any other phase described herein, could include more, less, or different sub-modules than those mentioned above. [0024] The programming phase is somewhat similar to the back-up phase, as Figure 3 makes clear. Thus, as each sub-module of the programming phase is written into the communication device 30, it is verified through any suitable mechanism. When a given sub-module is verified, the next sub-module is written into the communication device, etc. If a given sub-module fails during programming (i.e., the verification process detects a failure, power is interrupted during programming, etc.), the programming phase is aborted and programming process 10 is started again at the last restore point position recorded in the register 51. In this example, since the restore point position in the restore point register 51 was earlier set to 'RP=I,' the programming process 10 commences at the beginning of the programming phase. As with the back-up phase, restarting at the programming phase can alternatively comprise restarting at the position prior to the programming of the particular programming phase sub-module that earlier would not verify or was interrupted.

[0025] Note that writing of each of the sub-modules of programming data during the programming phase can include (intentionally or unintentionally) clearing the previously stored program and/or data in the communication device 30, and/or overwriting the previously stored program and/or data in the communication device. Because critical data has earlier been safely backed up and verified, such clearing/overwriting of the previously stored program can safely include clearing/overwriting of the critical data. As will be seen below, the critical data is restored in the next phase.

[0026] Referring again to Figures 1 and 3, once the programming phase has successfully completed, the restore point is again updated to the beginning of the restore phase (i.e., RP=2) in the restore point register 51, and the programming process 10 proceeds to the restore phase. In this example, in case of a failure during the restore phase of the programming process 10, this new restore point setting (RP=2) indicates that the programming process 10 has successfully completed the back-up phase and the programming phase, and the programming process 10 should recommence at the beginning of the restore phase. [0027] During the restore phase, the critical data originally read and verified during the back-up phase is re-written back to the communication device 30. Note that this can be beneficial to ensure that the newly-written program will reliably interact with the critical data, because both are written under the control of the programmer 20. In any event, the restore phase is also similar to the back-up phase. Should failure occur or be verified during the writing of a critical piece of data, the programming process 10 is aborted and reinitiated at the restore point position last recorded in the restore register 51, which in this example is the restore phase (RP=2). As such, programming re-commences at that position contained in the restore register 51, i.e., at the beginning of the restore phase.

[0028] Note that the disclosed programming process 10 achieves several significant benefits. First, critical data is preserved as a first step, and before any permanent changes are made to the programming in the communication device which might cause that data to be lost or corrupted. Second, because the critical data is overwritten and then rewritten into the communication device 30 under control of the programmer 20, it can be better ensured that the critical data will interact appropriately with the new program which the programmer 20 is installing. Third, because no phase is begun until the last phase is verified as successfully completed, programming is rendered more reliable. Fourth, through the logging of the restore points, failures in programming are recovered more efficiently, such that earlier phases that are successfully completed are not repeated.

[0029] Although disclosed as having restore points at the beginning of the back-up, programming, and restore phases, it should be noted that in that additional restore points can be used in other embodiments. For example, and as alluded to earlier, restore points can be used after processing (i.e., backing up, programming, or restoring) each sub-module or piece of data. By using a plurality of restore point during each phase, it becomes unnecessary to start at the beginning of each phase when recovering from a programming failure. While this can increase the efficiency of the programming failure recovery, it will add to the complexity of programming. [0030) Moreover, in the disclosed preferred embodiment, the back-up, programming, and restore phases are depicted as being continuous. However, each of the phases can be broken into sub-modules and performed in different orders with respect to sub- modules of the other phases. For example, as shown in the top row of Figure 4, the programming and restore phases can be interleaved, with certain sub-modules being restored before all programming sub-modules have been written into the communication device. Similarly, as shown in the bottom row of Figure 4, the backup phase can also be broken into sub-modules, although care must be taken to not write programming phase sub-modules that would erase back-up phase sub-modules in the communication device 30 before they are backed up.

£0031] It should be understood that the inventive concepts disclosed herein are capable of many modifications. To the extent such modifications fall within the scope of the appended claims and their equivalents, they are intended to be covered by this patent.

Claims

WHAT IS CLAIMED IS:

1. A method of programming a communication device, comprising: identifying at least one restore point at a location in a program process; executing the programming process; setting a register value to a first value upon execution of the programming process, wherein the register value is incremented after successfully reaching a next restore point in the programming process, and wherein the register value corresponds to a specific restore point location in the programming process; backing up at least one piece of critical data from the communication device; programming a program into the communication device; restoring the critical data that was backed up in the communication device; and if a failure is detected when executing the programming process, aborting the execution of the programming process and re-executing the programming process starting at the location of the restore point corresponding to the register value.

2. The method of claim 1, wherein the critical data comprises at least one of: a telephone number for the communication device, a unique identifier for the communication device, phasing data for the communication device, device tuning information for the communication device, or a security code for the communication device.

3. The method of claim 1, wherein the critical data that is backed up resides in a programmer coupled to the communication device.

4. The method of claim 1, wherein the critical data that is backed up resides in the communication device.

5. The method of claim 3, wherein the programmer is coupled to the communication device via one of a wireless link or a wired link.

6. The method of claim 3, wherein the programmer is coupled to the communications device via an on-board diagnostic connector.

7. The method of claim 1, wherein the communication device comprises a vehicular telematics unit.

8. The method of claim 1, wherein programming the application to the communication device comprises overwriting a previously stored application in the communication device.

9. The method of claim 8, wherein overwriting the previous application comprises overwriting at least a portion of the critical data that was backed up.

10. A method of programming a communication device, comprising in order:

(a) backing up at least one piece of critical data from the communication device;

(b) verifying the step of backing up, and if verification fails, repeating step (a);

(c) programming at least a portion of a program to the communication device;

(d) verifying the step of programming, and if verification fails, repeating step (c); and

(e) restoring the critical data that was backed up to the communication device.

11. The method of claim 10, further comprising verifying the step of restoring, and if verification fails, repeating step (e).

12. The method of claim 10, wherein the critical data comprises at least one of: a telephone number for the communication device, a unique identifier for the communication device, phasing data for the communication device, device tuning information for the communication device, or a security code for the communication device.

13. The method of claim 10, wherein the critical data that is backed up resides in a programmer coupled to the communication device.

14. The method of claim 13, wherein the programmer is coupled to the communication device via one of a wireless link or a wired link.

15. The method of claim 13, wherein the programmer is coupled to the communications device via an on-board diagnostic connector.

16. The method of claim 10, wherein the communication device comprises a vehicular telematics unit.

17. The method of claim 10, wherein programming the program to the communication device comprises overwriting a previously stored program in the communication device.

18. A method of recovering from failure of programming a communication device, the programming of the communication device occurring in a plurality of successive phases, comprising: assessing which of the plurality of phases the programming failure occurred in by assessing a restore point set during programming,; and reinitiating programming of the communication device starting at the beginning of the phase in which the programming failure occurred.

19. The method of claim 18, wherein the communication device comprises a vehicular telematics unit.