CN106990982B - Program updating method and device - Google Patents
Program updating method and device Download PDFInfo
- Publication number
- CN106990982B CN106990982B CN201710166980.6A CN201710166980A CN106990982B CN 106990982 B CN106990982 B CN 106990982B CN 201710166980 A CN201710166980 A CN 201710166980A CN 106990982 B CN106990982 B CN 106990982B
- Authority
- CN
- China
- Prior art keywords
- program
- updated
- bootstrap
- updating
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Abstract
The invention provides a program updating method and a device, wherein the method comprises the following steps: after the target program fails to be updated, the first bootstrap program is restarted, wherein the first bootstrap program is solidified in the memory; the target program is an application program or a second bootstrap program, the first bootstrap program is executed, and the target program is updated again according to the updating logic in the first bootstrap program. The first bootstrap program including the updating logic is solidified into the memory by separating the bootstrap program into two parts, and when the target program fails to be updated, the first bootstrap program can be relocated to the position of the first bootstrap program to start the first bootstrap program to guide and execute the updating logic when the target program returns to restart. Especially for the update of the BootLoader, the second bootstrap program can be continuously updated after the update fails, so that the problem that the ECU cannot be normally used due to the fact that the boot loader cannot be started after the update fails in the prior art can be solved.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for updating a program.
Background
An Electronic Control Unit (ECU) is also called a "traveling computer" or a "vehicle-mounted computer". Currently, the mainstream ECU supports online upgrade in the following two ways:
the first method comprises the following steps: the boot loader (BootLoader) responsible for upgrading the Application is merged with the Application (Application) and updates are upgraded at the same time. Once interruption occurs in the upgrading process, the system cannot be started any more, and under the condition, great risk and cost are brought to the ECU upgrading of the automobile.
And the second method comprises the following steps: the BootLoader and the application program are separated and respectively stored in independent spaces of a Flash memory (Flash), and the ECU is powered on and then the BootLoader is advanced to judge whether the application program is effective or not, so that whether the application program stays in a boot (boot) state or enters the application program is determined. Because the BootLoader and the application program are in an independent Flash area, the BootLoader is not affected after the update of the application program fails, and the application program can be continuously updated again through the BootLoader. However, when BootLoader also needs to be updated, if BootLoader fails to update, the whole system cannot be started.
Disclosure of Invention
Therefore, the invention provides a program updating method and device, which are used for solving the problem that a system cannot be started after the BootLoader fails to update in the existing program updating mode.
A second object of the present invention is to provide a program updating apparatus.
To achieve the above object, an embodiment of a first aspect of the present invention provides a program updating method, including:
returning to restart the first bootstrap program after the target program fails to be updated; wherein the first boot program is solidified in a memory; the target program is an application program or a second bootstrap program;
executing the first bootstrap program;
and according to the updating logic in the first bootstrap program, updating the target program again.
According to the program updating method, the bootstrap program is separated into two parts, the first bootstrap program comprising the updating logic is solidified into the memory, and after the target program fails to be updated, the first bootstrap program can be relocated to the position of the first bootstrap program when the target program returns to restart, so that the first bootstrap program is started to guide and execute the updating logic. Especially for the update of the BootLoader, the second bootstrap program can be continuously updated after the update fails, so that the problem that the ECU cannot be normally used due to the fact that the boot loader cannot be started after the update fails in the prior art can be solved.
To achieve the above object, a second embodiment of the present invention provides a program updating apparatus, including:
the system comprises a memory, a processor and a first bootstrap program stored on the memory and capable of running on the processor, wherein the processor executes the program updating method according to the embodiment of the first aspect of the invention.
The program updating device of the embodiment of the invention solidifies the first bootstrap program comprising the updating logic into the memory by separating the bootstrap program into two parts, and can be relocated to the position of the first bootstrap program when returning to restart after the target program fails to be updated, so as to start the first bootstrap program to guide and execute the updating logic. Especially for the update of the BootLoader, the second bootstrap program can be continuously updated after the update fails, so that the problem that the ECU cannot be normally used due to the fact that the boot loader cannot be started after the update fails in the prior art can be solved.
Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.
Drawings
The foregoing and/or additional aspects and advantages of the present invention will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:
fig. 1 is a flowchart illustrating a program updating method according to an embodiment of the present invention;
fig. 2 is a flowchart illustrating another program updating method according to an embodiment of the present invention;
fig. 3 is a flowchart illustrating another program updating method according to an embodiment of the present invention;
FIG. 4 is a diagram illustrating a memory partition according to an embodiment of the present invention;
fig. 5 is a schematic structural diagram of a program updating apparatus according to an embodiment of the present invention.
Detailed Description
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are illustrative and intended to be illustrative of the invention and are not to be construed as limiting the invention.
A program updating method and apparatus according to an embodiment of the present invention are described below with reference to the drawings.
Fig. 1 is a flowchart illustrating a program updating method according to an embodiment of the present invention. As shown in fig. 1, the program updating method includes the steps of:
s101, returning to restart the first bootstrap program after the last target program fails to be updated; wherein the first boot program is solidified in the memory; the target program is an application program or a second bootstrap program.
In this embodiment, in order to enable the target program to be updated continuously after the target program fails to be updated, a boot loader (BootLoader) for updating the application program is divided into two parts, and one part is update logic for updating the target program. The other part is a code block for updating the application program, and in this embodiment, the part is used as the second boot program. The updating of the target program can be finally completed based on the first bootstrap program and the second bootstrap program.
In this embodiment, in order to avoid the risk that the system cannot be started after the BootLoader fails to update, the first boot program is solidified into the memory. The memory may be a Flash memory. The first bootstrap program comprises update logic for updating the target program, and when the target program is updated, the first bootstrap program can guide the system to update according to the update program. And because the first bootstrap program is solidified in the memory, the first bootstrap program is not updated and upgraded when the system is updated and upgraded.
In practical applications, the system needs to be bootable from the boot location when booting, and in this embodiment, the first boot program is fixed to the boot location in the memory. Specifically, the memory space of the memory is divided in advance, one of the memory spaces may be set as a start position for starting the system, and the first boot program is solidified in the first memory space corresponding to the start position.
The target program may be an application program or a second bootstrap program separated from BootLoader. After the target program fails to update, the system can be restarted to try to update the target program again. In this embodiment, since the first boot program is fixed in the memory, when the first boot program returns to the restart, the first boot program can be relocated to the position of the first boot program to start the first boot program. Particularly, when the target program is the second boot program, the prior art fails to split the boot program into two parts, and thus the system may not be restarted after the boot program fails to be updated. In this embodiment, the update logic in the boot program is separately and fixedly stored in the memory, and even after another part of the update fails, the second boot program can be updated again according to the update logic by booting when the system is restarted.
And S102, executing a first bootstrap program.
And S103, updating the target program again according to the updating logic in the first bootstrap program.
After the first boot program is restarted, the first boot program may be executed. Further, after the first boot program is executed, the target program may be updated again according to the update logic included in the first boot program.
In the program updating method provided by this embodiment, after the target program fails to be updated, the first boot program is restarted, where the first boot program is solidified in the memory; the target program is an application program or a second bootstrap program, the first bootstrap program is executed, and the target program is updated again according to the updating logic in the first bootstrap program. In this embodiment, the boot program is divided into two parts, the first boot program including the update logic is solidified into the memory, and after the target program fails to be updated, the target program can be relocated to the position of the first boot program when the target program returns to restart, and the first boot program is started to boot and execute the update logic. Especially for the update of the BootLoader, the second bootstrap program can be continuously updated after the update fails, so that the problem that the ECU cannot be normally used due to the fact that the boot loader cannot be started after the update fails in the prior art can be solved.
Fig. 2 is a flowchart illustrating another program updating method according to an embodiment of the present invention. As shown in fig. 2, the program updating method includes the steps of:
s201, after the target program fails to be updated, returning to restart the first bootstrap program; wherein the first boot program is solidified in the memory.
For the description of S201, reference may be made to the related description in S101 in the above embodiment, and details are not repeated here.
And S202, executing a first bootstrap program.
And executing the first bootstrap program, wherein the first bootstrap program comprises the updating logic, and the application program can be updated again according to the updating logic comprised by the first bootstrap program. In this embodiment, the set update logic is that the application program and the second boot program update each other. For example, when the target program is an application program, the update of the application program is completed by the second boot program, and when the target program is the second boot program, the update of the second boot program is completed by the application program.
In practical applications, the update of the application program needs to be completed in the second boot program valid state, and the update of the second boot program needs to be completed in the application program valid state. In this embodiment, the update logic is formed according to at least one of the application program and the second boot program being in an active state.
In this embodiment, if the target program is an application program, when the application program fails to be updated, returns to the first boot program, and then boots according to the update logic, it may be determined that the second boot program is in an effective state, so that the application program may be continuously updated. When the application program is updated successfully, the application program can be in an effective state. When the second bootstrap program needs to be updated, the second bootstrap program can be updated through the application program.
Similarly, if the target program is the second bootstrap program, when the second bootstrap program fails to update and returns to the first bootstrap program and then is booted according to the update logic, it can be determined that the application program is in the valid state, so that the application program can be continuously updated. When the second boot program is updated successfully, the second boot program can be in an effective state. When the application program needs to be updated, the application program can be updated through the second bootstrap program.
S203, the first bootstrap program judges whether the application program needs to be updated.
Specifically, when the application program or the second boot program needs to be updated, the upper computer may send an indication signal indicating that the application program needs to be updated to the system through the bus, and the first boot program may determine whether the application program needs to be updated according to the indication signal. If it is determined that the application needs to be updated, S204 is performed.
And S204, if the application program needs to be updated, and when the second bootstrap program is effective, the application program is updated.
Because the update of the application program can be completed only when the second bootstrap program is valid, after the application program needs to be updated is judged, whether the second bootstrap program is valid needs to be judged, and when the second bootstrap program is determined to be valid, the application program can enter the second bootstrap program, and the application program is updated through the second bootstrap program.
In this embodiment, whether the second boot program is valid may be determined according to the valid flag of the second boot program. A preset value, for example, a value "1" is preset for the valid flag bit, and when the value of the valid flag bit is "1", it can be determined that the second boot program is in a valid state.
And S205, if the application program is not required to be updated, updating the second bootstrap program when the application program is effective and the second bootstrap program is required to be updated.
Specifically, when the first bootstrap program judges that the application program does not need to be updated according to the sent indication signal, whether the application program is valid can be continuously judged, and if the application program is valid, the application program is entered. Further, when the second boot program needs to be updated, the second boot program can be updated. If the second boot program does not require an update, the application program may be executed.
In this embodiment, whether the application program is valid may be determined according to the valid flag bit of the application program. A preset value, for example, a value "1" is preset for the valid flag bit, and when the value of the valid flag bit is "1", it can be determined that the application program is in a valid state.
In this embodiment, the update logic that the application program and the second boot program update each other is written into the first boot program in advance, then the first boot program is solidified into the memory, and after the target program fails to be updated, the target program can be relocated to the position of the first boot program when being returned to restart, and the first boot program is started to boot and execute the update logic. Especially for the update of the BootLoader, the second bootstrap program can be continuously updated after the update fails, so that the problem that the ECU cannot be normally used due to the fact that the boot loader cannot be started after the update fails in the prior art can be solved.
Fig. 3 is a flowchart illustrating another program updating method according to an embodiment of the present invention. The target application may be an application or may be a second boot program. Both are updated according to the flow shown in fig. 3. The program updating method provided by the embodiment can be applied to various control systems such as an ECU, an MUC and the like. As shown in fig. 3, the program updating method includes the steps of:
s301, the system starts a first bootstrap program.
In this embodiment, the first boot program is pre-fixed to the boot position of the memory. When the target program fails to be updated, the system can return to the starting position of the memory to restart the first bootstrap program. The first bootstrap program can renew the target program according to the preset updating logic. The target application may be an application or may be a second boot program. Both updates follow the flow shown in fig. 3.
In this embodiment, the set update logic is that the application program and the second boot program update each other. For example, when the target program is an application program, the update of the application program is completed by the second boot program, and when the target program is the second boot program, the update of the second boot program is completed by the application program. In practical applications, the update of the application program needs to be completed in the second boot program valid state, and the update of the second boot program needs to be completed in the application program valid state. In this embodiment, the update logic is formed according to at least one of the application program and the second boot program being in an active state.
In this embodiment, the storage space of the memory is divided in advance, and specifically, the first boot program is solidified into the first storage space corresponding to the start position. Further, one of the remaining memory spaces is selected as a second memory space for storing configuration parameters of the memory, wherein the configuration parameters include allocation information of the memory, i.e. address information of each memory space, stored contents, size of the memory space, and the like. Further, the configuration parameters further include valid identification bits of the target program, i.e., valid flag bits of the application program and valid flag bits of the second boot program. The configuration parameters may further include information such as a version number and update time of the target program, that is, a version number and update time of the application program, and a version number and update time of the second boot program.
In the present embodiment, the second boot program and the application program are stored in the remaining memory space other than the first memory space and the second memory space. Further, when the application program runs, key parameter values related to the system are also needed, and the key parameter values can be separately stored in another storage space. When the application program is executed, the system can read calibration data from the storage space in which the calibration data is stored.
For example, the memory may be divided into 5 memory spaces, and 5 memory space distributions may store: a first boot program, configuration parameters, a second boot program, an application program, and calibration data for the application program. The calibration data is a key parameter related to the system when the application program is executed, as shown in fig. 4. Fig. 4 is a schematic diagram illustrating a memory space division of a memory according to an embodiment of the present invention.
S302, the system judges whether the application program needs to be updated.
In practical applications, when the program is first burned in the system, the first boot program, the configuration parameters, and the second boot program must be burned, and further, in order to implement the application program used in the system, the application program may also be burned into the memory together. The program can be burned according to the memory division mode. And after the burning is finished, the system can be upgraded on line.
When the system runs the burned program for the first time, the system directly enters a first bootstrap program after being started, and then the first bootstrap program judges whether the application program needs to be updated or not. Specifically, the upper computer can send a first signal to the system through the bus, wherein the first signal is used for indicating that the application program needs to be updated, and the system judges whether the application program needs to be updated or not according to the first signal sent by the upper computer based on the first bootstrap program. If an update is required S303 is performed. If no update is required, S304 is performed.
Generally, after an application program is burned in a system, when a first boot program is executed for the first time, the system often does not receive a first signal sent by an upper computer through a bus, that is, the application program does not need to be updated.
S303, the system judges whether the second bootstrap program is effective according to the effective zone bit of the second bootstrap program.
Specifically, a valid flag bit of the second boot program may be read from the second storage space where the configuration parameter is located, and if the current target program to be updated is an application program, and the valid flag of the second boot program is a preset value, it may be determined that the second boot program is in a valid state, and then S305 is executed. If the valid flag of the second boot program is not the preset value, it may be determined that the second boot program is in a failed state, which indicates that the second boot program needs to be updated, and S306 needs to be executed to continue updating the second boot program through the application program.
In this embodiment, for updating a version of the target program, the preset value of the valid flag of the target program needs to be cleared before the version is updated for the first time, and after the version of the target program fails to be updated for the next time, it is determined that the target program is in a failure state according to the valid flag of the target program.
That is, when the target program is the second boot program, if the last update of the second boot program fails, the preset value of the valid flag of the second boot program is cleared during the last update, and according to the cleared valid flag, it can be determined that the second boot program is in an invalid state. If the second boot program is in an invalid state, S306 is performed.
S305, the system enters a second bootstrap program.
And S307, updating the application program by the system.
The second bootstrap program is used for updating the application program, and when the system enters the second bootstrap program, the system can update the application program by using the code block in the second bootstrap program. When the application update is completed, the system can be reset.
S304, the system judges whether the application program is effective according to the effective zone bit of the application program.
When the program does not need to be updated, whether the application program is valid can be continuously judged according to the valid flag bit of the application program. Specifically, the system stores configuration parameters in a second storage space of the memory, wherein the configuration parameters include valid flags of the application program and the second boot program. The system can read the valid flag bit of the application program from the second storage space. The system can judge whether the application program is effective according to the value of the effective zone bit. In general, if the application does not need to be updated, the valid flag of the application in the configuration parameter is a preset value, that is, the application is valid, then S306 is executed.
When the target program is the application program, if the application program is failed to be updated last time, the preset value of the valid flag of the application program is cleared during the last updating, and the application program can be determined to be in an invalid state according to the cleared valid flag. In general, if the application is invalid, which means that the application needs to be updated, S307 needs to be executed.
In practical applications, when the application fails to be updated during the last update and the system is not connected to the upper computer, although the application needs to be updated, the indication signal sent by the upper computer cannot be received, in this case, since the indication signal of the update is not received, the step S303 determines that the application does not need to be updated, but actually, the application still needs to be updated because the application fails to be updated last time. Moreover, each time the version of the application program is updated, the preset value of the valid flag bit of the application program needs to be cleared before the version is updated for the first time. In the updating process, if the application fails to be updated, the application may be determined to be invalid according to the valid flag of the application when the application is updated again next time, and in this case, S307 needs to be executed.
S306, the system enters an application program.
S308, the system judges whether the second bootstrap program needs to be updated.
When the second boot program needs to be updated, the upper computer can send a second signal for indicating that the second boot program needs to be updated to the system through the bus. Further, if the second signal is received, the system may determine that the second boot program needs to be updated, and then S310 is performed. If the second signal is not received, the system may determine that no update to the second boot program is needed, and proceed to S312.
And S310, the system updates the second bootstrap program.
When the system judges that the second bootstrap program needs to be updated according to the second signal, the system can update the second bootstrap program, and specifically, the update content of the second bootstrap program can be received from the upper computer through the bus. After the second bootstrap program is updated, the system is reset.
S312, the system executes the application program.
When the application program judges that the second bootstrap program does not need to be updated according to the second signal, the system directly executes the application program and normally uses the service or the function provided by the application program. After the system executes the application program, the system can power down.
Further, after the target program is updated, the system may adjust the occupied storage space of the target program according to the actual size of the target program. Specifically, the system may adjust the size and/or location of the storage space occupied by the target program according to the actual size of the target program. In this embodiment, the target program is stored in a storage space other than the first storage space and the second storage space. The system can flexibly adjust the residual storage space between the first storage space and the second storage space in the storage by the updated actual size of the target program. For example, the storage location of the target program may be adjusted, or the size of the space originally occupied by the target program may be adjusted.
In practical applications, the configuration parameters in the memory are generally changed after the target program is successfully updated, and then the system needs to update the configuration parameters in the second storage space in the memory after the target program is updated. For example, when the target program is updated successfully, the valid flag of the target program needs to be restored to a preset value, so that the updated target program can be used by the system. For another example, the updated version number and the update time of the target program may be updated to the configuration parameters.
For another example, after the target program is updated, the position or size of the storage space may need to be adjusted due to the problem of the actual size, and the system needs to update the position and the occupied space of the updated target program into the allocation information of the memory in the configuration parameter after the adjustment is completed.
In order to understand the program updating process provided in the embodiment of the present invention, the target program is taken as the second boot program for explanation. When the first bootstrap program is executed for the first time, the second bootstrap program and the application program are in an effective state and do not need to be updated. When it is detected that the second boot program needs to be updated, the valid flag of the second boot program needs to be cleared. At this time, the application program is in an effective state, so that after the second bootstrap program fails to be updated, the system returns to restart the first bootstrap program, and when the application program does not need to be updated, the step of judging whether the application program is effective is carried out.
And when the application program needs to be updated, entering a step of judging the effectiveness of the second bootstrap program, wherein the system can only jump to the application program because the last update of the second bootstrap program is unsuccessful, and updating the second bootstrap program through the application program until the second bootstrap program is updated successfully, so that the application program can not be updated. And when the second bootstrap program is updated successfully, the effective zone bit of the second bootstrap program is restored to the preset value.
Since the second boot program is valid at this time, the second boot program can be entered to update the application program. Or when the application program is not updated successfully in the last updating process and the system is not connected with the upper computer, the system does not receive a signal which is sent by the upper computer and indicates that the application program is updated, the system enters a step of judging whether the application program is valid or not, the system can enter a second bootstrap program because the application program is invalid, the application program is updated through the second bootstrap program, and the valid flag bit of the application program cannot be restored to the preset value until the application program is updated.
The update logic provided in this embodiment may ensure that at least one of the application program and the second boot program is in an active state, and when one of the object programs is in the active state, because the other is in the active state, and the first boot program is fixed in the memory, after the update of the object program fails, the first boot program may be returned, and the object program may be updated again until the update of the object program is completed, and when the update is completed, the object program is active. According to the embodiment, mutual updating and upgrading of the application program and the second bootstrap program can be realized, especially for updating of the BootLoader, the second bootstrap program can be continuously updated after updating fails, and therefore the problem that in the prior art, after updating of the BootLoader fails, the BootLoader cannot be started, and accordingly the ECU cannot be normally used is solved.
Fig. 5 is a schematic structural diagram of a program updating apparatus according to an embodiment of the present invention. As shown in fig. 5, the program updating apparatus includes: a processor 11 and a memory 12.
The processor 11 is used for returning to restart the first bootstrap program after the target program fails to be updated; wherein the first boot program is solidified in the memory 12; the target program is an application program or a second bootstrap program, the first bootstrap program is executed, and the target program is updated again according to the updating logic in the first bootstrap program.
Further, the processor 11 is specifically configured to update the target program again based on the update logic that updates the application program and the second boot program with each other.
The processor 11 is specifically configured to form the update logic according to a valid state of at least one of the application program and the second boot program.
The processor 11 is specifically configured to determine whether the application program needs to be updated by the first boot program, and update the application program if the application program needs to be updated and when the second boot program is valid.
The processor 11 is specifically configured to read the valid flag of the second boot program from the memory 12, and determine whether the second boot program is valid according to the valid flag of the second boot program.
The processor 11 is specifically configured to update the second boot program when the application program is valid and the second boot program needs to be updated, if the application program does not need to be updated.
The processor 11 is specifically configured to read the valid flag bit of the application program from the memory 12, and determine whether the application program is valid according to the valid flag bit of the application program.
The processor 11 is specifically configured to, for updating of one version of the target program, clear a preset value of a valid flag of the target program before a first update of the version is performed, and determine that the target program is in a failure state according to the valid flag of the target program when a next update of the version of the target program fails.
The processor 11 is specifically configured to divide a storage area of the memory 12 in advance to form a plurality of storage spaces, and solidify the first boot program in a first storage space; the first storage space is a starting position for starting a system, and a second storage space is selected from the rest storage spaces, wherein the second storage space is used for storing configuration parameters; the configuration parameters include allocation information of the memory 12 and valid flag bits of the target program, and the target program is stored in a storage space other than the first storage space and the second storage space.
The processor 11 is specifically configured to adjust, after the update is completed, a storage space occupied by the target program according to the actual size of the target program.
The processor 11 is specifically configured to update the configuration parameters stored in the second storage space after the target program is successfully updated.
The processor 11 is specifically configured to, when the target program is the application program and after the target program is successfully updated, update the calibration data stored in the memory 12, where the calibration data is a key parameter value related to a system when the application program is executed.
The processor 11 and the memory 12 may be connected to each other via a bus and communicate with each other. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 5, but this is not intended to represent only one bus or type of bus.
The processor 11 may be a Central Processing Unit (CPU), or an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits configured to implement embodiments of the present invention.
In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.
Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "a plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing steps of a custom logic function or process, and alternate implementations are included within the scope of the preferred embodiment of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention.
The logic and/or steps represented in the flowcharts or otherwise described herein, e.g., an ordered listing of executable instructions that can be considered to implement logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
It should be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.
It will be understood by those skilled in the art that all or part of the steps carried by the method for implementing the above embodiments may be implemented by hardware related to instructions of a program, which may be stored in a computer readable storage medium, and when the program is executed, the program includes one or a combination of the steps of the method embodiments.
In addition, functional units in the embodiments of the present invention may be integrated into one processing module, or each unit may exist alone physically, or two or more units are integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. The integrated module, if implemented in the form of a software functional module and sold or used as a stand-alone product, may also be stored in a computer readable storage medium.
The storage medium mentioned above may be a read-only memory, a magnetic or optical disk, etc. Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention, and that variations, modifications, substitutions and alterations can be made to the above embodiments by those of ordinary skill in the art within the scope of the present invention.
Claims (11)
1. A program update method, comprising:
returning to restart the first bootstrap program after the target program fails to be updated; wherein the first boot program is solidified in a memory; the target program is an application program or a second bootstrap program;
executing the first bootstrap program;
according to the updating logic in the first bootstrap program, the target program is updated again;
the re-updating the target program according to the update logic in the first bootstrap program includes:
and updating the target program again based on the updating logic updated by the application program and the second bootstrap program, wherein at least one of the application program and the second bootstrap program is in a valid state to form the updating logic.
2. The method of claim 1, wherein said re-updating the target program in accordance with the update logic that the application and the second boot program update each other comprises:
determining, by the first bootstrap program, whether the application program needs to be updated;
updating the application if needed and while the second boot is active.
3. The method of claim 2, further comprising:
reading a valid flag bit of the second boot program from the memory;
and judging whether the second bootstrap program is valid or not according to the valid flag bit of the second bootstrap program.
4. The method of claim 2, further comprising:
if the application does not need to be updated, the second boot program is updated when the application is valid and the second boot program needs to be updated.
5. The method of claim 4, further comprising:
reading a valid flag bit of the application program from the memory;
and judging whether the application program is valid or not according to the valid flag bit of the application program.
6. The method of claim 2 or 3, further comprising:
for updating of one version of the target program, before the version is updated for the first time, clearing a preset value of a valid flag bit of the target program;
and after one updating of the version of the target program fails, determining that the target program is in a failure state according to the effective zone bit of the target program during the next updating.
7. The method according to any one of claims 1-4, further comprising:
dividing a storage area of the memory in advance to form a plurality of storage spaces;
solidifying the first boot program in a first storage space; the first storage space is a starting position for starting a system;
selecting a second storage space from the rest storage spaces, wherein the second storage space is used for storing configuration parameters; the configuration parameters comprise allocation information of the memory and a valid flag bit of the target program;
and storing the target program in a storage space except the first storage space and the second storage space.
8. The method of claim 7, further comprising:
and after the updating is finished, adjusting the occupied storage space of the target program according to the actual size of the target program.
9. The method of claim 7, further comprising:
and after the target program is updated successfully, updating the configuration parameters stored in the second storage space.
10. The method of claim 6, further comprising:
when the target program is the application program, after the target program is updated successfully, the calibration data stored in the memory is updated, wherein the calibration data is a key parameter value related to a system when the application program is executed.
11. A program update apparatus, comprising:
memory, a processor and a first boot program stored on the memory and executable on the processor, the processor performing the program update method of any of claims 1-10.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710166980.6A CN106990982B (en) | 2017-03-20 | 2017-03-20 | Program updating method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710166980.6A CN106990982B (en) | 2017-03-20 | 2017-03-20 | Program updating method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106990982A CN106990982A (en) | 2017-07-28 |
| CN106990982B true CN106990982B (en) | 2021-07-02 |
Family
ID=59412071
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710166980.6A Active CN106990982B (en) | 2017-03-20 | 2017-03-20 | Program updating method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106990982B (en) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE102017119068B4 (en) * | 2017-08-21 | 2020-12-10 | Infineon Technologies Ag | Update a store |
| DE102017119065B4 (en) * | 2017-08-21 | 2020-12-10 | Infineon Technologies Ag | Update a store |
| CN107608702A (en) * | 2017-10-25 | 2018-01-19 | 迈普通信技术股份有限公司 | Bootloader program modules update method and device |
| CN108055583B (en) * | 2017-12-28 | 2020-08-07 | 深圳市九洲电器有限公司 | Automatic recovery method and system for set top box |
| CN108920196A (en) * | 2018-06-28 | 2018-11-30 | 国机智骏（北京）汽车科技有限公司 | Entire car controller bootload upgrade method, device, entire car controller and vehicle |
| CN109992312B (en) * | 2019-03-26 | 2021-09-14 | 联想(北京)有限公司 | Starting method, device and system of electronic equipment |
| CN110096300B (en) * | 2019-04-08 | 2023-03-14 | 上海赛治信息技术有限公司 | FPGA program file backup management system, operation method and upgrading method |
| CN110134411A (en) * | 2019-05-20 | 2019-08-16 | 江苏华鹏智能仪表科技股份有限公司 | A kind of self-identifying method for burn-recording suitable for ammeter RN8318 chip |
| CN112015456A (en) * | 2019-05-31 | 2020-12-01 | 河南森源电动汽车有限公司 | BootLoader program updating method |
| CN110362327B (en) * | 2019-07-12 | 2023-05-16 | 北京经纬恒润科技股份有限公司 | Application program updating method, device and system |
| CN111443953B (en) * | 2020-03-24 | 2023-08-01 | 烟台艾睿光电科技有限公司 | Method, device and medium for starting infrared imaging system based on FPGA |
| WO2023141832A1 (en) * | 2022-01-26 | 2023-08-03 | 宁德时代新能源科技股份有限公司 | Program updating method and program updating apparatus |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1567195A (en) * | 2003-06-20 | 2005-01-19 | 华为技术有限公司 | Method for implementing hot-update of bootstrap program in flush bonding system |
| CN101895671A (en) * | 2010-07-21 | 2010-11-24 | 深圳创维数字技术股份有限公司 | Set top box Loader module updating method and set top box thereof |
| CN102486733A (en) * | 2010-12-03 | 2012-06-06 | 中兴通讯股份有限公司 | Method and device for upgrading boot program |
| CN104360877A (en) * | 2014-10-24 | 2015-02-18 | 同济大学 | ECU (electronic control unit) firmware updating method based on Bootloader self update |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7376943B2 (en) * | 2003-12-18 | 2008-05-20 | Lsi Corporation | Safe method for upgrading firmware of optical disk product |
| US7313682B2 (en) * | 2004-04-29 | 2007-12-25 | Alcatel Lucent | Method and system for updating boot memory that stores a fail-safe reset code and is configured to store boot code and boot updater code |
| CN104572141B (en) * | 2013-10-10 | 2019-03-12 | 上海信耀电子有限公司 | The online updating method of the bootstrap of automobile electric control unit ECU |
| CN104090796B (en) * | 2014-07-08 | 2017-06-09 | 成都万维图新信息技术有限公司 | A kind of embedded device method for updating program and system |
| CN106250196A (en) * | 2016-08-12 | 2016-12-21 | 上海金脉电子科技有限公司 | The method updating vehicle-mounted boot loader by CAN communication |
-
2017
- 2017-03-20 CN CN201710166980.6A patent/CN106990982B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1567195A (en) * | 2003-06-20 | 2005-01-19 | 华为技术有限公司 | Method for implementing hot-update of bootstrap program in flush bonding system |
| CN101895671A (en) * | 2010-07-21 | 2010-11-24 | 深圳创维数字技术股份有限公司 | Set top box Loader module updating method and set top box thereof |
| CN102486733A (en) * | 2010-12-03 | 2012-06-06 | 中兴通讯股份有限公司 | Method and device for upgrading boot program |
| CN104360877A (en) * | 2014-10-24 | 2015-02-18 | 同济大学 | ECU (electronic control unit) firmware updating method based on Bootloader self update |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106990982A (en) | 2017-07-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106990982B (en) | Program updating method and device | |
| CN109408153B (en) | Software starting method and software upgrading method | |
| US9471435B2 (en) | Information processing device, information processing method, and computer program | |
| CN106802813B (en) | Method and device for upgrading aerial firmware and vehicle | |
| CN110178114B (en) | Vehicle control device and program update system | |
| KR101427755B1 (en) | Device and method for firmware upgrade using usb | |
| US20080010446A1 (en) | Portable apparatus supporting multiple operating systems and supporting method therefor | |
| WO2009042658A2 (en) | Method, system and apparatus for providing a boot loader of an embedded system | |
| CN108241498B (en) | Vehicle-mounted equipment upgrading method and device and vehicle | |
| CN109408122B (en) | Equipment starting method, electronic equipment and computer storage medium | |
| CN106775674B (en) | Equipment based on universal boot loader and starting method thereof | |
| CN105468384A (en) | Vehicle-mounted controller programming system and method, server and programming terminal | |
| CN109800032B (en) | BOOTROM multi-core loading method and device | |
| CN104063256A (en) | Partition and firmware upgrading method based on minimum operating system | |
| CN101872306A (en) | Embedded system for realizing software updating and software backup and implementation method thereof | |
| US10956144B2 (en) | Apparatus for providing update of vehicle and computer-readable storage medium | |
| US20070050612A1 (en) | Boot program update and restoration system and method thereof | |
| CN106708569B (en) | Hot loading method and device for VOBC configuration file in over-the-line train | |
| CN109032649B (en) | OTA (over the air) upgrading method, device, equipment and storage medium | |
| CN110196730B (en) | Hot patch management method, device and storage medium of application program | |
| CN115756561A (en) | Software upgrading method and device, computer equipment and storage medium | |
| CN114115958A (en) | Program starting method and terminal equipment | |
| CN114237722A (en) | System starting method, device, equipment and engineering vehicle | |
| CN115061713A (en) | Method and device for upgrading electronic equipment | |
| CN112256285A (en) | OTA (over the air) upgrading method of vehicle, computer-readable storage medium and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |