Upgrade processing method, device and electronic equipment based on embedded system

Abstract

The present application discloses an upgrade processing method, device and electronic device based on an embedded system, and relates to the field of data processing technology. The method includes: first obtaining the firmware information to be upgraded of the target application in the embedded system; then according to the firmware information to be upgraded, saving the upgrade configuration information of the target application in the first area; then restarting the embedded system, after the BootLoader is executed, according to the upgrade configuration information of the target application read, the firmware information to be upgraded overwrites the original firmware information of the target application; generates the upgrade configuration information of the BootLoader and saves it in the second area, wherein the first area and the second area are different areas; sets the watchdog function in the BootLoader, and runs the target application for testing. After the upgrade, if the embedded system runs abnormally, the application can be discovered and processed in time after testing.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to an upgrade processing method, device and electronic equipment based on an embedded system. Background Art

[0002] Embedded devices are mainly composed of embedded processors, related supporting hardware and embedded software systems. They are "devices" that integrate hardware and software and can work independently. Among them, embedded software systems (referred to as embedded systems) are different from general computer processing systems. They do not have large-capacity storage media like hard disks, but mostly use flash memory as storage media. Embedded software includes hardware-related underlying software, operating systems, graphical interfaces, communication protocols, database systems, standardized browsers and application software.

[0003] Currently, embedded devices need to be remotely upgraded to resolve bugs and adapt to changing needs. However, during the remote upgrade process, there is a possibility that the operator may send the wrong firmware, transmission errors, firmware problems, etc., causing the embedded system to run abnormally after the upgrade. Summary of the invention

[0004] In view of this, the present application provides an upgrade processing method, device and electronic device based on an embedded system, the main purpose of which is to improve the technical problem in the current prior art that it is impossible to timely monitor the abnormal operation of the embedded system after the upgrade so as to handle it in time.

[0005] According to one aspect of the present application, there is provided an upgrade processing method based on an embedded system, the method comprising:

[0006] Obtain the firmware information to be upgraded of the target application in the embedded system;

[0007] According to the firmware information to be upgraded, the upgrade configuration information of the target application is saved in the first area;

[0008] Restarting the embedded system, after the BootLoader is executed, overwriting the original firmware information of the target application with the firmware information to be upgraded according to the read upgrade configuration information of the target application;

[0009] Generate BootLoader upgrade configuration information and save it in a second area, wherein the first area and the second area are different areas;

[0010] The watchdog function is set in the BootLoader, and the target application is run for testing.

[0011] According to another aspect of the present application, an upgrade processing device based on an embedded system is provided, the device comprising:

[0012] An acquisition module, used to acquire firmware information to be upgraded of a target application in an embedded system;

[0013] A saving module, configured to save the upgrade configuration information of the target application in the first area according to the firmware information to be upgraded;

[0014] An upgrade module, used for restarting the embedded system, and after the BootLoader is executed, overwriting the original firmware information of the target application with the firmware information to be upgraded according to the upgrade configuration information of the target application read;

[0015] The saving module is further used to generate upgrade configuration information of the BootLoader and save it in a second area, wherein the first area and the second area are different areas;

[0016] The test module is used to set the watchdog function in the BootLoader and run the target application for testing.

[0017] According to another aspect of the present application, a storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the above-mentioned upgrade processing method based on the embedded system is implemented.

[0018] According to another aspect of the present application, an electronic device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the above-mentioned upgrade processing method based on the embedded system when executing the computer program.

[0019] By means of the above technical scheme, the present application provides an upgrade processing method, device and electronic device based on an embedded system. After obtaining the firmware information to be upgraded of the target application in the embedded system, according to the firmware information to be upgraded, the upgrade configuration information of the target application is saved in the first area; then the embedded system is restarted, and after the BootLoader is executed, the firmware information to be upgraded is overwritten with the original firmware information of the target application according to the upgrade configuration information of the read target application; after the overwriting is correct, the upgrade configuration information of the BootLoader is generated and saved in the second area, and the watchdog function is subsequently set in the BootLoader, and the target application is run for testing. Compared with the prior art, the present application can be found and processed in time if the embedded system runs abnormally after the upgrade. And in the upgrade processing process, two different areas (addresses) are used to store the upgrade configuration information of the target application and the upgrade configuration information of the BootLoader respectively, which can avoid the upgrade configuration information of the target application being changed by the BootLoader, or the upgrade configuration information of the BootLoader being changed by the target application, thereby preventing the cross-write operation from causing data loss, thereby improving the accuracy of the target application upgrade in the embedded system.

[0020] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0022] Figure 1 A schematic diagram of a flow chart of an upgrade processing method based on an embedded system provided in an embodiment of the present application is shown;

[0023] Figure 2 A schematic diagram of the process of starting an embedded system provided in an embodiment of the present application is shown;

[0024] Figure 3 A schematic diagram of a flow chart of another upgrade processing method based on an embedded system provided in an embodiment of the present application is shown;

[0025] Figure 4 A schematic diagram of a process flow of an application example provided by an embodiment of the present application is shown;

[0026] Figure 5A schematic structural diagram of an upgrade processing device based on an embedded system provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0027] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that the embodiments and features in the embodiments of the present application can be combined with each other without conflict.

[0028] In order to improve the technical problem that the existing technology cannot timely monitor the abnormal operation of the embedded system after the upgrade so as to handle it in time. This embodiment provides an upgrade processing method based on the embedded system, such as Figure 1 As shown, the method includes:

[0029] Step 101: Obtain firmware information to be upgraded of a target application in an embedded system.

[0030] The embedded system may be an embedded software system in an embedded device, and the embedded device may be an embedded device in a smart cabinet (such as a courier cabinet, a food collection cabinet, etc.), a food delivery device, a power control board, or other smart devices. The target application (Application, APP) may be an embedded software, which may specifically include: hardware-related underlying software, operating system, graphical interface, communication protocol, database system, standardized browser, and application software, etc. In this embodiment, the upgrade process of one of the embedded software (i.e., the target application, APP program) is taken as an example to illustrate the specific upgrade process.

[0031] In this embodiment, after receiving the upgrade instruction, the target application (APP program) starts to download the firmware information to be upgraded (APP), and the firmware information can be used to upgrade the target application. For example, the firmware information to be upgraded of the target application can be downloaded through the technical means of the Internet of Things (IOT) to achieve the Over-the-Air Technology (OTA) upgrade of the target application.

[0032] Step 102: According to the to-be-upgraded firmware information of the target application, save the upgrade configuration information of the target application in the first area.

[0033] The upgrade configuration information of the target application may include: firmware version, firmware size, checksum, and flags that need to be upgraded, etc. The first area may be an area inside or outside the flash memory, which is used to store the upgrade configuration information of the target application.

[0034] Step 103: Restart the embedded system. After the BootLoader is executed, the firmware information to be upgraded will be overwritten with the original firmware information of the target application according to the upgrade configuration information of the target application read.

[0035] Bootloader is the first code executed by the embedded system after power-on. It is a small program that runs before the operating system kernel runs. Through this small program, the hardware devices can be initialized and the memory space mapping can be established, so as to bring the system's hardware and software environment to a suitable state, so as to prepare the correct environment for the final call to the operating system kernel. Correspondingly, the target application (APP program) can be considered as the code that executes the application logic.

[0036] For example, Figure 2 As shown in the figure, after the embedded system is powered on, the BootLoader program will be executed first, and then the APP program will be executed.

[0037] The original firmware information of the target application is the original firmware information of the target application before it is upgraded. Restart the embedded system to enter the Bootloader. After the BootLoader program is executed, read the upgrade configuration information of the target application; then determine whether an upgrade is required based on the upgrade configuration information. After determining that an upgrade is required, use the acquired target application's firmware information to be upgraded (new firmware) to overwrite the original firmware information (old firmware) of the target application to complete the upgrade operation.

[0038] Step 104: Generate BootLoader upgrade configuration information and save it in the second area.

[0039] The first area and the second area are different areas, and the second area may be another area inside or outside the flash memory.

[0040] After the new firmware of the target application correctly overwrites the old firmware, the upgrade configuration information such as the upgraded mark and the upgrade time is written into the second area corresponding to the BootLoader.

[0041] In the current existing technology, APP and BootLoader will jointly operate the same upgrade configuration file (i.e., the same upgrade configuration information), which may be abnormally rewritten. For example, during the APP upgrade process, the upgrade configuration information of the APP is changed by the BootLoader, or the upgrade configuration information of the BootLoader is changed by the APP.

[0042] Compared with the prior art, the upgrade processing method of this embodiment uses two different areas (addresses) to store the upgrade configuration information of the target application and the upgrade configuration information of the BootLoader respectively during the upgrade processing process, which can prevent the upgrade configuration information of the target application from being changed by the BootLoader, or the upgrade configuration information of the BootLoader from being changed by the target application, thereby preventing data loss caused by cross-write operations, thereby improving the accuracy of target application upgrades in embedded systems.

[0043] Step 105: Set the watchdog function in the BootLoader and run the target application for testing.

[0044] Among them, watchdogs are divided into hardware watchdogs and software watchdogs. The hardware watchdog uses a timer circuit whose timing output is connected to the reset terminal of the circuit. The program clears the timer within a certain time range (commonly known as "feeding the dog"). Therefore, when the program works normally, the timer can never overflow and a reset signal can never be generated. If the program fails and the watchdog is not reset within the timing period, the watchdog timer overflows to generate a reset signal and restart the system. The principle of the software watchdog is the same, except that the timer on the hardware circuit is replaced by the internal timer of the processor, which can simplify the hardware circuit design.

[0045] For example, use the watchdog function in BootLoader, write the upgraded flag, upgrade time and other upgrade configuration information in the address corresponding to BootLoader (second area), set the PC pointer to jump to the starting address corresponding to the target application (APP program), and if the watchdog is not fed in time after the program jumps to APP (such as the program does not clear the timer within a certain time range), the embedded system will be restarted. This method can effectively test whether the upgraded target application can run correctly in the future. If the watchdog is not fed in time, it will be considered that there is an abnormal operation, and the embedded system will be restarted to try to debug the upgraded target application; if the watchdog can be fed in time, it means that the target application is running normally, and the monitoring of whether the watchdog is fed in time can be continued in the future.

[0046] Compared with the prior art, the upgrade processing method based on the embedded system provided in this embodiment can be timely discovered and processed if the embedded system runs abnormally after testing after the upgrade. In addition, during the upgrade process, two different areas (addresses) are used to store the upgrade configuration information of the target application and the upgrade configuration information of the BootLoader respectively, which can prevent the upgrade configuration information of the target application from being changed by the BootLoader, or the upgrade configuration information of the BootLoader from being changed by the target application, thereby preventing data loss caused by cross-write operations, thereby improving the accuracy of target application upgrades in embedded systems, and effectively improving the success rate of OTA. In addition, during the actual test, no situation where the system cannot work after the upgrade was found.

[0047] Further, as a refinement and extension of the specific implementation of the above embodiment, in order to fully illustrate the implementation of this embodiment, this embodiment also provides another upgrade processing method based on an embedded system, such as Figure 3 As shown, the method includes:

[0048] Step 201: Obtain firmware information to be upgraded of a target application in an embedded system.

[0049] Step 202: Verify the integrity and legality of the firmware information to be upgraded of the target application.

[0050] In this embodiment, after receiving the upgrade instruction, the APP program starts to download the firmware (APP) to be upgraded; after the download is completed, the integrity and legality of the firmware are determined, for example, by checking the hash value of the firmware.

[0051] Step 203a: If the firmware information to be upgraded is successfully verified, the upgrade configuration information of the target application is saved in the first area according to the firmware information to be upgraded.

[0052] Optionally, according to the firmware information to be upgraded, the upgrade configuration information of the target application is saved in the first area, specifically including: setting a mark that needs to be upgraded; then generating the upgrade configuration information of the target application according to the mark that needs to be upgraded and the firmware information to be upgraded and saving it in the first area.

[0053] For example, after the integrity and legality of the firmware are verified correctly, the upgrade configuration information such as the mark to be upgraded, the firmware version, size, and check value are set to be written into the address corresponding to the APP (ie, the first area).

[0054] Step 204a: restart the embedded system. After the BootLoader is executed, the original firmware information of the target application is overwritten with the firmware information to be upgraded according to the upgrade configuration information of the target application read.

[0055] Optionally, according to the read upgrade configuration information of the target application, the firmware information to be upgraded overwrites the original firmware information of the target application, which may specifically include: according to the mark to be upgraded, the firmware information to be upgraded overwrites the original firmware information of the target application.

[0056] For example, after the BootLoader program is executed, the upgrade configuration information of the APP is read (read-only); whether an upgrade is required is determined based on whether there is a mark that needs to be upgraded recorded in the first area (the address corresponding to the APP). If the mark that needs to be upgraded is recorded in the first area (the APP upgrade flag is set), it means that the APP needs to be upgraded, and the firmware information to be upgraded will overwrite the original firmware information of the target application; and if there is no mark that needs to be upgraded recorded in the first area (the APP upgrade flag is not set), it means that the APP does not need to be upgraded and there is no need to perform a firmware overwriting operation.

[0057] Step 205a: Generate BootLoader upgrade configuration information and save it in the second area.

[0058] Optionally, step 205a may specifically include: after the firmware information to be upgraded is successfully overwritten, generating upgrade configuration information of the BootLoader according to the upgraded mark and saving it in the second area.

[0059] For example, after the correct firmware is overwritten, the upgrade configuration information such as the upgraded mark, upgrade time, etc. is written to the address corresponding to the BootLoader (the second area); after completion, the PC pointer is set to jump to the starting address corresponding to the APP.

[0060] Step 206a: Set the watchdog function in the BootLoader and run the target application for testing.

[0061] Optionally, running the target application for testing may specifically include: if the target application runs correctly, canceling the mark of needing to be upgraded saved in the first area. For example, after the APP runs correctly, canceling the mark of needing to be upgraded at the address corresponding to the APP (first area) to avoid repeating the same upgrade process in the future.

[0062] To illustrate the specific test process, optionally, step 206a may specifically include: after running the target application, if the dog is not fed in time, restart the embedded system to run the target application again; if the dog is fed in time, it is determined that the target application is running correctly. For this embodiment, the watchdog function is used in the BootLoader. When the program jumps to the APP, if the dog is not fed in time, the embedded system will restart. In this way, it is effective to test whether the upgraded target application can run correctly later.

[0063] At present, the prior art does not identify the abnormality of the system restarting multiple times in a short period of time after the APP jumps successfully. In order to solve this problem, optionally, in step 204a, before the firmware information to be upgraded overwrites the original firmware information of the target application, the method of this embodiment may also include: backing up the original firmware information of the target application; accordingly, setting a watchdog function in the BootLoader, running the target application for testing, and specifically may also include: recording the number of restarts of the embedded system and the time of each restart; then judging whether the embedded system needs to be restored based on the recorded number of restarts and the time of each restart; if it is determined that the embedded system needs to be restored, the embedded system is restored based on the backed up original firmware information of the target application.

[0064] In this embodiment, the original firmware information of the target application can be backed up in advance before upgrading. The system is designed with a real-time clock (RTC) module, which can clearly determine the time difference between two system restarts and can be used to record the time of each restart of the embedded system.

[0065] The method of this embodiment counts the number of restarts and multiple restarts in a short period of time in BootLoader, and can identify abnormal restarts and restore the APP when necessary, that is, restore it to the state before the upgrade. The rules and standards for determining whether the embedded system needs to be restored can be set according to actual needs.

[0066] As an optional method, whether the embedded system needs to be restored is determined based on the number of times the embedded system is restarted and the time of each restart. Specifically, it may include: if the target application runs correctly, then based on the time of each restart, it is determined whether the total time of a historical preset number of consecutive restarts including the most recent restart is less than a preset duration threshold; if the total time is less than the preset duration threshold, it is determined that the embedded system needs to be restored, and the recorded number of times the embedded system is restarted and the time of each restart are cleared.

[0067] The preset number of times and preset duration thresholds can be pre-set according to actual needs. For example, although the APP has been running correctly and there is no mark that needs to be upgraded in the first area, the upgraded APP will restart if the watchdog function is not fed in time because the BootLoader has been pre-set. If the total time of the latest N times (pre-set number of times) of restart is less than n minutes (pre-set duration threshold), it means that the upgraded APP has been restarted multiple times in a short period of time and an abnormality has occurred. At this time, the APP needs to be restored using the original firmware (old firmware before the upgrade) backed up in advance by the APP to ensure the normal use of the APP.

[0068] As another optional method, whether the embedded system needs to be recovered is determined based on the number of times the embedded system is restarted and the time of each restart. Specifically, it may include: if the target application does not run correctly, then determining whether the number of times the embedded system is restarted is greater than a preset number threshold; if the number of restarts is greater than the preset number threshold, then determining that the embedded system needs to be recovered, and clearing the number of restarts and the time of each restart.

[0069] The preset times threshold can be pre-set according to actual needs. For example, if the APP does not run correctly, there is a mark in the first area that needs to be upgraded, and there is a mark in the second area corresponding to the BootLoader that has been upgraded, which means that the firmware has been overwritten, but the APP has not run correctly. Since the watchdog function is set in advance in the BootLoader, it will restart if the watchdog is not fed in time. If the number of restarts is greater than M times (the preset times threshold), and the APP still does not run correctly, it means that an abnormality has occurred. At this time, the APP needs to be restored using the original firmware (old firmware before the upgrade) backed up in advance by the APP to ensure the normal use of the APP.

[0070] In step 203b, which is parallel to step 203a, if the firmware information to be upgraded fails to be verified, the target application is refused to be upgraded.

[0071] For this embodiment, after determining that the firmware information to be upgraded of the APP has not passed the integrity and legality verification, the APP can be directly refused to be upgraded to avoid an invalid upgrade process, thereby saving system resource consumption.

[0072] In order to illustrate the specific implementation process of the above embodiments, the following application examples are given, but are not limited thereto:

[0073] In the embedded system, the following settings are made in advance: (a) Use the watchdog function in the BootLoader. If the watchdog is not fed in time after the program jumps to the APP, the system will restart; (b) The system is designed with an RTC module to clearly define the time difference between two restarts; (c) Store the upgrade configuration files of the APP and the BootLoader in two areas of the flash memory (internal or external) respectively;

[0074] (1) After receiving the upgrade instruction, the APP program starts downloading the firmware to be upgraded (APP).

[0075] (2) After the download is complete, the integrity and legality of the firmware are determined; if the determination is correct, the upgrade configuration information such as the flag to be upgraded, the firmware version, the firmware size, and the check value are written to the address corresponding to the APP, and then the reboot is set to enter the BootLoader.

[0076] (3) After the BootLoader program is executed, it reads (read-only) the upgrade configuration information of the APP; if it is determined that an upgrade is required, the new firmware is used to overwrite the original firmware; after the correct overwriting, the upgrade flag, upgrade time and other upgrade configuration information are written to the address corresponding to the BootLoader; after completion, the PC pointer is set to jump to the starting address corresponding to the APP.

[0077] (4) After the APP runs correctly, cancel the mark of the address corresponding to the APP that needs to be upgraded.

[0078] Based on the above configuration, if Figure 4 As shown, after the BootLoader program is executed, it is determined whether the upgrade mark recorded in the address corresponding to the APP is set (that is, whether there is a mark that needs to be upgraded. If the APP upgrade mark is set, it needs to be upgraded. If the APP upgrade mark is not set, it does not need to be upgraded). If the APP upgrade mark is not set, it can be determined whether the total time of the last 5 restarts is less than 2 minutes. If the total time is less than 2 minutes, it means that the upgraded APP has been restarted multiple times in a short period of time, and an abnormality has occurred. At this time, the APP needs to be restored, the backup firmware is restored, and the recorded number of embedded system restarts and the time of each restart are cleared, and the APP before the upgrade is jumped to run. If the total time is not less than 2 minutes, the RTC time at the time of this restart is recorded, and the upgraded APP is jumped to run.

[0079] If the APP upgrade mark is set, determine whether the BootLoader corresponding address records an upgraded mark. If there is no record of an upgraded mark, it means that the new firmware of the APP has not overwritten the old firmware (existing firmware). At this time, first back up the existing firmware, then upgrade it, and overwrite the old firmware with the new firmware of the APP. Set and write the corresponding records, including: setting the upgraded mark recorded at the corresponding address of the BootLoader, clearing the number of restarts of the BootLoader and the number of restart time records (clearing the number of restarts of the corresponding embedded system and the number of restart time records). Then record the RTC time at this restart. Jump to run the upgraded APP. If the BootLoader corresponding address records an upgraded mark, determine whether the number of restarts of the BootLoader is greater than 5 times. If the number of restarts of the BootLoader is greater than 5 times, it means that an abnormality has occurred. At this time, it is necessary to restore the APP, restore the backup firmware, and clear the number of restarts of the embedded system and the time of each restart, and jump to run the APP before the upgrade. If the number of restarts of the BootLoader is not greater than 5 times, then record the RTC time at this restart, and jump to run the upgraded APP.

[0080] The method of this embodiment uses two different addresses to store the upgrade configuration information of the APP and the upgrade configuration information of the BootLoader respectively, which can prevent the APP upgrade configuration information from being changed by the BootLoader or the BootLoader upgrade configuration information from being changed by the APP. Prevent data loss caused by cross-write operations. When the APP upgrade flag is not set, the RTC time of each restart is recorded, and the system is restored if it is judged that there are multiple restarts in a short period of time (set as needed). When the APP upgrade flag is set, the number of restarts is counted, and the system is restored if it is greater than a fixed number (set as needed). Through these two optional methods, the number of restarts and multiple restarts in a short period of time are counted in the BootLoader, so that abnormal restarts can be identified and the APP can be restored when necessary.

[0081] Further, as Figure 1 and Figure 3 The specific implementation of the method shown in the embodiment provides an upgrade processing device based on an embedded system, such as Figure 5 As shown, the device includes: an acquisition module 31, a storage module 32, an upgrade module 33, and a test module 34.

[0082] An acquisition module 31 is used to acquire firmware information to be upgraded of a target application in an embedded system;

[0083] A saving module 32, configured to save the upgrade configuration information of the target application in the first area according to the firmware information to be upgraded;

[0084] An upgrade module 33, used to restart the embedded system, and after the BootLoader is executed, overwrite the original firmware information of the target application with the firmware information to be upgraded according to the read upgrade configuration information of the target application;

[0085] The saving module 32 is further used to generate the upgrade configuration information of the BootLoader and save it in the second area, wherein the first area and the second area are different areas;

[0086] The test module 34 is used to set the watchdog function in the BootLoader and run the target application for testing.

[0087] In a specific application scenario, the saving module 32 is specifically used to set a mark that needs to be upgraded; based on the mark that needs to be upgraded and the firmware information to be upgraded, the upgrade configuration information of the target application is generated and saved in the first area;

[0088] The upgrade module 33 is specifically configured to overwrite the original firmware information of the target application with the firmware information to be upgraded according to the mark requiring upgrade;

[0089] The testing module 34 is specifically configured to cancel the mark requiring upgrading saved in the first area if the target application runs correctly.

[0090] In a specific application scenario, the saving module 32 is further configured to generate the upgrade configuration information of the BootLoader according to the upgraded mark and save it in the second area after the firmware information to be upgraded is successfully overwritten.

[0091] In a specific application scenario, the test module 34 is specifically used to restart the embedded system to run the target application again if the dog is not fed in time after running the target application; if the dog is fed in time, it is determined that the target application runs correctly.

[0092] In a specific application scenario, the device further includes: a backup module;

[0093] A backup module, used for backing up the original firmware information of the target application;

[0094] The test module 34 is specifically used to record the number of restarts of the embedded system and the time of each restart; based on the number of restarts and the time of each restart, determine whether the embedded system needs to be restored; if it is determined that the embedded system needs to be restored, restore the embedded system based on the backed-up original firmware information of the target application.

[0095] In a specific application scenario, the test module 34 is also specifically used to determine, if the target application runs correctly, whether the total time of the historical preset number of consecutive restarts including the latest restart is less than the preset duration threshold based on the time of each restart; if the total time is less than the preset duration threshold, it is determined that the embedded system needs to be restored, and the number of restarts and the time of each restart are cleared.

[0096] In a specific application scenario, the test module 34 is also specifically used to determine whether the number of restarts of the embedded system is greater than a preset number threshold if the target application does not run correctly; if the number of restarts is greater than the preset number threshold, it is determined that the embedded system needs to be restored, and the number of restarts and the time of each restart are cleared.

[0097] In a specific application scenario, the device further includes: a verification module;

[0098] A verification module, used to verify the integrity and legality of the firmware information to be upgraded; if the firmware information to be upgraded fails to be verified, the target application is refused to be upgraded;

[0099] The saving module 32 is further configured to save the upgrade configuration information of the target application in the first area according to the firmware information to be upgraded if the firmware information to be upgraded is successfully verified.

[0100] It should be noted that for other corresponding descriptions of the functional units involved in the upgrade processing device based on the embedded system provided in this embodiment, reference can be made to Figure 1 and Figure 3 The corresponding description in will not be repeated here.

[0101] Based on the above Figure 1 and Figure 3 The method shown in the embodiment also provides a storage medium on which a computer program is stored. When the program is executed by a processor, the above-mentioned Figure 1 and Figure 3 The upgrade processing method based on the embedded system is shown.

[0102] Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, USB flash drive, mobile hard disk, etc.), including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of the present application.

[0103] Based on the above Figure 1 and Figure 3 The method shown, and Figure 5 In order to achieve the above-mentioned purpose, the embodiment of the present application also provides an electronic device, which can be a personal computer, a smart cabinet, a food delivery treasure, a power control board, or other network equipment, etc. The device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-mentioned Figure 1 and Figure 3 The upgrade processing method based on the embedded system is shown.

[0104] Optionally, the above-mentioned physical device may also include a user interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a WI-FI module, etc. The user interface may include a display, an input unit such as a keyboard, etc., and the optional user interface may also include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (such as a WI-FI interface), etc.

[0105] Those skilled in the art will appreciate that the above-mentioned physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or a combination of certain components, or different arrangements of components.

[0106] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the above-mentioned physical device, and supports the operation of the information processing program and other software and / or programs. The network communication module is used to realize the communication between the components inside the storage medium, and the communication with other hardware and software in the information processing physical device.

[0107] Through the description of the above implementation methods, those skilled in the art can clearly understand that the present application can be implemented by means of software plus the necessary general hardware platform, or by hardware. By applying the technical solution of this embodiment, compared with the prior art, the solution of this embodiment can be timely discovered and processed if the embedded system runs abnormally after testing after the upgrade, and can be timely identified and restored when the upgrade abnormality occurs. And in the upgrade process, two different areas (addresses) are used to store the upgrade configuration information of the target application and the upgrade configuration information of the BootLoader respectively, which can avoid the upgrade configuration information of the target application being changed by the BootLoader, or the upgrade configuration information of the BootLoader being changed by the target application, thereby preventing the cross-write operation from causing data loss, thereby improving the accuracy of the target application upgrade in the embedded system.

[0108] Those skilled in the art will appreciate that the accompanying drawings are only schematic diagrams of a preferred implementation scenario, and the modules or processes in the accompanying drawings are not necessarily necessary for implementing the present application. Those skilled in the art will appreciate that the modules in the devices in the implementation scenario can be distributed in the devices of the implementation scenario according to the description of the implementation scenario, or can be changed accordingly and located in one or more devices different from the present implementation scenario. The modules of the above-mentioned implementation scenario can be combined into one module, or can be further split into multiple submodules.

[0109] The above serial numbers of this application are only for description and do not represent the advantages and disadvantages of the implementation scenarios. The above disclosure is only a few specific implementation scenarios of this application, but this application is not limited to them, and any changes that can be thought of by technicians in this field should fall within the scope of protection of this application.

Claims

1. An upgrade processing method based on an embedded system, characterized in that: include: Obtain the firmware information to be upgraded of the target application in the embedded system; According to the firmware information to be upgraded, the upgrade configuration information of the target application is saved in the first area; Restarting the embedded system, after the BootLoader is executed, overwriting the original firmware information of the target application with the firmware information to be upgraded according to the read upgrade configuration information of the target application; Generate BootLoader upgrade configuration information and save it in a second area, wherein the first area and the second area are different areas; Set the watchdog function in BootLoader and run the target application for testing; If the target application runs correctly, then judging whether the total time of the historical preset number of consecutive restarts including the latest restart is less than the preset time threshold according to the time of each restart; If the total time is less than the preset time threshold, it is determined that the embedded system needs to be restored, and the number of restarts and the time of each restart are cleared.

2. The method according to claim 1, characterized in that The step of storing the upgrade configuration information of the target application in the first area according to the firmware information to be upgraded specifically includes: Set the flag that needs to be upgraded; Generate upgrade configuration information of the target application according to the mark requiring upgrade and the firmware information to be upgraded and save the information in the first area; The step of overwriting the original firmware information of the target application with the firmware information to be upgraded according to the read upgrade configuration information of the target application specifically includes: According to the mark requiring upgrading, overwriting the original firmware information of the target application with the firmware information to be upgraded; The running of the target application for testing specifically includes: If the target application runs correctly, the mark requiring upgrading saved in the first area is cancelled.

3. The method according to claim 1, characterized in that The generating of the upgrade configuration information of the BootLoader and storing it in the second area specifically includes: After the firmware information to be upgraded is successfully overwritten, the upgrade configuration information of the BootLoader is generated according to the upgraded mark and saved in the second area.

4. The method according to claim 1, characterized in that The step of setting the watchdog function in the BootLoader and running the target application for testing specifically includes: After running the target application, if the dog is not fed in time, restarting the embedded system to run the target application again; If the dog is fed in time, it is determined that the target application is running correctly.

5. The method according to claim 4, characterized in that Before overwriting the original firmware information of the target application with the firmware information to be upgraded, the method further includes: Backing up the original firmware information of the target application; The step of setting a watchdog function in the BootLoader and running the target application for testing specifically includes: Recording the number of restarts of the embedded system and the time of each restart; Determining whether recovery processing needs to be performed on the embedded system according to the number of restarts and the time of each restart; If it is determined that the embedded system needs to be restored, the embedded system is restored according to the backed-up original firmware information of the target application.

6. The method according to claim 5, characterized in that The determining, according to the number of restarts and the time of each restart, whether it is necessary to perform recovery processing on the embedded system specifically includes: If the target application does not run correctly, determining whether the number of restarts of the embedded system is greater than a preset number threshold; If the restart times are greater than the preset times threshold, it is determined that the embedded system needs to be restored, and the restart times and the time of each restart are cleared.

7. The method according to claim 1, characterized in that Before saving the upgrade configuration information of the target application in the first area according to the firmware information to be upgraded, the method further includes: Verifying the integrity and legality of the firmware information to be upgraded; If the firmware information to be upgraded fails to be verified, refusing to upgrade the target application; The step of storing the upgrade configuration information of the target application in the first area according to the firmware information to be upgraded specifically includes: If the firmware information to be upgraded is successfully verified, the upgrade configuration information of the target application is saved in the first area according to the firmware information to be upgraded.

8. An upgrade processing device based on an embedded system, characterized in that: include: An acquisition module, used to acquire firmware information to be upgraded of a target application in an embedded system; A saving module, configured to save the upgrade configuration information of the target application in the first area according to the firmware information to be upgraded; An upgrade module, used for restarting the embedded system, and after the BootLoader is executed, overwriting the original firmware information of the target application with the firmware information to be upgraded according to the upgrade configuration information of the target application read; The saving module is further used to generate upgrade configuration information of the BootLoader and save it in a second area, wherein the first area and the second area are different areas; A test module, used to set a watchdog function in the BootLoader and run the target application for testing; The test module is specifically used to determine whether the total time of a preset number of consecutive restarts in history, including the most recent restart, is less than a preset duration threshold based on the time of each restart if the target application runs correctly; if the total time is less than the preset duration threshold, it is determined that the embedded system needs to be restored, and the number of restarts and the time of each restart are cleared.

9. An electronic device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

Images