Program upgrade method and program upgrade device
By dividing the memory into two levels of independent storage areas for the bootloader and the application program, and using the application program to perform the upgrade process for the bootloader program, the problem of poor stability in bootloader program upgrades is solved, ensuring stable operation and upgrades of the program.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HOYMILES POWER ELECTRONICS INC
- Filing Date
- 2026-04-23
- Publication Date
- 2026-05-26
Smart Images

Figure CN122086445A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and in particular to a program upgrade method and a program upgrade device. Background Technology
[0002] The firmware of a micro-reverse device includes a bootloader and an application program (APP). The bootloader has many functions such as initialization, self-test, jump, communication, and APP upgrade. When there are technical updates or fault repairs, the bootloader needs to be upgraded via OTA (over-the-air).
[0003] In related technologies, when a bootloader program undergoes an OTA upgrade, it involves erasing and rewriting the boot address of the memory. The boot information (i.e., the codestart value) at this boot address is crucial for program jumps. If an abnormal scenario such as a power outage occurs during the erasure and rewrite process, the bootloader program will fail to run normally and upgrade. Therefore, it is evident that existing bootloader program upgrade methods suffer from poor program upgrade stability. Summary of the Invention
[0004] This disclosure provides a program upgrade method and a program upgrade apparatus, which can improve the upgrade stability of the bootloader program.
[0005] In a first aspect, this disclosure provides a program upgrade method, which includes: verifying a second bootloader according to a first bootloader; if the verification passes, performing a program jump to run the second bootloader; the first bootloader is located in a first storage area of a memory, and the starting address of the first storage area is a preset startup address; the second bootloader is located in a second storage area of the memory; verifying an application according to the second bootloader; if the verification passes, performing a program jump to run the application; the application is located in a third storage area of the memory; and during the operation of the application, upon receiving a bootloader upgrade instruction, performing an upgrade process on the second bootloader according to the application.
[0006] In one optional implementation, the bootloader upgrade instruction includes first upgrade information corresponding to the second bootloader, and the upgrade process of the second bootloader according to the application includes: determining the erase region of the memory from the first upgrade information according to the application, matching the erase region with the second memory region to obtain a first matching result; if the first matching result is a successful match, the application erases the erase region and writes the bootloader upgrade program from the first upgrade information into the erase region to obtain the upgraded second bootloader.
[0007] In one optional implementation, before determining the erase region of the memory from the first upgrade information based on the application, the method further includes: determining first version information corresponding to the bootloader upgrade program from the first upgrade information based on the application; matching the first version information with first preset version information to obtain a second matching result; and performing the step of determining the erase region of the memory from the first upgrade information based on the application if the second matching result is a successful match.
[0008] In one optional implementation, after writing the bootloader upgrade program from the first upgrade information into the erase area to obtain the upgraded second bootloader, the method further includes: verifying the upgraded second bootloader according to the application, and determining that the second bootloader upgrade is successful if the verification passes.
[0009] In an optional implementation, the method further includes: during the operation of the application, upon receiving an application upgrade instruction, performing a program soft reset to run the first bootloader; re-verifying the second bootloader according to the first bootloader, and if the verification passes, performing a program jump to run the second bootloader; and upgrading the application according to the second bootloader.
[0010] In one optional implementation, the application upgrade instruction includes second upgrade information corresponding to the application. The step of performing a program soft reset to run the first bootloader upon receiving the application upgrade instruction includes: upon receiving the application upgrade instruction, determining second version information corresponding to the application upgrade program from the second upgrade information based on the application; matching the second version information with second preset version information to obtain a third matching result; and performing a program soft reset to run the first bootloader if the third matching result is a successful match.
[0011] In one optional implementation, after verifying the application according to the second bootloader, the method further includes: keeping the second bootloader running if the application fails verification by the second bootloader; and upgrading the application according to the second bootloader when an application upgrade instruction is received during the operation of the second bootloader.
[0012] In one optional implementation, after upgrading the application according to the second bootloader, the method further includes: verifying the upgraded application according to the second bootloader; if the verification passes, determining that the application has been successfully upgraded; and performing a program jump according to the second bootloader to run the upgraded application.
[0013] In one optional implementation, after verifying the second bootloader according to the first bootloader, the method further includes: if the first bootloader fails to verify the second bootloader, verifying the application according to the first bootloader; if the first bootloader passes the verification of the application, performing a program jump according to the first bootloader to run the application.
[0014] Secondly, this disclosure provides a program upgrade device, comprising: a first running module, configured to verify a second bootloader according to a first bootloader, and, if the verification passes, perform a program jump to run the second bootloader; the first bootloader is located in a first storage area of a memory, the starting address of the first storage area being a preset startup address; the second bootloader is located in a second storage area of the memory; a second running module, configured to verify an application according to the second bootloader, and, if the verification passes, perform a program jump to run the application; the application is located in a third storage area of the memory; and a program upgrade module, configured to, during the operation of the application, upon receiving a bootloader upgrade instruction, perform an upgrade process on the second bootloader according to the application.
[0015] The program upgrade method provided in this embodiment firstly verifies a second bootloader based on a first bootloader. If the verification passes, a program jump is performed to run the second bootloader. The first bootloader is located in a first storage area of the memory, and the starting address of the first storage area is a preset startup address. The second bootloader is located in a second storage area of the memory. Secondly, the application is verified based on the second bootloader. If the verification passes, a program jump is performed to run the application. The application is located in a third storage area of the memory. Finally, during the operation of the application, upon receiving a bootloader upgrade instruction, the second bootloader is upgraded according to the application.
[0016] Therefore, this embodiment of the present disclosure can divide the memory into two independent storage areas for the bootloader and the application program. After the application program is launched, when upgrading the bootloader program, the application program is responsible for upgrading the second bootloader, and the first bootloader will not be upgraded. Since the starting address of the storage area of the first bootloader is the preset startup address, the startup information (i.e., the codestart value) at the preset startup address will not be erased or overwritten during the upgrade process of the bootloader, thereby ensuring the stability of the bootloader upgrade.
[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description
[0018] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:
[0019] Figure 1 A flowchart of a program upgrade method provided in this embodiment of the disclosure;
[0020] Figure 2 This is a schematic diagram illustrating the program storage space partitioning in an embodiment of this disclosure;
[0021] Figure 3 This is a schematic diagram illustrating the process of an application upgrading a bootloader in an embodiment of this disclosure;
[0022] Figure 4 This is a schematic diagram illustrating the process of application upgrade by the second bootloader in an embodiment of this disclosure;
[0023] Figure 5 This is a flowchart illustrating the program jump in the embodiments of this disclosure;
[0024] Figure 6 A block diagram of a program upgrade device provided in an embodiment of this disclosure;
[0025] Figure 7 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation
[0026] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.
[0027] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.
[0028] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.
[0029] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.
[0030] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.
[0031] The firmware of a micro refurbished device includes a bootloader and an application program (APP). The bootloader is the starting point for program execution; if the bootloader malfunctions, the entire software will fail to run properly. In practical applications, the bootloader can be flashed via a physical interface after disassembly, but this will affect the micro refurbished device's airtightness, waterproofing, and other properties, impacting subsequent use.
[0032] Accordingly, after a micro-reversal device leaves the factory, updating the bootloader program without disassembling the device requires over-the-air (OTA) technology. OTA is a technology that allows for remote management, configuration updates, or software upgrades of devices via wireless communication. OTA can update device firmware, system, applications, etc., without requiring a physical interface.
[0033] In related technologies, when a bootloader program undergoes an OTA upgrade, it involves erasing and rewriting the boot address of the memory. The boot information (i.e., the codestart value) at this boot address is crucial for program jumps. If an abnormal scenario such as a power outage occurs during the erasure and rewrite process, the bootloader program will fail to run normally and upgrade. Therefore, it is evident that existing bootloader program upgrade methods suffer from poor program upgrade stability.
[0034] In view of the above, embodiments of this disclosure provide a program upgrade method and a program upgrade apparatus. The program upgrade method provided by embodiments of this disclosure firstly verifies a second bootloader based on a first bootloader. If the verification passes, a program jump is performed to run the second bootloader. The first bootloader is located in a first storage area of the memory, and the starting address of the first storage area is a preset startup address. The second bootloader is located in a second storage area of the memory. Secondly, the application is verified based on the second bootloader. If the verification passes, a program jump is performed to run the application. The application is located in a third storage area of the memory. Finally, during the operation of the application, upon receiving a bootloader upgrade instruction, the second bootloader is upgraded according to the application.
[0035] Therefore, this embodiment of the present disclosure can divide the memory into two independent storage areas for the bootloader and the application program. After the application program is launched, when upgrading the bootloader program, the application program is responsible for upgrading the second bootloader, and the first bootloader will not be upgraded. Since the starting address of the storage area of the first bootloader is the preset startup address, the startup information (i.e., the codestart value) at the preset startup address will not be erased or overwritten during the upgrade process of the bootloader, thereby ensuring the stability of the bootloader upgrade.
[0036] Figure 1 A flowchart illustrating a program upgrade method provided in an embodiment of this disclosure. (Refer to...) Figure 1 The method includes:
[0037] Step S110: Verify the second bootloader according to the first bootloader. If the verification passes, perform a program jump to run the second bootloader. The first bootloader is located in the first storage area of the memory, and the starting address of the first storage area is the preset startup address. The second bootloader is located in the second storage area of the memory.
[0038] The memory can be flash memory within the chip, and this disclosure does not limit this. The memory includes a first bootloader, a second bootloader, and a separate storage area for the application program.
[0039] The preset boot address refers to the address in memory corresponding to the storage space where boot information (i.e., the codestart value) is stored. For example, for some chips, address 0x00080000 in the Flash memory is the preset boot address. The codestart value at this address is used for program jumps after the chip powers on. If the codestart value at the preset boot address is abnormally erased, the program startup after the chip powers on will be abnormal, making it impossible to perform upgrade processing of the bootloader.
[0040] Accordingly, in this embodiment of the disclosure, the preset boot address is used as the starting address of the first storage area, thereby allocating storage space in the memory for the first bootloader.
[0041] In this embodiment, the bootloader can be divided into a first bootloader and a second bootloader. The first bootloader is used for program verification and program redirection, and is not used to update the second bootloader. Since the first bootloader only involves simple functional logic, during the R&D testing phase, after verifying that the first bootloader has no abnormal logic, it can remain in a fixed state without requiring program upgrades. Accordingly, after the device leaves the factory, the first bootloader can remain in a fixed state without requiring OTA upgrades.
[0042] In this embodiment, the second bootloader includes the functional logic of a traditional bootloader program. For example, the second bootloader is used for communication interaction, online application upgrades, program verification, and program navigation. Accordingly, the second bootloader can be stored in the second storage area of the memory.
[0043] The memory also includes a third storage area for storing application programs. It should be noted that this embodiment does not impose specific restrictions on the order of the second and third storage areas; for example, the second storage area can be located before or after the third storage area. Furthermore, this embodiment does not impose specific restrictions on the size of the first, second, and third storage areas, as long as they meet the storage requirements of the bootloader and application programs.
[0044] For example, Figure 2 This diagram illustrates the program storage space partitioning in an embodiment of the present disclosure. (Refer to...) Figure 2The memory area corresponding to the address range 0x80000-0x81000 is the first memory area, which stores the first bootloader, i.e., the Boot1 program. The content stored at address 0x80000 is the codestart value, used for program jumps. The memory area corresponding to the address range 0x81000-0x84FFF is the second memory area, which stores the second bootloader, i.e., the Boot2 program. The memory area after address 0x85000 is the third memory area, which stores the application program, i.e., the APP program.
[0045] In this step, verifying the second bootloader according to the first bootloader means that the first bootloader checks whether the second bootloader has any errors. It should be noted that this embodiment does not impose specific limitations on the method of program verification. For example, program verification can employ program integrity checks such as Cyclic Redundancy Check (CRC), parity check, hash check, Hamming code check, etc. For instance, the first bootloader calculates the CRC check value of the second bootloader; if the check value is correct, the program verification passes.
[0046] Correspondingly, if the first bootloader passes the verification of the second bootloader, the first bootloader can perform a program jump, for example, by setting the program counter to the entry address of the second bootloader, thereby fetching instructions from that entry address and switching the currently running program from the first bootloader to the second bootloader.
[0047] Step S120: The application is verified according to the second bootloader. If the verification is successful, the program jumps to run the application. The application is located in the third storage area of the memory.
[0048] The verification of the application by the second bootloader refers to the second bootloader checking whether the application has errors. It should be noted that this embodiment does not impose specific limitations on the method of program verification. For example, program verification can employ methods such as CRC checksum verification, parity check, hash checksum verification, and Hamming code checksum verification. For instance, the second bootloader calculates the CRC checksum value of the application; if the checksum value is correct, the program verification passes.
[0049] Correspondingly, if the application passes the verification by the second bootloader, the second bootloader can perform a program jump, for example, by setting the program counter to the entry address of the application, thereby fetching instructions from that entry address and switching the currently running program from the second bootloader to the application.
[0050] Step S130: During the operation of the application, upon receiving a bootloader upgrade instruction, the second bootloader is upgraded according to the application.
[0051] The bootloader upgrade instruction may include upgrade information corresponding to the second bootloader, such as version information, the second bootloader upgrade program, and erase area information. This embodiment does not limit this.
[0052] During application runtime, the bootloader upgrade command can be sent to the application from the superior communication module. Upon receiving the bootloader upgrade command, the application can then upgrade the second bootloader accordingly.
[0053] This disclosure provides a program upgrade method and apparatus. First, a second bootloader is verified based on a first bootloader. If the verification passes, a program jump is performed to run the second bootloader. The first bootloader is located in a first storage area of the memory, and the starting address of the first storage area is a preset startup address. The second bootloader is located in a second storage area of the memory. Second, an application is verified based on the second bootloader. If the verification passes, a program jump is performed to run the application. The application is located in a third storage area of the memory. Finally, during the operation of the application, upon receiving a bootloader upgrade instruction, the second bootloader is upgraded according to the application.
[0054] Therefore, this embodiment of the present disclosure can divide the memory into two independent storage areas for the bootloader and the application program. After the application program is launched, when upgrading the bootloader program, the application program is responsible for upgrading the second bootloader, and the first bootloader will not be upgraded. Since the starting address of the storage area of the first bootloader is the preset startup address, the startup information (i.e., the codestart value) at the preset startup address will not be erased or overwritten during the upgrade process of the bootloader, thereby ensuring the stability of the bootloader upgrade.
[0055] In one optional implementation, the bootloader upgrade instruction includes first upgrade information corresponding to the second bootloader. Upgrading the second bootloader according to the application includes: determining an erase region of the memory from the first upgrade information according to the application; matching the erase region with the second memory area to obtain a first matching result; if the first matching result is successful, the application erases the erase region and writes the bootloader upgrade program from the first upgrade information into the erase region to obtain the upgraded second bootloader.
[0056] The first upgrade information corresponding to the second bootloader may include the bootloader upgrade program, version information, erase area information, etc.
[0057] For example, the erase region information may include the erase start address and erase length. Thus, before upgrading the second bootloader, the application can determine the erase region of the memory. For instance, based on the erase start address and erase length, the address range corresponding to the erase region can be determined. Therefore, by comparing the address range corresponding to the erase region with the address range corresponding to the second memory area, it can be determined whether the erase region and the second memory area match.
[0058] Accordingly, if the first matching result is successful, it indicates that the memory's erase area verification is correct, meaning that the first and third memory areas will not be accidentally erased. In this case, the application program erases the memory's erase area and writes the bootloader upgrade program from the first upgrade information into the erased erase area.
[0059] The bootloader upgrade program can be written in segments. For example, the application writes each segment of the bootloader upgrade program sequentially to its corresponding storage area.
[0060] Before writing each segment of the bootloader upgrade program, that is, before writing the bootloader upgrade program from the first upgrade information to the erase area, the application can verify the bootloader upgrade program. If the verification passes, the writing process can then proceed. For example, the application can verify whether there are any errors in the bootloader upgrade program using methods such as program integrity CRC check, parity check, and hash check.
[0061] For example, if a segment of the bootloader upgrade program received by the application fails verification due to communication abnormalities or other reasons, that segment of the bootloader upgrade program is discarded, and the data is resent. Once the last line of the bootloader upgrade program is successfully burned, it indicates that the bootloader upgrade program has been written, and the upgraded second bootloader program is obtained.
[0062] If the first matching result fails, it indicates that the memory erase area verification has failed. At this time, the application can end the upgrade process of the second bootloader and report the error information.
[0063] In this embodiment of the disclosure, when the application upgrades the second bootloader, it first checks whether the erase area of the memory matches the second storage area where the second bootloader is located. If they match, the application then performs data erasure and upgrade program writing to avoid program failure due to erasing abnormal areas.
[0064] In one alternative implementation, before determining the erase region of the memory from the first upgrade information according to the application, the method further includes: determining, according to the application, a first version information corresponding to the bootloader upgrade program from the first upgrade information; matching the first version information with first preset version information to obtain a second matching result; and if the second matching result is a successful match, performing the step of determining the erase region of the memory from the first upgrade information according to the application.
[0065] The first upgrade information includes the first version information. The first version information is used to identify the version number corresponding to the bootloader upgrade program.
[0066] The first preset version information is used to determine whether there are any version anomalies, such as version rollback, thereby avoiding abnormal upgrades to the bootloader. It should be noted that this embodiment does not impose specific limitations on the composition of the first preset version information.
[0067] For example, the first preset version information may include a preset lower limit value for the version number of the bootloader. This preset lower limit value can be dynamically set following the upgrade process of the bootloader, and this embodiment of the present disclosure does not impose any restrictions on it. Accordingly, only when the first version information is greater than the preset lower limit value is the second matching result determined to be a successful match. In this case, it indicates that the application has passed the verification of the first version information, and thus the application can proceed with the upgrade process of the second bootloader.
[0068] For example, the first preset version information may include a preset range of the version number of the bootloader. This preset range can be dynamically set as the bootloader upgrades, and this embodiment does not impose any limitations on this. Accordingly, the second matching result is determined to be a successful match only if the first version information falls within the preset range. In this case, it indicates that the application has passed the verification of the first version information, and the application can proceed with the upgrade process of the second bootloader.
[0069] If the second matching result between the first version information and the first preset version information fails, it indicates that the application has failed to verify the first version information. At this time, the application can end the upgrade process of the second bootloader and report the error information.
[0070] In this embodiment of the disclosure, before the application detects whether the erase area matches the second storage area where the second bootloader is located, it first checks whether the version information of the bootloader upgrade program is correct. If it is correct, the erase area detection is then performed, thereby avoiding the situation where the second bootloader upgrade is abnormal due to the abnormality of the bootloader upgrade program.
[0071] In one optional implementation, after writing the bootloader upgrade program from the first upgrade information into the erase area to obtain the upgraded second bootloader, the method further includes: verifying the upgraded second bootloader according to the application, and determining that the second bootloader upgrade is successful if the verification passes.
[0072] The application's verification of the upgraded second bootloader refers to the application checking whether the upgraded second bootloader contains errors. For example, program verification can employ methods such as CRC checksum, parity check, hash checksum, and Hamming code checksum. For instance, the application calculates the CRC checksum of the upgraded second bootloader; if the checksum is correct, the program verification passes.
[0073] Accordingly, if the application verifies the upgraded second bootloader, it can update the version information of the upgraded second bootloader and confirm that the second bootloader upgrade was successful.
[0074] In this embodiment of the disclosure, after the application has finished writing the bootloader upgrade program, it will verify whether the upgraded second bootloader is correct. If the verification passes, the version information of the second bootloader will be updated to confirm that the second bootloader has been successfully upgraded, thereby avoiding the possibility of program errors in the successfully upgraded second bootloader.
[0075] For ease of understanding, Figure 3 This illustration shows a flowchart of an application upgrading a bootloader in an embodiment of this disclosure, with reference to... Figure 3 The bootloader upgrade includes the following steps:
[0076] Step S301: During the operation of the application, receive the bootloader upgrade instruction.
[0077] The bootloader upgrade instruction includes the first upgrade information corresponding to the second bootloader.
[0078] Step S302: Match the first version information corresponding to the bootloader upgrade program with the first preset version information according to the application to obtain a second matching result. If the second matching result is a successful match, proceed to step S303. If the second matching result is a failed match, proceed to step S310.
[0079] Step S303: Based on the first upgrade information corresponding to the second bootloader obtained by the application, determine the erase region of the memory, match the erase region with the second memory area, and obtain a first matching result. If the first matching result is successful, proceed to step S304. If the first matching result is unsuccessful, proceed to step S310.
[0080] Step S304: Perform the erasure process on the erasure area according to the application.
[0081] Step S305: Based on the application's verification of the received current segment bootloader upgrade program, determine whether the verification passes. If the verification passes, proceed to step S306. If the verification fails, proceed to step S311.
[0082] Step S306: Write the current segment bootloader upgrade program to the corresponding storage area in the erase area according to the application.
[0083] Step S307: Determine whether the last bootloader upgrade program has been written completely based on the application. If the writing is complete, proceed to step S308; otherwise, return to step S305.
[0084] Step S308: Determine whether the verification passes based on the second bootloader after the application verification upgrade process. If the verification passes, proceed to step S309. If the verification fails, proceed to step S310.
[0085] Step S309: Based on the application, update the version information of the upgraded second bootloader and confirm that the second bootloader upgrade was successful.
[0086] Step S310: Based on the application, determine that the second bootloader upgrade failed and report the error message.
[0087] Step S311: Based on the error message reported by the application, wait for the data to be resent.
[0088] In one alternative implementation, the application can also be upgraded by a second bootloader.
[0089] Accordingly, the above-mentioned program upgrade method also includes: during the operation of the application, upon receiving an application upgrade instruction, performing a program soft reset to run a first bootloader; re-verifying the second bootloader according to the first bootloader, and if the verification passes, performing a program jump to run the second bootloader; and upgrading the application according to the second bootloader.
[0090] The application upgrade instruction may include second upgrade information corresponding to the application, such as version information, application upgrade program, and erase area information, etc., which are not limited in this embodiment.
[0091] During application runtime, application upgrade commands can be sent from the upper-level communication module to the application. Upon receiving the upgrade command, the application needs to perform a software reset, for example, by calling the software reset interface to trigger the software watchdog timeout mechanism, causing the program to reset and switching the currently running program from the application to the first bootloader.
[0092] The first bootloader re-verifies the second bootloader, using methods such as CRC checksum, parity check, and hash checksum. If the verification passes, a program jump occurs, switching the currently running program from the first bootloader to the second bootloader. If the verification fails, it indicates that the second bootloader cannot upgrade the application, and a program jump occurs to run the application. In other words, the currently running program switches from the first bootloader to the application. In this case, the application upgrade fails. The second bootloader can be upgraded first to restore the ability to upgrade the application after its upgrade is complete.
[0093] During the execution of the second bootloader, applications can be upgraded according to the second bootloader. The specific process for application upgrades can refer to the second bootloader upgrade process described above, and will not be repeated here.
[0094] In this embodiment of the disclosure, when the application is running, if an application upgrade instruction is received, a soft reset is first performed, and the application enters the first bootloader. Then, the first bootloader re-verifies the second bootloader. If the verification passes, the application enters the second bootloader to upgrade the application.
[0095] In one optional implementation, the application upgrade instruction includes second upgrade information corresponding to the application. Upon receiving the application upgrade instruction, a program soft reset is performed to run the first bootloader, including: upon receiving the application upgrade instruction, determining second version information corresponding to the application upgrade program from the second upgrade information based on the application; matching the second version information with second preset version information to obtain a third matching result; and if the third matching result is a successful match, performing a program soft reset to run the first bootloader.
[0096] The second upgrade information includes second version information. This second version information is used to identify the version number corresponding to the application upgrade program.
[0097] The second preset version information is used to determine whether there are any version anomalies, such as version rollback, thereby avoiding abnormal upgrades to the application. It should be noted that this embodiment does not impose specific limitations on the composition of the second preset version information.
[0098] For example, the second preset version information may include a preset lower limit value for the application's version number. This preset lower limit value can be dynamically set following the application's upgrade process, and this embodiment of the disclosure does not impose any restrictions on it. Accordingly, only when the second version information is greater than the preset lower limit value is the third matching result determined to be a successful match. In this case, it indicates that the application has passed the verification of the second version information, and thus the application can perform a software reset.
[0099] For example, the second preset version information may include a preset range of the application's version number. This preset range can be dynamically set as the application upgrades, and this embodiment does not impose any limitations on this. Accordingly, only when the second version information falls within this preset range is the third matching result determined to be a successful match. In this case, it indicates that the application has passed the verification of the second version information, and the application can then perform a software reset.
[0100] If the third matching result between the second version information and the second preset version information fails, it indicates that the application failed to verify the second version information. At this point, the application upgrade process can be terminated, and the application upgrade is confirmed to have failed.
[0101] In this embodiment of the disclosure, if an application upgrade instruction is received during application runtime, a soft reset is performed after verifying that the version information of the application upgrade program is correct, in order to avoid abnormal upgrades to the application.
[0102] In one alternative implementation, after upgrading the application according to the second bootloader, the method further includes: verifying the upgraded application according to the second bootloader; if the verification passes, determining that the application upgrade is successful; and performing a program jump according to the second bootloader to run the upgraded application.
[0103] After the second bootloader completes the application upgrade, it can verify the upgraded application.
[0104] The verification of the upgraded application by the second bootloader refers to the second bootloader verifying whether the upgraded application has errors. It should be noted that this embodiment does not impose specific limitations on the method of program verification. For example, program verification can employ methods such as CRC check for program integrity, parity check, hash check, and Hamming code check.
[0105] If the second bootloader fails to verify the upgraded application, the application upgrade is deemed to have failed. In this case, you can wait in the second bootloader for the application to be upgraded again.
[0106] If the second bootloader verifies the upgraded application, the application upgrade is considered successful. The second bootloader can then switch the running application from the current application to the upgraded one.
[0107] In this embodiment of the disclosure, when the second bootloader upgrades the application, after the application upgrade program is written, the second bootloader verifies the upgraded application. If the verification passes, the application upgrade is successful, and the second bootloader jumps to the upgraded application so that the upgraded functions can be executed normally.
[0108] For ease of understanding, Figure 4 This illustration shows a flowchart of the application upgrade process performed by the second bootloader in an embodiment of this disclosure. (Refer to...) Figure 4 Application upgrades include the following steps:
[0109] Step S401: During the operation of the application, receive the application upgrade instruction.
[0110] The application upgrade instruction includes the second upgrade information corresponding to the application.
[0111] Step S402: Based on the application, match the second version information corresponding to the application with the second preset version information to obtain a third matching result. If the third matching result is a successful match, proceed to step S403. If the third matching result is a failed match, proceed to step S410.
[0112] Step S403: Based on the application, perform a program soft reset to run the first bootloader.
[0113] Step S404: Re-verify the second bootloader based on the first bootloader to determine if the verification passes. If the verification passes, proceed to step S405. If the verification fails, proceed to step S409.
[0114] Step S405: According to the first bootloader, perform a program jump to run the second bootloader.
[0115] Step S406: Upgrade the application according to the second bootloader.
[0116] Step S407: Verify the upgraded application according to the second bootloader to determine whether the verification passes. If the verification passes, proceed to step S408; if the verification fails, proceed to step S410.
[0117] Step S408: Confirm that the application upgrade was successful, and proceed with the program jump according to the second bootloader to run the upgraded application.
[0118] Step S409: According to the first bootloader, perform a program jump to run the application.
[0119] Step S410: Determine if the application upgrade failed.
[0120] In one alternative implementation, after the application is verified by the second bootloader, the method further includes: if the application verification by the second bootloader fails, keeping the second bootloader running; and during the operation of the second bootloader, if an application upgrade instruction is received, upgrading the application according to the second bootloader.
[0121] If the application fails verification by the second bootloader, it indicates that the application cannot function properly. Therefore, the current running application can remain the second bootloader, and the application can be upgraded according to the second bootloader.
[0122] Accordingly, during the execution of the second bootloader, application upgrade instructions can be sent from the upper-level communication module to the second bootloader. Upon receiving the application upgrade instruction, the second bootloader can then upgrade the application according to the instruction. After the application upgrade is complete, the second bootloader can jump to the upgraded application for execution.
[0123] In this embodiment of the disclosure, if the application malfunctions, the second bootloader waits for the application upgrade instruction and performs the application upgrade process so that the upgraded application can run normally.
[0124] In one alternative implementation, after verifying the second bootloader according to the first bootloader, the method further includes: if the first bootloader fails to verify the second bootloader, verifying the application according to the first bootloader; if the first bootloader passes the verification of the application, performing a program jump according to the first bootloader to run the application.
[0125] If the first bootloader fails to verify the second bootloader, it indicates that the second bootloader cannot run normally. In this case, the first bootloader can continue to verify the application. This verification can employ methods such as CRC checksum, parity check, hash check, and Hamming code check, and this embodiment does not impose any limitations on these methods. If the verification passes, the program jumps, switching the currently running program from the first bootloader to the application, thereby ensuring the normal execution of the application functions.
[0126] Furthermore, during the application's operation, it can wait for the second bootloader to be upgraded. If the application receives a bootloader upgrade instruction, it can upgrade the second bootloader according to the instruction, thereby restoring the second bootloader to normal operation.
[0127] In other words, in this embodiment, the first bootloader only performs program verification and program redirection. Its logic is simple, its operation is stable, it occupies little space, and it does not undergo online upgrades, thus protecting the codestart value from being overwritten. The second bootloader can be used to perform OTA upgrades on the application, and it can also be used for application verification and application redirection. The application can be used to perform OTA upgrades on the second bootloader, and it can execute all application functions.
[0128] Therefore, in this embodiment of the disclosure, when the second bootloader malfunctions, the system can jump from the first bootloader to the application, enabling both normal application execution and OTA (Over-The-Air) upgrades of the second bootloader based on the application. When the application malfunctions, the system can jump from the first bootloader to the second bootloader, thereby enabling OTA upgrades of the application based on the second bootloader.
[0129] For ease of understanding, Figure 5 This diagram illustrates a flowchart of program jumps in an embodiment of this disclosure. Figure 5 The jump flow of each program is as follows:
[0130] Step S501: Run the first bootloader.
[0131] Step S502: Verify the second bootloader against the first bootloader to determine if the verification passes. If the verification passes, proceed to step S503. If the verification fails, proceed to step S507.
[0132] Step S503: Jump to the second bootloader according to the first bootloader.
[0133] Step S504: Verify the application according to the second bootloader to determine whether the verification passes. If the verification passes, proceed to step S505. If the verification fails, proceed to step S510.
[0134] Step S505: Perform a program jump according to the second bootloader to run the application.
[0135] Step S506: During the operation of the application, upon receiving a bootloader upgrade instruction, the second bootloader is upgraded according to the application.
[0136] Step S507: Verify the application according to the first bootloader to determine whether the verification passes. If the verification passes, proceed to step S508. If the verification fails, proceed to step S509.
[0137] Step S508: Perform a program jump according to the first bootloader to run the application.
[0138] Step S509: Determine if the application is abnormal, and keep the first bootloader running.
[0139] It should be noted that if both the second bootloader and the application fail verification, it indicates that the Flash memory is damaged. In this case, if only the first bootloader is kept running, program transitions will be impossible, causing the device to malfunction. Therefore, an exception handling mechanism can be implemented to re-flash the first bootloader, the second bootloader, and the application through the physical interface.
[0140] Step S510: Keep the second bootloader running. During the operation of the second bootloader, if an application upgrade instruction is received, upgrade the application according to the second bootloader.
[0141] In other words, in this embodiment of the disclosure, when both the second bootloader and the application are functioning normally, the system jumps from the first bootloader to the second bootloader, and then from the second bootloader to the application. When the second bootloader malfunctions, the system jumps from the first bootloader to the application, allowing the application to function normally and enabling the application to wait for an upgrade of the second bootloader. When the application malfunctions, the system jumps from the first bootloader to the second bootloader, allowing the second bootloader to wait for an application upgrade.
[0142] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.
[0143] In addition, this disclosure also provides a program upgrade device, an electronic device, and a computer-readable storage medium, all of which can be used to implement any of the program upgrade methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the corresponding descriptions in the method section, and will not be repeated here.
[0144] Figure 6 This is a block diagram of a program upgrade device provided in an embodiment of the present disclosure.
[0145] Reference Figure 6 This disclosure provides a program upgrade apparatus, which includes:
[0146] The first running module 61 is used to verify the second bootloader according to the first bootloader, and if the verification is successful, to perform a program jump to run the second bootloader; the first bootloader is located in the first storage area of the memory, and the starting address of the first storage area is a preset start address; the second bootloader is located in the second storage area of the memory.
[0147] The second running module 62 is used to verify the application according to the second bootloader, and if the verification is successful, to perform a program jump to run the application; the application is located in the third storage area of the memory;
[0148] The program upgrade module 63 is used to upgrade the second bootloader according to the application when a bootloader upgrade instruction is received during the operation of the application.
[0149] In one optional implementation, the bootloader upgrade instruction includes first upgrade information corresponding to the second bootloader, and the upgrade process of the second bootloader according to the application includes: determining the erase region of the memory from the first upgrade information according to the application, matching the erase region with the second memory region to obtain a first matching result; if the first matching result is a successful match, the application erases the erase region and writes the bootloader upgrade program from the first upgrade information into the erase region to obtain the upgraded second bootloader.
[0150] In one optional implementation, before determining the erase region of the memory from the first upgrade information according to the application, the device is further configured to: determine the first version information corresponding to the bootloader upgrade program from the first upgrade information according to the application; match the first version information with the first preset version information to obtain a second matching result; and if the second matching result is a successful match, perform the step of determining the erase region of the memory from the first upgrade information according to the application.
[0151] In one optional implementation, after writing the bootloader upgrade program from the first upgrade information into the erase area to obtain the upgraded second bootloader, the device is further configured to: verify the upgraded second bootloader according to the application, and determine that the second bootloader upgrade is successful if the verification passes.
[0152] In an optional implementation, the apparatus is further configured to: during the operation of the application, upon receiving an application upgrade instruction, perform a program soft reset to run the first bootloader; re-verify the second bootloader according to the first bootloader, and if the verification passes, perform a program jump to run the second bootloader; and upgrade the application according to the second bootloader.
[0153] In one optional implementation, the application upgrade instruction includes second upgrade information corresponding to the application. The step of performing a program soft reset to run the first bootloader upon receiving the application upgrade instruction includes: upon receiving the application upgrade instruction, determining second version information corresponding to the application upgrade program from the second upgrade information based on the application; matching the second version information with second preset version information to obtain a third matching result; and performing a program soft reset to run the first bootloader if the third matching result is a successful match.
[0154] In one optional implementation, after verifying the application according to the second bootloader, the device is further configured to: keep the second bootloader running if the application fails verification by the second bootloader; and, during the operation of the second bootloader, upgrade the application according to the second bootloader upon receiving an application upgrade instruction.
[0155] In one optional implementation, after upgrading the application according to the second bootloader, the device is further configured to: verify the upgraded application according to the second bootloader; if the verification passes, determine that the application has been successfully upgraded; and perform a program jump according to the second bootloader to run the upgraded application.
[0156] In one optional implementation, after verifying the second bootloader according to the first bootloader, the device is further configured to: verify the application according to the first bootloader if the first bootloader fails to verify the second bootloader; and perform a program jump according to the first bootloader to run the application if the first bootloader passes the verification of the application.
[0157] Each module in the aforementioned program upgrade device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.
[0158] Figure 7 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.
[0159] Reference Figure 7 This disclosure provides an electronic device, which includes: at least one processor 701; at least one memory 702; and one or more I / O interfaces 703 connected between the processor 701 and the memory 702; wherein the memory 702 stores one or more computer programs that can be executed by at least one processor 701, and the one or more computer programs are executed by at least one processor 701 to enable at least one processor 701 to perform the above-described program upgrade method.
[0160] The modules in the aforementioned electronic devices can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0161] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the above-described program upgrade method. The computer-readable storage medium may be volatile or non-volatile.
[0162] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device executes the above-described program upgrade method.
[0163] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).
[0164] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.
[0165] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.
[0166] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and conventional procedural programming languages such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.
[0167] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.
[0168] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.
[0169] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.
[0170] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.
[0171] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0172] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.
Claims
1. A program upgrade method, characterized in that, include: The second bootloader is verified according to the first bootloader. If the verification passes, the program jumps to run the second bootloader. The first bootloader is located in the first storage area of the memory, and the starting address of the first storage area is a preset start address. The second bootloader is located in the second storage area of the memory. The application is verified according to the second bootloader. If the verification passes, the program jumps to run the application. The application is located in the third storage area of the memory. During the operation of the application, upon receiving a bootloader upgrade instruction, the second bootloader is upgraded according to the application.
2. The method according to claim 1, characterized in that, The bootloader upgrade instruction includes first upgrade information corresponding to the second bootloader, and the upgrade process of the second bootloader according to the application includes: According to the application, the erase region of the memory is determined from the first upgrade information, and the erase region is matched with the second memory area to obtain a first matching result; If the first matching result is successful, the application erases the erased area and writes the bootloader upgrade program from the first upgrade information into the erased area to obtain the upgraded second bootloader.
3. The method according to claim 2, characterized in that, Before determining the erase region of the memory from the first upgrade information based on the application, the method further includes: Based on the application, determine the first version information corresponding to the bootloader upgrade program from the first upgrade information; The first version information is matched with the first preset version information to obtain the second matching result; If the second matching result is a successful match, the step of determining the erase region of the memory from the first upgrade information based on the application is executed.
4. The method according to claim 2 or 3, characterized in that, After writing the bootloader upgrade program from the first upgrade information into the erased area to obtain the upgraded second bootloader, the method further includes: According to the application, the upgraded second bootloader is verified, and if the verification passes, the second bootloader is determined to have been successfully upgraded.
5. The method according to claim 1, characterized in that, The method further includes: During the operation of the application, upon receiving an application upgrade instruction, a soft reset is performed to run the first bootloader. The second bootloader is re-verified based on the first bootloader. If the verification passes, the program jumps to run the second bootloader. The application is upgraded according to the second bootloader.
6. The method according to claim 5, characterized in that, The application upgrade instruction includes second upgrade information corresponding to the application. Upon receiving the application upgrade instruction, performing a program soft reset to run the first bootloader includes: Upon receiving an application upgrade instruction, the second version information corresponding to the application upgrade program is determined from the second upgrade information based on the application. The second version information is matched with the second preset version information to obtain the third matching result; If the third matching result is a successful match, a soft reset is performed to run the first bootloader.
7. The method according to claim 1, characterized in that, After verifying the application according to the second bootloader, the method further includes: If the application fails to be verified by the second bootloader, the second bootloader shall continue to run; During the operation of the second bootloader, upon receiving an application upgrade instruction, the application is upgraded according to the second bootloader.
8. The method according to any one of claims 5-7, characterized in that, After upgrading the application according to the second bootloader, the method further includes: The upgraded application is verified by the second bootloader. If the verification passes, the application is determined to have been successfully upgraded. The program is then redirected by the second bootloader to run the upgraded application.
9. The method according to claim 1, characterized in that, After verifying the second bootloader according to the first bootloader, the method further includes: If the first bootloader fails to verify the second bootloader, the application is verified according to the first bootloader. If the application passes the verification by the first bootloader, the application will be executed by program redirection according to the first bootloader.
10. A program upgrade device, characterized in that, include: The first running module is used to verify the second bootloader according to the first bootloader, and if the verification is successful, to perform a program jump to run the second bootloader; the first bootloader is located in the first storage area of the memory, and the starting address of the first storage area is a preset start address; the second bootloader is located in the second storage area of the memory; The second execution module is used to verify the application according to the second bootloader, and if the verification is successful, to perform a program jump to run the application; the application is located in the third storage area of the memory; The program upgrade module is used to upgrade the second bootloader according to the application when a bootloader upgrade instruction is received during the operation of the application.
Citation Information
Patent Citations
Software upgrading method of vehicle-mounted electronic controller, vehicle-mounted electronic controller and vehicle
CN119883340A