CN113760332A

CN113760332A - Software upgrading method and electronic equipment

Info

Publication number: CN113760332A
Application number: CN202111004328.7A
Authority: CN
Inventors: 刘西富; 徐卫; 刘岩; 李淑荣; 臧胜波
Original assignee: Qingdao Xinxin Microelectronics Technology Co Ltd
Current assignee: Qingdao Xinxin Microelectronics Technology Co Ltd
Priority date: 2021-08-30
Filing date: 2021-08-30
Publication date: 2021-12-07

Abstract

The application provides a software upgrading method and electronic equipment, which are used for solving the problem that the whole electronic equipment cannot continue to operate after upgrading of certain software fails. The target software comprises a first storage area and a second storage area, when the target software is upgraded, one area stores software data of a version to be upgraded, the other area is used for independently updating the software and storing software data of a new version, and if the software upgrading is successfully carried out, the area stores the software data of the new version. And when upgrading next time, updating by adopting another storage area. Each area provided by the application is upgraded independently and the roles can be interchanged. In view of the fact that the first storage area and the second storage area are independently used for software upgrading, even if upgrading fails, the software data of the version to be updated cannot be affected, target software can be operated by the software data of the version to be updated, and normal operation of electronic equipment is guaranteed.

Description

Software upgrading method and electronic equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a software upgrading method and an electronic device.

Background

With the development of internet technology, various electronic devices are widely used in life. Software in the electronic device is upgraded to optimize the functionality of the electronic device. Software upgrades, however, can cause problems that result in the electronic device not being able to continue to operate.

For example, when a single backup electronic device encounters a problem during an upgrade process, the result of each upgrade operation link can be determined by feeding back the upgrade result to the client. Wherein, the result of each upgrading operation link fed back has two types, namely success and failure. However, this method only solves the problem of how to determine the abnormal step of the upgrade, but cannot solve the problem that the single-backup electronic device cannot continue to operate after a certain software fails to be upgraded.

For another example, the dual backup electronic device includes two areas, one of which is a code area and the other is a backup area. When software is upgraded, software data is stored in a backup area and then updated in a code area, and secondary moving of the software data can occur. In addition, if the software upgrade fails, the electronic device may not continue to operate.

In view of the above, a software upgrading method is needed to ensure that the electronic device can still operate normally after the software upgrading fails.

Disclosure of Invention

The embodiment of the application provides a software upgrading method and electronic equipment, and is used for solving the problem that the whole electronic equipment cannot continue to operate after certain software in the existing electronic equipment fails to be upgraded.

In a first aspect, the present application provides a software upgrading method, where target software includes a first storage area and a second storage area, the method including:

identifying a storage area, which does not store the software data of the version to be updated of the target software, in the first storage area and the second storage area as an upgrading area;

and upgrading the target software to an upgrading area, and taking the software data stored in the upgrading area as the software data of the version to be updated in the next upgrading.

Optionally, the target software includes a plurality of upgrade packages, and upgrading the target software to an upgrade area includes:

and performing the following upgrading operation on each data packet one by one until the upgrading operation on the last data packet is performed:

verifying a specified operation result of the data packet, wherein the specified operation result comprises a receiving packet of the data packet and/or a writing packet of the data packet, and the writing packet is a writing result obtained after the receiving packet is written into the upgrading area;

if the verification result of the data packet is verification failure, repeatedly carrying out upgrading operation on the data packet;

if the data packet fails to be upgraded for multiple times, interrupting the software upgrading of the target software;

and if the verification result of the data packet is successful, executing upgrading operation on the next data packet.

Optionally, the target software further includes a third storage area, and the third storage area stores basic startup program data of the target software; the first storage area and the second storage area are used for storing functional data of the target software.

Optionally, the target software is associated with user information, and the user information stores a starting area identifier; identifying a storage area, which does not store the software data of the target software, of the to-be-updated version in the first storage area and the second storage area, as an upgrade area, and including:

reading the starting area identification, and determining a storage area for storing software data of a version to be updated;

taking the other storage area as an upgrading area;

after the target software is upgraded to the upgrade area, the method further comprises:

and if the upgrade is successful, updating the starting area identification to indicate the upgrade area.

Optionally, the method further includes:

and in response to a starting request of the target software, starting the target software by using the software data in the storage area indicated by the starting area identification.

In a second aspect, the present application provides a software upgrading method applied to an upper computer, the method including:

instructing a lower computer to carry out software upgrading on target software, wherein the target software comprises a first storage area and a second storage area in the lower computer;

responding to an upgrade ready message of the lower computer, and controlling the lower computer to upgrade the software of the target software, wherein the lower computer is used for identifying a first storage area and a second storage area which do not store the software data of the version to be updated of the target software and serve as upgrade areas; upgrading the target software to an upgrading area;

and the software data stored in the upgrading area is used as the software data of the version to be updated in the next upgrading.

Optionally, the target software includes a plurality of upgrade packages, and the lower computer is controlled to perform software upgrade on the target software, including:

transmitting any data packet to a lower computer for upgrading operation, and monitoring the upgrading result of the data packet;

if the upgrading result of the data packet is upgrading failure, controlling the lower computer to carry out upgrading operation on the data packet again;

if the data packet fails to be upgraded for multiple times, the software upgrading of the target software is interrupted;

and if the upgrading result of the data packet is successful, transmitting the next data packet to the lower computer for upgrading operation.

Optionally, the monitoring the upgrade result of the data packet includes:

receiving an upgrading result of the data packet fed back by the lower computer;

if the upgrading result is in a successful state, determining that the data packet is upgraded successfully;

if the upgrading result is in an error state, determining that the upgrading of the data packet fails;

and if the upgrading result is in a busy state, determining that the data packet is upgrading.

In a third aspect, the present application provides a software upgrading method applied to a lower computer, the method including:

receiving an upgrading instruction aiming at target software sent by an upper computer;

performing upgrade-ready work based on the upgrade indication;

after the upgrading is ready, identifying a storage area, which does not store the software data of the version to be updated of the target software, in the first storage area and the second storage area as an upgrading area;

and if the verification result of the data is successful, executing upgrading operation on the next data packet.

Optionally, the method further includes:

for any data packet, determining an upgrading result of the data packet based on the upgrading operation condition of the data packet;

if the data packet is upgraded successfully, the upgrading result is recorded as a success state;

if the data packet fails to be upgraded, recording the upgrading result as an error state;

and if the data packet is executing upgrading operation, recording the upgrading result as a busy state.

Optionally, the target software further includes a third storage area, and the third storage area stores basic boot program data of the target software; the first storage area and the second storage area are used for storing functional data of the target software.

Optionally, the target software is associated with user information, and the user information stores a start area identifier; the identifying, as an upgrade area, a storage area in the first storage area and the second storage area where software data of a version to be updated of the target software is not stored includes:

reading the starting area identification, and determining a storage area in which the software data of the version to be updated is stored;

taking another storage area as the upgrading area; after the target software is upgraded to the upgrade area, the method further comprises:

Optionally, the method further includes:

and in response to the starting request of the target software, starting the target software by using the software data in the storage area indicated by the starting area identification.

Optionally, if the target software is successfully upgraded, deleting the software data of the version to be updated.

In a fourth aspect, the present application further provides an electronic device, including:

a processor; a memory for storing processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the software upgrade method as in any one of the first to third aspects above.

In a fifth aspect, the present application also provides a computer-readable storage medium, in which instructions, when executed by a processor of an electronic device, enable the electronic device to perform any of the methods as provided in the first to third aspects of the present application.

In a sixth aspect, an embodiment of the present application provides a computer program product comprising a computer program that, when executed by a processor, implements any of the methods as provided in the first to third aspects of the present application.

In the upgrading process, the first storage area or the second storage area can be independently adopted for software upgrading, software data of a version to be updated cannot be changed, roles of the first storage area and the second storage area are interchanged, existing functions of the software data of the version to be updated can be reserved, the upgrading process is completed, the software data do not need to be moved from a backup area to a code area, secondary moving of the data cannot be generated, one storage area is directly and independently subjected to software upgrading, and resource consumption caused by secondary moving of the software data is avoided.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

FIG. 1 is a schematic diagram of an upgrade software scenario of target software in an embodiment of the present application;

FIG. 2 is a schematic diagram of a memory area required for upgrading software in an embodiment of the present application;

FIG. 3 is a schematic flowchart of a software upgrading method provided in an embodiment of the present application;

FIG. 4 is another schematic diagram of a memory area required for upgrading software in an embodiment of the present application;

FIG. 5 is a flowchart illustrating a software upgrading method provided in an embodiment of the present application;

FIG. 6 is a flowchart illustrating a software upgrading method provided in an embodiment of the present application;

FIG. 7 is a flowchart illustrating a software upgrading method provided in an embodiment of the present application;

FIG. 8 is a flowchart illustrating a software upgrading method provided in an embodiment of the present application;

fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In order to make the technical solutions of the present application better understood by those of ordinary skill in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or otherwise described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

Hereinafter, some terms in the embodiments of the present application are explained to facilitate understanding by those skilled in the art.

(1) In the embodiments of the present application, the term "plurality" means two or more, and other terms are similar thereto.

(2) "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., A and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

(3) A server serving the terminal, the contents of the service such as providing resources to the terminal, storing terminal data; the server is corresponding to the software program installed on the terminal and is matched with the software program on the terminal to run.

(4) The terminal device may refer to an APP (Application, software program) of a software class, or may refer to a client. The system is provided with a visual display interface and can interact with a user; is corresponding to the server, and provides local service for the client. The software programs of the software class are generally installed on a common client terminal except for some software programs which only run locally, and need to be operated in cooperation with a server terminal. For software program upgrading, a corresponding server and a service program in a network are required to provide corresponding services, such as database service, configuration parameter service, storage data service and the like, so that a specific communication connection needs to be established between a client terminal and a server terminal to ensure the normal operation of the software program.

In view of the problem that the electronic device fails to be upgraded and cannot be operated in the prior art, the embodiment of the application provides a software upgrading method and an electronic device.

In the embodiment of the application, the target software comprises a first storage area and a second storage area, and one area stores currently available software data, which is also referred to as software data of a version to be updated in the following text, when the target software is upgraded. And the other area is used for independently upgrading software, and if the software is successfully upgraded, the area stores the updated software data. And when upgrading next time, updating by adopting another storage area. That is, the first storage area and the second storage area provided in the embodiment of the present application are different from the code area and the backup area in the related art, and each area provided in the embodiment of the present application is upgraded independently and roles of the areas can be interchanged. Therefore, the storage areas which do not store the software data of the version to be updated are selected from the first storage area and the second storage area to independently perform software upgrading, so that the software data of the version to be updated are not affected even if the upgrading fails, and the existing functions of the target software can be protected. Therefore, when the upgrading fails, the target software can be operated by adopting the software data of the version to be updated, and the normal operation of the electronic equipment is ensured. In addition, in the embodiment of the application, software data does not need to be moved from the backup area to the code area, but software upgrading is directly and independently performed on one storage area, and resource consumption caused by secondary movement of the software data is also avoided.

After the inventive concept of the embodiment of the present application is introduced, some brief descriptions are made below on the technical solution of the embodiment of the present application, and it should be noted that the software scenario described below is only used for describing the embodiment of the present application and is not limited. In specific implementation, the technical scheme provided by the embodiment of the application can be flexibly implemented according to actual needs.

Reference is made to fig. 1, which is a schematic software scenario diagram of a software upgrading method provided in an embodiment of the present application. The software scenario includes an electronic device 101 and a server 102. The electronic device 101 and the server 102 are connected via a wireless or wired network, and the electronic device 101 includes, but is not limited to, a desktop computer, a mobile phone, a mobile computer, a tablet computer, a media player, a smart wearable device, a smart television, and other electronic devices. The server 102 may be a server, a server cluster composed of several servers, or a cloud computing center. The server 102 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as cloud service, a cloud database, cloud computing, a cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, big data and artificial intelligence platform.

Of course, the method provided in the embodiment of the present application is not limited to the scenario shown in fig. 1, and may also be used in other possible scenarios, and the embodiment of the present application is not limited. The functions that can be implemented by each device in the scenario shown in fig. 1 will be described in the following method embodiments, and will not be described in detail herein.

The server 102 provides the software data to the electronic device 101. For example, the electronic device 101 may send an update request to the server 102 to perform software update on the target software, and the server may send corresponding software data to the electronic device for software upgrade according to the update request.

When the target software is upgraded, the target software upgrading method comprises two storage areas, wherein one storage area stores software data of a version to be updated, and the other storage area is used for independently updating the software and storing the software data of the new version. And if the target software is installed in the first storage area, updating the second storage area by the software data sent by the server during upgrading. And after successful updating, adopting the software data of the updated version to operate the target software. If the target software fails to be upgraded, the software data of the version to be updated cannot be affected, and the target software can be operated through the software data of the version to be updated, so that the existing functions of the target software can be protected. Therefore, when the upgrading fails, the target software can be operated by adopting the software data of the version to be updated, and the normal operation of the electronic equipment is ensured.

To further illustrate the technical solutions provided by the embodiments of the present application, the following detailed description is made with reference to the accompanying drawings and the detailed description. Although the embodiments of the present application provide the method operation steps as shown in the following embodiments or figures, more or less operation steps may be included in the method based on the conventional or non-inventive labor. In steps where no necessary causal relationship exists logically, the order of execution of the steps is not limited to that provided by the embodiments of the present application.

Illustratively, as shown in fig. 2, when the target software is upgraded, two storage areas are included, one area stores the software data of the version to be updated, and the other area is used for the software upgrade. In the embodiment of the present application, it is not limited which of the first storage area and the second storage area is the code area, that is, the roles of the first storage area and the second storage area may be interchanged with the upgrading of the target software. Based on this, a flow diagram of the software upgrading method provided by the embodiment of the present application may be as shown in fig. 3:

s301, identifying a storage area, which does not store the software data of the version to be updated of the target software, in the first storage area and the second storage area as an upgrading area;

and S302, upgrading the target software to an upgrading area, and taking the software data stored in the upgrading area as the software data of the version to be updated in the next upgrading.

For example, the target software is installed in a first storage area, and when the target software is upgraded for the first time, the software data stored in the first storage area is the data of the version to be updated, and the software is updated by using a second storage area. After successful updating, the second storage area stores the updated version of the software data, and the software data in the first storage area can be emptied. Then, when the target software is subjected to software upgrading for the second time, the software data stored in the second storage area becomes new software data of the version to be updated, then, the first storage area is adopted for software upgrading, and the subsequent upgrading can be performed by the same way, and is not repeated. Therefore, in the upgrading process, the first storage area or the second storage area can be independently adopted for software upgrading, software data of a version to be updated is not changed, roles of the first storage area and the second storage area are exchanged, the existing functions of the software data of the version to be updated can be kept, the upgrading process is completed, the software data do not need to be moved from the backup area to the code area, secondary movement of the data is generated, one storage area is directly and independently subjected to software upgrading, and resource consumption caused by secondary movement of the software data is avoided.

In other embodiments, if the device includes a plurality of pieces of software, in order to upgrade the plurality of pieces of software, in this embodiment of the application, a plurality of storage areas may be provided, for example, in the case of two pieces of software, a storage area a for storing the first piece of software, a storage area B for storing the second piece of software, and a free storage area C. When the first software is updated, the idle area is preferentially adopted to finish the updating of the first software. The case memory area a is stored after the first software is successfully updated. At this time, the storage area a is a free area, the storage area B stores the second software, and the storage area C stores the first software. And when the second software needs to be updated, the idle area A is adopted to complete the update of the second software, so that the idle area is updated to be the storage area B. Therefore, the idle area is changed along with updating in the plurality of areas, and the idle area is adopted for updating when any software is updated, so that the condition that the software cannot be allowed due to failure in updating the data of the original storage area is avoided.

In the embodiment of the application, the software data of the target software can be divided into basic starting program data and functional data. Basic boot program data, i.e., the basic boot code for booting; the functional data includes software functional codes and codes for realizing various functional configurations. Therefore, in order to reduce the data amount processed when the target software is upgraded, the updating efficiency is improved. As shown in fig. 4, in the embodiment of the present application, not only the first storage area and the second storage area but also the third storage area are provided. The first storage area and the second storage area are used for storing functional data of target software; the third storage area stores basic startup program data of the target software. In view of the fact that the basic starting program data does not need to be updated in the upgrading process, only the functional data of the target software can be updated, and therefore the data amount processed when the target software is upgraded is reduced, and the updating efficiency is improved.

In another embodiment, as shown in fig. 4, a fourth storage area is further provided in the embodiment of the present application, for storing user information. The user information comprises a starting area identifier, and the starting area identifier is used for indicating whether the target software is operated by adopting the first storage area or the second storage area when the target software is started. For example, when the boot area flag is 0, it indicates that the target software is booted using the first storage area, and when the boot area flag is 1, it indicates that the target software is booted using the second storage area. Thus, upon identifying the upgrade area in S301, it may be performed as: reading a starting area identifier, and determining a storage area for storing software data of a version to be updated; and then the other storage area is used as an upgrade area. For example, if the start area flag is 0, it indicates that the first storage area stores software data of a version to be updated, and the second storage area is used as an upgrade area for software update.

In order to facilitate the role exchange between the first storage area and the second storage area, in the embodiment of the application, after the target software is upgraded to the upgrade area, if the target software is upgraded successfully, the start area identifier is updated to indicate the upgrade area. For example, if the boot area flag is updated to 1, and 1 indicates the second storage area, the target software is booted using the second storage area. Therefore, when software is upgraded next time, the other storage area can be determined to be adopted for software updating according to the starting area identification.

Therefore, in the embodiment of the application, the upgrading area can be simply and conveniently determined by adopting the starting area identifier in the user information, and the role exchange between the first storage area and the second storage area can be conveniently realized.

Another purpose of the start area identifier is to start the target software, and the target software can be started by using the software data in the storage area indicated by the start area identifier in response to a start request of the target software. Thus, it is possible to easily determine which storage area software data should be activated based on the activation area identifier.

In another embodiment, the target software includes a plurality of upgrade packages, and when the data of the version to be updated in the target software is upgraded to the upgrade area, the upgrade packages included in the target software are upgraded. In order to achieve the accuracy of the transmission/writing process of each data packet, the upgrade operation shown in fig. 5 may be performed on each data packet one by one until the upgrade operation on the last data packet is performed, as shown in fig. 5, and a specific upgrade operation may include the following steps.

S501, verifying a specified operation result of the data packet, wherein the specified operation result comprises a receiving packet of the data packet and/or a writing packet of the data packet, and the writing packet is a writing result after the receiving packet is written into the upgrading area. The check of the received packet of the data packet can be used for judging the accuracy of the data packet in the transmission process, and the check of the written packet of the data packet can be used for judging the accuracy of the data packet in the written process.

The process of checking each upgrade package in the target software comprises 3 checking modes:

(1) for example, the received packet is analyzed and verified according to a predefined format, the receiving process of the received packet and the content of the received packet data are both verified, and if the received packet is 10 bytes of data and only 8 bytes of data packets are received, it can be considered that the received packet has a problem in the data transmission path, the receiving process of the received packet has an error, and the received packet verification fails. And if the check information in the received packet is consistent with the received data after calculation and comparison. If the data content of the received packet is inconsistent with the data content of the received packet, the received packet is considered to be in error, and the received packet is failed to be checked. Otherwise, the received packet is successfully checked. The received packet is checked to ensure the integrity and correctness of data transmission.

(2) Verification of the write packet of the data packet, for example, verification of the write packet in the upgrade area, determines whether the read-back data after writing is consistent with the data to be written. If not, the check of the write packet may be deemed to have failed. Otherwise, the write packet is verified successfully. Of course, the integrity of the write packet may also be checked, so that the integrity and correctness of the write data packet can be guaranteed by checking the write packet.

(3) The received packet and the written packet are checked, for example, for the reception process of the received packet and the content of the received packet data. If the receiving process of the receiving packet and the content of the receiving packet data have no problem, the verification result of the receiving packet is successful, the receiving packet is written into the upgrading area, the written packet is verified in the upgrading area, and whether the read-back data after being written is consistent with the data to be written is determined. The specific checking process is the same as the above (1) and (2), and the details are not repeated here.

In the above three modes, if the write stability of the data packet is high, the received packet can be checked separately, i.e., the checking mode (1) is performed. If the transmission stability of the data packet is high, the write packet can be checked independently, i.e. the checking mode (2) is executed. The data packet is only subjected to receiving packet verification or writing packet verification, so that the data packet verification time can be saved, the target software upgrading time is shortened, and the target software upgrading efficiency is accelerated. If the data packet is subjected to the verification of the receiving packet and the verification of the writing packet, the smooth upgrading of the data packet can be further ensured through twice verification of the data packet.

And S502, if the verification result of the data packet is successful, executing the upgrading operation of the next data packet.

S503, if the verification result of the data packet is verification failure, repeatedly upgrading the data packet;

if the received data packet is checked, when the check fails, the receiving process of the data packet may be in error or the data content of the data packet may be in error. For example, a data transmission path problem, such as receiving 10 bytes of data, results in only 8 bytes being received. The received data packet contains check information, and the received data is inconsistent with the check information after calculation. If the write packet of the data packet is checked, it may be that the read-back data after writing is inconsistent with the data to be written. If the received packet and the written packet of the data packet are checked, the reasons of the failure check include errors in the receiving process of the data packet, errors in the content of the data packet, errors in writing the data packet, and the like. The reason for the specific verification failure is analyzed in the same way as above, and is not described herein again.

S504, if the data packet fails to be upgraded for multiple times, the software upgrading of the target software is interrupted;

if the verification result of the current verification data packet is verification failure, the data packet is repeatedly upgraded for many times, and the data packet can be successfully upgraded as far as possible. If the verification result of the data packet fails for multiple times, the data in the data packet is wrong, the target software is abandoned to be upgraded, and resource consumption caused by invalid upgrading operation is avoided.

The first storage area and the second storage area provided by the embodiment of the application can be upgraded independently, and roles can be interchanged. Therefore, the storage areas which do not store the software data of the version to be updated are selected from the first storage area and the second storage area to independently perform software upgrading, so that the software data of the version to be updated are not affected even if the upgrading fails, and the existing functions of the target software can be protected. Therefore, when the upgrading fails, the target software can be operated by adopting the software data of the version to be updated, and the normal operation of the electronic equipment is ensured. In addition, in the embodiment of the application, software data does not need to be moved from the backup area to the code area, but software upgrading is directly and independently performed on one storage area, and resource consumption caused by secondary movement of the software data is also avoided. In addition, in this embodiment, the verification of the receiving packet and/or the writing packet is performed on each upgrade packet in the target software, so as to ensure the accuracy of the data.

Based on the same inventive concept, if the internal upgrading of the electronic equipment is mainly performed by two parts, one part is an upper computer and the other part is a lower computer, the embodiment of the application provides a software upgrading method aiming at the upper computer and the lower computer. Taking an electronic device as an example, an upper computer is, for example, a System On Chip (SOC), a lower computer is, for example, a Micro Control Unit (MCU), the upper computer obtains software upgrading data, and sends the software data to the lower computer through protocols such as I2C/SPI/UART (I2C (Inter-Integrated Circuit bus), SPI (Serial Peripheral Interface), UART (Universal Asynchronous Receiver Transmitter)) and the like; the lower computer receives and upgrades the software data, and how the upper computer and the lower computer cooperate to complete the software upgrade is described below, and a flow diagram of a specific software upgrade method is shown in fig. 6:

s601, the upper computer indicates the lower computer to carry out software upgrading on target software, wherein the target software comprises a first storage area and a second storage area in the lower computer. For example, the upper computer sends an upgrade instruction to the lower computer, which is used for instructing the lower computer to upgrade the target software.

And S602, the lower computer receives an upgrade instruction aiming at the target software sent by the upper computer and executes the upgrade ready work based on the upgrade instruction.

And S603, sending an upgrade ready message to the upper computer after the lower computer is ready for upgrading.

And S604, the upper computer responds to the upgrading ready message of the lower computer and controls the lower computer to upgrade the target software.

During implementation, the APP function state machine of the lower computer can comprise the following working states:

a normal processing state (normal processing state) indicating that the lower computer is in normal logical function processing, for example, a function is being executed;

an upgrading status (upgrading status) indicating that the lower computer can perform software upgrading operation of related software;

an idle state (idle status) indicating an idle period in which the lower computer is in the upgrade state, and indicating that the processing of the previous upgrade package is completed and the next upgrade package can be received.

The upper computer may send an RDSR (Receive Data Service Request) command for reading a state of the APP function state machine of the lower computer. Therefore, the upper computer can conveniently send the upgrading instruction and control the sending time of the upgrading packet.

When the lower computer is in a normal state, if an upgrading instruction of the upper computer is received, the lower computer enters an upgrading state (upgrading status). In this upgrade state, the lower level will first perform an upgrade preparation. The upgrade preparation work varies from software to software or from electronic device to electronic device, and there is no uniform standard. Initialization of various states, flags, and even shutdown of some functional models may be involved, and even a reboot of the lower computer may be involved in some cases. In short, the upgrade preparation work can be determined according to actual conditions, as long as the data receiving, storing and checking in the upgrade process can be guaranteed.

After the upgrade preparation work is finished, an upgrade ready message is fed back to the upper computer, and then the upgrade packet data can be received.

When software is upgraded, the lower computer needs to identify, as an upgrade area, a storage area in the first storage area and the second storage area, where software data of a version to be updated of the target software is not stored.

And S606, the lower computer upgrades the target software to an upgrading area. That is, the received upgrade package is written into the upgrade area by the lower computer to perform software upgrade. After the upgrade is successful, the software data stored in the upgrade area is used as the software data of the version to be updated in the next upgrade. Therefore, the roles of the two storage areas are exchanged, and the two storage areas are independently upgraded.

As previously described, the target software includes a plurality of upgrade packages, each of which is checked for data integrity and accuracy. The checking method has been described above, and is not described herein again. The embodiment of the application mainly illustrates that the lower computer performs verification and feeds back a verification result to the upper computer so that the upper computer can conveniently control the transmission of the upgrade patch. As shown in fig. 6, the following steps are included.

S607, the upper computer transmits any data packet to the lower computer for upgrading operation and monitors the upgrading result of the data packet; the upgrading result of the data packet comprises the following steps: upgrading is successful and failed.

And S608, the lower computer checks the appointed operation result of the data packet, wherein the appointed operation result comprises a receiving packet of the data packet and/or a writing packet of the data packet.

And S609, if the lower computer successfully verifies the data packet, the lower computer sends a verification success message to the upper computer. The verification success message can be used for indicating that the upgrading result of the data packet is successful in upgrading.

S610, the upper computer receives the message that the upgrading result of the data packet is successful in upgrading, and the upper computer transmits the next data packet to the lower computer for upgrading operation.

S611, the lower computer receives the next data packet and performs an upgrade operation on the next data packet. I.e., the upgrade operation of S608 is continuously performed on the next packet.

And S612, if the verification result of the data packet of the lower computer is verification failure, the lower computer sends a verification failure message to the upper computer. The check failure message may be used to indicate that the upgrade result of the data packet is an upgrade failure.

If the received data packet is checked, when the check fails, the receiving process of the data packet may be in error or the data content of the data packet may be in error. For example, the receiving process of the data packet is erroneous, for example, 10 bytes of data are received, and as a result, only 8 bytes are received. If the data packet has an error, if the received data packet has the check information, the received data is inconsistent with the check information after calculation. If the write packet of the data packet is verified, when the verification fails, it may be that the write error is that the read-back data after writing is inconsistent with the data to be written. If the received packet and the written packet of the data packet are checked, the reasons of the failure check include errors in the receiving process of the data packet, errors in the content of the data packet, errors in writing the data packet, and the like. The reason for the specific verification failure is analyzed in the same way as above, and is not described herein again.

In implementation, each data packet may maintain a corresponding status, for example, a busy status is used to indicate that an upgrade operation is being performed on the current data packet, no operation result is obtained yet, a successful status is used to indicate that the current data packet is successfully upgraded, and an error status is used to indicate that the upgrade operation on the current data packet fails. And the upper computer can read the state of the data packet maintained by the lower computer. For example, a busy status is read and the result of the upgrade operation for the packet may be awaited. And if the successful state is read, the next data packet can be sent to the lower computer, and if the error state is read, the data packet is retransmitted. When the data packet is in an error state or a success state, the working state of the corresponding lower computer can be synchronously updated to be an idle state. If the upper computer reads the idle state of the lower computer, the data packet can be sent to the lower computer.

And S613, if the upgrade result of the data packet received by the upper computer is upgrade failure, controlling the lower computer to perform upgrade operation on the data packet again. I.e., the upgrade operation of S608 is re-performed on this packet.

And S614, the lower computer repeatedly performs upgrading operation on the data packet, and if the data packet fails to be upgraded for multiple times, the software upgrading of the target software is interrupted.

As described above, the lower computer determines the update result of the data packet for the update operation condition of any data packet, and then, the lower computer feeds back the update result to the upper computer.

If the lower computer successfully upgrades the data packet, the upgrading result is recorded as a successful state; and feeds back the upgrade result to the upper computer as a success state. And the upper computer receives the upgrading result as a successful state and determines that the data packet is upgraded successfully.

If the lower computer data packet fails to be upgraded, the upgrading result is recorded as an error state; and feeds back an upgrading result to the upper computer as an error state. And the upper computer receives the upgrading result as an error state and determines that the data packet is failed to be upgraded.

And if the lower computer data packet is executing the upgrading operation, recording the upgrading result as a busy state. And feeds back the upgrading result to the upper computer as a busy state. And the upper computer receives the upgrading result as a busy state and determines that the data packet is upgrading.

In this embodiment, whether the data packet is in the process of upgrading operation or whether the data packet upgrading result is successful or failed can be determined according to the data packet upgrading result fed back by the lower computer.

For convenience of understanding, the embodiment of the present application provides a software upgrading method for an upgrading process between a System On Chip (SOC) and a Micro Controller Unit (MCU) where the upper computer is an SOC and the lower computer is an MCU.

In this embodiment the SOC is an integrated circuit with a dedicated target that contains the complete system and has the full contents of the embedded software. The MCU is a general-purpose computer that integrates peripheral interfaces such as a Memory, a counter, an a/D converter (USB), a UART (Universal Asynchronous Receiver Transmitter), a PLC (Programmable Logic Controller), a DMA (Direct Memory Access), and an LCD (Liquid Crystal Display) driving circuit on a single chip to form a chip-level computer, and performs different combination control for different software occasions, such as a mobile phone, a computer peripheral, a remote Controller, a stepping motor in the automobile electronics, an industrial stepping motor, and a robot control.

In this embodiment, in order to complete the upgrade of the target software, the SOC and the MCU divide the target software into four regions, as shown in fig. 4, a first storage region and a second storage region are used for storing functional data of the target software; the functional data refers to software data. One of the first storage area and the second storage area stores software data of a version to be updated, and the other area is used for software upgrading. In the embodiment of the present application, it is not limited which of the first storage area and the second storage area is the code area, that is, the roles of the first storage area and the second storage area may be interchanged with the upgrading of the target software.

The third storage area stores basic startup program data of the target software; in view of the fact that the basic starting program data does not need to be updated in the upgrading process, only the functional data of the target software can be updated, and therefore the data amount processed when the target software is upgraded is reduced, and the updating efficiency is improved.

The fourth storage area is used for storing user information. The user information comprises a starting area identifier, and the starting area identifier is used for indicating whether the target software is operated by adopting the first storage area or the second storage area when the target software is started. For example, when the boot area flag is 0, it indicates that the target software is booted using the first storage area, and when the boot area flag is 1, it indicates that the target software is booted using the second storage area.

The following description is provided for how the SOC and the MCU cooperate to complete software upgrade, and a flow diagram of a specific software upgrade method is shown in fig. 7;

s701, the SOC indicates the MCU to carry out software upgrading on the target software, wherein the target software comprises a first storage area and a second storage area in the MCU.

S702, the SOC reads the APP function state machine of the MCU through an RDSR (received Data Service Request) command, and the APP function state machine of the MCU can have the following working states:

After receiving the upgrade command in the normal state, the MCU enters the upgrade state to complete some upgrade preparation work, and after completing the upgrade preparation work, the MCU feeds back the upgrade ready information to the SOC in S703.

And S704, the SOC responds to the upgrading ready message of the MCU and controls the MCU to upgrade the target software.

In the process of upgrading the target software by the SOC control MCU, if the target software is installed in a first storage area of the MCU, and software data stored in the first storage area is the data of the version to be updated during the first upgrading, the software is updated by using a second storage area. After successful updating, the second storage area stores the updated version of the software data, and the software data in the first storage area can be emptied. Then, when the target software is subjected to second software upgrading, the software data stored in the second storage area becomes new software data of a version to be updated, and then the first storage area is adopted for software upgrading. The subsequent upgrade can be analogized, and is not described in detail. Therefore, in the upgrading process, the first storage area or the second storage area can be independently adopted for software upgrading, software data of a version to be updated is not changed, roles of the first storage area and the second storage area are exchanged, the existing functions of the software data of the version to be updated can be kept, the upgrading process is completed, the software data do not need to be moved from the backup area to the code area to generate data secondary movement, but one storage area is directly and independently subjected to software upgrading, and resource consumption caused by secondary movement of the software data is avoided.

In order to ensure the transmission integrity and accuracy of each upgrade package, in S705 in the embodiment of the present application, the SOC transmits any data package to the MCU for upgrade operation. In S706, the MCU checks the received packet and the written packet for each data packet, and maintains the upgrade operation status of the data packet. Busy status, success status and error status as described previously.

And S707, the SOC reads the upgrading operation state of the data packet of the MCU through an RDSR command.

And S708, if the upgrading operation state of the MCU is a successful state, the SOC transmits the next data packet to the MCU for upgrading operation.

And S709, if the upgrading operation state of the MCU is a busy state, at the moment, the data packet is upgrading, and the SOC can continuously read the upgrading operation state.

And S710, if the upgrading operation state of the MCU is an error state, confirming that the upgrading of the data packet fails, and then executing the step S711.

And S711, the SOC control MCU renews the upgrading operation on the data packet and returns to execute the step 707. In addition, the number of upgrades repeated for the data packet may be recorded.

And S712, if the MCU fails to upgrade the data packet for multiple times, the SOC interrupts the upgrade of the target software.

S713, finishing the upgrading operation of the last data packet and finishing the upgrading of the target software.

After successful upgrade, whether the update field in the user information can be updated from yes to no, and the start area identification field can be updated to the identification of the upgrade area.

And S714, after the upgrading is successful, the MCU updates the user information stored in the fourth storage area. The user information includes a start area identifier, for example, when the start area identifier is 0 before the target software is upgraded, it indicates that the target software is started using the first storage area. And when the starting area mark is 1, the target software is started by adopting the second storage area. And after the target software is upgraded to the upgrading area, if the target software is successfully upgraded, updating the starting area identification to indicate the upgrading area. For example, if the boot area flag is updated to 1, and 1 indicates the second storage area, the target software is booted using the second storage area.

The user information also comprises update indication information, after the upgrade is successful, the value of the update indication information is set as a value for identifying the update, and when the upgrade fails, the value is kept to represent no update.

And S715, finishing the upgrading of the target software by the MCU.

In the embodiment of the present application, after the target software upgrade is finished, in the process of starting the target software, the steps shown in fig. 8 may be executed.

S801, determining the value of the user information updating indication information stored in the fourth storage area, and driving whether the target software is updated or not based on the value.

S802, if the update is indicated, if the start identifier indicates the first storage area, it indicates that the first storage area has the latest version of the software data, so that the data in the second storage area is cleared, the memory occupied by the software data of the target software is saved, if the second storage area indicated by the start identifier indicates the first storage area, the software data in the first storage area is deleted, and then S803 is executed.

And S803, updating the user information, such as setting the value of the updating indication information to a value indicating no updating, and then starting the target software by using the storage area indicated by the starting identifier.

S804, under the condition that the updating is not indicated, the target software is started by adopting the storage area indicated by the starting identifier.

Having described the method and apparatus of an exemplary embodiment of the present application, an electronic device according to another exemplary embodiment of the present application is described next.

As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method or program product. Accordingly, various aspects of the present application may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.

In some possible implementations, an electronic device according to the present application may include at least one processor, and at least one memory. Wherein the memory stores program code which, when executed by the processor, causes the processor to perform the task scheduling method according to various exemplary embodiments of the present application described above in this specification. For example, the processor may perform steps as in a task scheduling method.

An electronic apparatus according to this embodiment of the present application is described below with reference to fig. 9. The electronic device shown in fig. 9 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 9, the electronic device 130 is represented in the form of a general electronic device. The components of the electronic device 130 may include, but are not limited to: the at least one processor 131, the at least one memory 132, and a bus 133 that connects the various system components (including the memory 132 and the processor 131).

Bus 133 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor, or a local bus using any of a variety of bus architectures.

The memory 132 may include readable media in the form of volatile memory, such as Random Access Memory (RAM)1321 and/or cache memory 1322, and may further include Read Only Memory (ROM) 1323.

Memory 132 may also include a program/utility 1325 having a set (at least one) of program modules 1324, such program modules 1324 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

The electronic device 130 may also communicate with one or more external devices 134 (e.g., keyboard, pointing device, etc.), with one or more devices that enable a user to interact with the electronic device 130, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 130 to communicate with one or more other electronic devices. Such communication may occur via input/output (I/O) interfaces 135. Also, the electronic device 130 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) via the network adapter 136. It should be understood that although not shown in the figures, other hardware and/or software modules may be used in conjunction with electronic device 130, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

In an exemplary embodiment, a computer-readable storage medium including instructions, such as the memory 132 including instructions, is also provided. Alternatively, the storage medium may be a non-transitory computer readable storage medium, which may be, for example, a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

In an exemplary embodiment, a computer program product is also provided, comprising a computer program which, when executed by the processor 131, implements any of the software upgrade methods as provided herein.

In an exemplary embodiment, the various aspects of the software upgrading method provided in the present application may also be implemented in the form of a program product including program code for causing a computer device to perform the steps in the software upgrading method according to various exemplary embodiments of the present application described above in this specification, when the program product is run on the computer device.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The program product for the software upgrading method of the embodiment of the present application may employ a portable compact disc read only memory (CD-ROM) and include program codes, and may be run on an electronic device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the consumer electronic device, partly on the consumer electronic device, as a stand-alone software package, partly on the consumer electronic device and partly on a remote electronic device, or entirely on the remote electronic device or server. In the case of remote electronic devices, the remote electronic devices may be connected to the consumer electronic devices through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to external electronic devices (e.g., through the internet using an internet service provider).

Further, while the operations of the methods of the present application are depicted in the drawings in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable image scaling apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable image scaling apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims

1. A method of upgrading software, wherein target software includes a first memory region and a second memory region, the method comprising:

identifying a storage area, which does not store the software data of the target software to be updated, in the first storage area and the second storage area as an upgrading area;

and upgrading the target software to the upgrading area, and taking the software data stored in the upgrading area as the software data of the version to be updated in the next upgrading.

2. The method of claim 1, wherein the target software comprises a plurality of upgrade packages, and wherein upgrading the target software to the upgrade area comprises:

if the verification result of the data packet is verification failure, repeatedly upgrading the data packet;

3. The method of claim 1, wherein the target software further has a third storage area, the third storage area having stored therein basic initiator data of the target software; the first storage area and the second storage area are used for storing functional data of the target software.

4. The method according to claim 1, wherein the target software is associated with user information, and the user information stores therein a boot area identifier; the identifying, as an upgrade area, a storage area in the first storage area and the second storage area where software data of a version to be updated of the target software is not stored includes:

taking another storage area as the upgrading area;

5. The method of claim 4, further comprising:

6. A software upgrading method is applied to an upper computer, and comprises the following steps:

responding to an upgrade ready message of the lower computer, and controlling the lower computer to upgrade the software of the target software, wherein the lower computer is used for identifying a storage area which is not stored with the software data of the version to be updated of the target software and is used as an upgrade area; upgrading the target software to the upgrading area;

7. The method of claim 6, wherein the target software comprises a plurality of upgrade packages, and the controlling the lower computer to perform software upgrade on the target software comprises:

transmitting any data packet to the lower computer for upgrading operation, and monitoring the upgrading result of the data packet;

8. A software upgrading method is applied to a lower computer, and the method comprises the following steps:

performing upgrade-ready work based on the upgrade indication;

9. The method of claim 8, wherein the target software includes a plurality of upgrade packages, and wherein upgrading the target software to the upgrade area comprises:

10. An electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the software upgrade method of any one of claims 1-9.