Ota upgrade method, device, apparatus and storage medium

Abstract

The application relates to the technical field of OTA upgrading, and discloses an OTA upgrading method, device and equipment and a storage medium, the method is applied to an electronic device, the electronic device is provided with a nonvolatile memory, the nonvolatile memory has a shared static library partition, a current application partition and a standby application partition which are independent of each other; the current application partition and the standby application partition share a public function library in the shared static library partition, the method comprises the following steps: in the case that an OTA upgrading image is received, the OTA upgrading image is written into the standby application partition through a unified erasing and writing interface, and a starting identifier is updated, the starting identifier is used for indicating an application partition started next time; after detecting a restart operation, the standby application partition is started based on the starting identifier, the standby application partition is taken as a new current application partition, and the current application partition is taken as a new standby application partition. The application reduces the redundant occupation of firmware through the shared static library partition, and improves the utilization efficiency of resources.

Description

Technical Field

[0001] This application relates to the field of OTA upgrade technology, and in particular to an OTA upgrade method, apparatus, device and storage medium. Background Technology

[0002] In the field of embedded OTA upgrades, storing a pre-compiled and linked complete firmware image in the application partition of non-volatile memory, and switching between A / B partitions (i.e., the current application partition and the backup application partition) to achieve rollback in case of upgrade failure, is a mainstream technical solution to ensure device reliability. The complete firmware image contains business logic code and common function libraries (such as communication protocol stacks, encryption algorithm libraries, file systems, etc.), providing a complete code environment for application operation.

[0003] The existing approach typically uses a dual-partition (A / B) system to independently store the complete firmware image. This means the current application partition and the backup application partition each hold a complete copy of the firmware image. During an upgrade, the new firmware version is written to the backup partition, and the upgrade is completed through partition switching. However, this approach requires each application partition to independently store a complete copy of the common function library. Since the common function library usually remains stable or only undergoes minor updates during version iterations, storing a copy in each partition results in duplicate storage of the common function library, leading to low storage resource utilization efficiency. Summary of the Invention

[0004] The main purpose of this application is to provide an OTA upgrade method, which aims to solve the technical problem of how to improve the utilization efficiency of storage resources.

[0005] To achieve the above objectives, this application proposes an OTA upgrade method, which is applied to an electronic device. The electronic device is equipped with non-volatile memory, which is pre-divided into mutually independent shared static library partitions, a current application partition, and a backup application partition. The current application partition and the backup application partition share a common function library in the shared static library partition. The method includes: Upon receiving an OTA upgrade image, the OTA upgrade image is written to the backup application partition through a unified erase / write interface, and the startup identifier is updated. The startup identifier is used to indicate the application partition to be started on the next startup. Upon detecting a restart operation, the backup application partition is started based on the startup identifier, and the backup application partition is used as the new current application partition, and the current application partition is used as the new backup application partition.

[0006] In one embodiment, the common function library is linked as a static library to the application layer programs of the current application partition and the backup application partition, respectively. The code segment and data segment of the common function library are mapped to the physical address of the shared static library partition through the linker script, so that when the application layer programs of the current application partition and the backup application partition call the common function library, they jump to the same target address.

[0007] In one embodiment, before the step of writing the OTA upgrade image to the backup application partition via a unified erase / write interface upon receiving the OTA upgrade image, the method further includes: Obtain the dependency library version information declared by the OTA upgrade image; Obtain the library version information stored in the shared static library partition; Determine whether the dependency library version information matches the library version information; If a match is found, the OTA upgrade image can be written to the backup application partition.

[0008] In one embodiment, the non-volatile memory further includes a download area, and the step of writing the OTA upgrade image to the backup application partition through a unified erase / write interface upon receiving the OTA upgrade image includes: The OTA upgrade image is written to the download area through the unified erase / write interface; After the OTA upgrade image is written, it is copied from the download area to the backup application partition through a unified erase / write interface.

[0009] In one embodiment, the step of starting the backup application partition based on the startup identifier includes: Perform an integrity check on the shared static library partition; If the integrity check passes, the backup application partition is started based on the startup identifier; If the integrity check fails, the library recovery flag stored in the electronic device is obtained; If the library recovery flag is the first value, then the contents of the shared static library partition are restored from the preset factory backup area; If the library recovery flag is the second value, then load the library compatibility pad that is pre-embedded in the current application partition or the backup application partition, and use the library compatibility pad to replace the damaged public function library in the shared static library partition. If the library recovery flag is a third value, then the recovery mode of the electronic device is activated. This recovery mode is a mode that responds to external recovery commands and refuses to jump to any application partition.

[0010] In one embodiment, the step of starting the backup application partition based on the startup identifier further includes: Obtain the dependency library version information declared by the backup application partition; Obtain the library version information stored in the shared static library partition; Determine whether the dependency library version information matches the library version information; If a match is found, execution will proceed to the backup application partition. If they do not match, then try to start the currently used application partition.

[0011] In one embodiment, after the jump to the backup application partition for execution, the method further includes: If the backup application partition fails to start, the number of startup failures will be accumulated. If the number of startup failures reaches a predetermined threshold, the system switches to the current application partition for startup and marks the backup application partition as unavailable.

[0012] Furthermore, to achieve the above objectives, this application also proposes an OTA upgrade device, the device comprising: The upgrade writing module is used to write the OTA upgrade image to the backup application partition through a unified erase and write interface when the OTA upgrade image is received, and to update the boot identifier, which is used to indicate the application partition to be started on the next boot. The startup switching module is used to start the backup application partition based on the startup identifier after detecting a restart operation, and use the backup application partition as the new current application partition, and the current application partition as the new backup application partition.

[0013] In addition, to achieve the above objectives, this application also proposes an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the OTA upgrade method described above when executed by the processor.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium that is a computer-readable storage medium, on which a computer program is stored, which, when executed by a processor, implements the steps of the OTA upgrade method described above.

[0015] This application proposes an OTA upgrade method, apparatus, device, and storage medium. The method is applied to an electronic device, which has a non-volatile memory. The non-volatile memory is pre-divided into mutually independent shared static library partitions, a current application partition, and a backup application partition. The current application partition and the backup application partition share a common function library in the shared static library partition. The method includes: upon receiving an OTA upgrade image, writing the OTA upgrade image to the backup application partition through a unified erase / write interface and updating a startup identifier, the startup identifier indicating the application partition to be started at the next startup; after detecting a restart operation, starting the backup application partition based on the startup identifier, and using the backup application partition as the new current application partition and the current application partition as the new backup application partition.

[0016] This application's OTA upgrade method employs a storage optimization architecture with a shared static library partition. The current application partition and the backup application partition share common function libraries within the shared static library partition. Therefore, during the actual upgrade process, the two application partitions do not need to store their own copies of the same common function library code; instead, they access the common function library in the shared static library partition uniformly through address mapping or symbolic links. Compared to existing solutions that independently store complete firmware images for each application partition, resulting in duplicate storage of common function libraries and low utilization of non-volatile memory space, this application, by introducing a shared static library partition, effectively reduces redundant system firmware usage in memory. Consequently, when electronic devices perform OTA upgrades with limited storage resources, they can support dual-partition redundant upgrades while retaining more user data storage space, improving storage resource utilization efficiency and the practicality of the upgrade solution. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application; Figure 2 This is a flowchart of the first embodiment of the OTA upgrade method proposed in this application; Figure 3This is a flowchart of a second embodiment of the OTA upgrade method proposed in this application; Figure 4 This is a flowchart of the third embodiment of the OTA upgrade method proposed in this application; Figure 5 A diagram of an OTA upgrade device provided in an embodiment of this application.

[0020] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0022] Reference Figure 1 , Figure 1 This is a schematic diagram of the device structure of the hardware operating environment involved in the embodiments of this application.

[0023] like Figure 1 As shown, the device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may be connected to a display screen; optionally, the user interface 1003 may include a standard wired interface or a wireless interface. In this application, the wired interface of the user interface 1003 may be a USB interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be high-speed random access memory (RAM) or non-volatile memory (NVM), such as a disk storage device. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0024] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0025] like Figure 1 As shown, the memory 1005, which is identified as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an OTA upgrade program.

[0026] exist Figure 1 In the device shown, the network interface 1004 is mainly used to connect to the backend server and communicate with the backend server; the user interface 1003 is mainly used to connect to the user equipment; the device calls the OTA upgrade program stored in the memory 1005 through the processor 1001 and executes the steps of the OTA upgrade method provided in the embodiments of this application.

[0027] Understandably, in the field of embedded OTA upgrades, storing a pre-compiled and linked complete firmware image in the application partition of non-volatile memory, and switching between A / B partitions (i.e., the current application partition and the backup application partition) to achieve rollback in case of upgrade failure, is a mainstream technical solution to ensure device reliability. The complete firmware image contains business logic code and common function libraries (such as communication protocol stacks, encryption algorithm libraries, file systems, etc.), providing a complete code environment for application operation.

[0028] The existing approach typically uses a dual-partition (A / B) system to independently store the complete firmware image. This means the current application partition and the backup application partition each hold a complete copy of the firmware image. During an upgrade, the new firmware version is written to the backup partition, and the upgrade is completed through partition switching. However, this approach requires each application partition to independently store a complete copy of the common function library. Since the common function library usually remains stable or only undergoes minor updates during version iterations, storing a copy in each partition results in duplicate storage of the common function library, leading to low storage resource utilization efficiency.

[0029] Therefore, to solve the above-mentioned technical problems, this embodiment proposes an OTA upgrade method. The method is applied to an electronic device, which is equipped with non-volatile memory. The non-volatile memory is pre-divided into mutually independent shared static library partitions, a current application partition, and a backup application partition. The current application partition and the backup application partition share a common function library in the shared static library partition. The method includes: upon receiving an OTA upgrade image, writing the OTA upgrade image to the backup application partition through a unified erase / write interface and updating the boot identifier, which is used to indicate the application partition to be started at the next boot; after detecting a restart operation, starting the backup application partition based on the boot identifier, and using the backup application partition as the new current application partition, and the current application partition as the new backup application partition.

[0030] This embodiment of the OTA upgrade method employs a storage optimization architecture with a shared static library partition. The current application partition and the backup application partition share a common function library within the shared static library partition. Therefore, during the actual upgrade process, the two application partitions do not need to store their own copies of the same common function library code; instead, they access the common function library in the shared static library partition uniformly through address mapping or symbolic links. Compared to existing solutions that independently store a complete firmware image for each application partition, resulting in duplicate storage of the common function library and low utilization of non-volatile memory space, this embodiment, by introducing a shared static library partition, effectively reduces redundant system firmware usage in memory. Thus, when electronic devices perform OTA upgrades with limited storage resources, they can support dual-partition redundant upgrades while retaining more user data storage space, improving storage resource utilization efficiency and the practicality of the upgrade solution.

[0031] For ease of understanding, the following is combined with Figures 2 to 4 The OTA upgrade method provided in the embodiments of this application, as well as the OTA upgrade method, apparatus, device and storage medium provided in the following embodiments, will be described in detail.

[0032] This application provides an OTA upgrade method. The method is applied to an electronic device, which has a non-volatile memory. The non-volatile memory is pre-divided into an independent shared static library partition, a current application partition, and a backup application partition; wherein the current application partition and the backup application partition share a common function library in the shared static library partition.

[0033] It should be noted that the aforementioned electronic devices can be embedded devices with online firmware upgrade capabilities, such as industrial charging piles, vehicle controllers, or power monitoring terminals. The aforementioned non-volatile memory can be non-volatile memory used for persistent storage of program code in embedded systems, such as NOR Flash memory. The aforementioned shared static library partition can be a storage area designated within the physical space of the non-volatile memory specifically for storing common function libraries. The aforementioned current application partition can be a storage area storing currently running application-layer programs. The aforementioned backup application partition can be a storage area storing backup application-layer programs, used as a rollback or switch target in case the current application partition upgrade fails. The aforementioned common function library can be a collection of basic functional code that multiple application partitions commonly depend on, such as a communication protocol stack, encryption algorithm library, file system library, or control algorithm library. The aforementioned application-layer programs can be functional code that implements the device's business logic, and do not contain copies of the aforementioned common function libraries.

[0034] In its implementation, the non-volatile memory of the aforementioned electronic device is partitioned according to a predetermined layout during the factory programming stage. The shared static library partition exists independently of the current application partition and the backup application partition. Each of the current and backup application partitions stores application-layer programs, but neither partition contains a physical copy of the shared function library. During the compilation and linking stage, the application-layer programs in the current and backup application partitions establish an address mapping relationship with the shared function library in the shared static library partition through the linker script. When an application-layer program in the current application partition calls an interface function in the shared function library, its actual jump target address points to the corresponding function entry address in the shared static library partition. Similarly, when an application-layer program in the backup application partition calls the same shared function library interface, its jump target address is the same as the target address jumped to when called in the current application partition. In this way, the current and backup application partitions share the shared function library in the shared static library partition, rather than storing independent copies of the shared function library.

[0035] Reference Figure 2 , Figure 2 This is a flowchart of the first embodiment of the OTA upgrade method proposed in this application.

[0036] like Figure 2 As shown, the method includes: Step S10: Upon receiving the OTA upgrade image, the OTA upgrade image is written to the backup application partition through the unified erase / write interface, and the startup identifier is updated. The startup identifier is used to indicate the application partition to be started at the next startup.

[0037] It should be noted that the executing entity in this embodiment can be a multifunctional machine device with OTA upgrade capability, such as an electronic device, or a device capable of performing the above-mentioned functions. This embodiment uses an electronic device (hereinafter referred to as the device) for description.

[0038] Furthermore, it should be noted that the aforementioned OTA upgrade image can be a firmware data package sent by a cloud server for updating the application layer program of an electronic device, which at least contains the binary code of the application layer program. The aforementioned unified erase / write interface can be a unified entry function provided by the bootloader for performing non-volatile memory erase or write operations. The aforementioned boot identifier can be a flag bit stored in the parameter area of ​​non-volatile memory, used to indicate which application partition the electronic device should boot from on the next boot.

[0039] In its implementation, upon receiving the OTA upgrade image pushed from the cloud, the aforementioned electronic device first verifies the image's legitimacy, including verifying its integrity and signature validity. If the verification passes, the electronic device performs a write operation on the non-volatile memory via the unified erase / write interface. The electronic device calls the unified erase / write interface to write the OTA upgrade image to the backup application partition. During the write operation, the unified erase / write interface verifies the target address of each erase / write request to ensure that the OTA upgrade image is correctly written within the address range of the backup application partition. After the OTA upgrade image is written, the electronic device updates the boot flag, setting its value to indicate that the next boot will be from the backup application partition. Subsequently, the electronic device performs a reset and restart operation.

[0040] Step S20: After detecting a restart operation, start the backup application partition based on the startup identifier, and use the backup application partition as the new current application partition, and use the current application partition as the new backup application partition.

[0041] It should be explained that the above restart operation can be a system reset action performed by the electronic device after the OTA upgrade is completed, such as a power-on restart process triggered by hardware reset or software reset.

[0042] In its implementation, after writing the OTA upgrade image and updating the boot identifier, the aforementioned electronic device performs a system reset. After the reset, the electronic device powers on again, and the bootloader first performs hardware initialization, then reads the boot identifier from the parameter area of ​​the non-volatile memory. Based on the value of the boot identifier, the electronic device determines the target application partition for this boot, namely the aforementioned backup application partition. Next, the electronic device performs integrity verification and version compatibility checks on the OTA upgrade image stored in the backup application partition. After these checks pass, the electronic device jumps the execution flow to the backup application partition and starts running the new version of the application layer program. After booting, the electronic device marks the backup application partition as the new current application partition and the original current application partition as the new backup application partition. At this point, the application partition roles of the electronic device are reversed; the original backup application partition becomes the currently running application partition, and the original current application partition becomes the target partition or rollback partition for the next upgrade.

[0043] For ease of understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, in an industrial charging pile scenario, after the aforementioned electronic device completes the writing of the OTA upgrade image and updates the boot identifier, it performs a system reset. After the reset and power-on, the boot program reads the boot identifier in the parameter area and confirms that the boot identifier points to the backup application partition. The aforementioned electronic device performs an integrity check on the image in the backup application partition. After the check passes, it jumps to the starting address of the backup application partition to execute the new version of the application layer program. The aforementioned electronic device marks the original backup application partition as the current application partition and the original current application partition as the backup application partition. Subsequently, if the aforementioned electronic device receives another OTA upgrade image, the new upgrade image will be written to the updated backup application partition (i.e., the original current application partition).

[0044] Furthermore, in order to improve storage resource utilization and system maintainability, the common function library is linked in the form of a static library to the application layer program of the current application partition and the application layer program of the backup application partition, respectively. The code segment and data segment of the common function library are mapped to the physical address of the shared static library partition through the linker script, so that the application layer program of the current application partition and the application layer program of the backup application partition jump to the same target address when calling the common function library.

[0045] It should be explained that the aforementioned static library format can be a pre-compiled archive file containing common functional code during the compilation process, such as a .a format library file. The aforementioned linker script can be a configuration file used during the compilation and linking phase to control the layout of various segments of the object file in non-volatile memory. The aforementioned code segment can be a segment region storing executable instructions, and the aforementioned data segment can be a segment region storing read-only constants or initialized global variables. The aforementioned physical address can be the actual memory address in non-volatile memory.

[0046] In the specific implementation, during the compilation and linking stage, developers pre-compile the common function library into a static library and link this static library with the application layer programs of both the current application partition and the backup application partition. The aforementioned electronic device uses the same linker script file in its compilation configuration. This linker script explicitly specifies that the code and data segments of the common function library should be placed at the starting physical address of the shared static library partition. Based on the instructions of this linker script, the linker allocates the code and data segments of all object files in the common function library to the address space corresponding to the shared static library partition. Simultaneously, when the application layer programs of the current application partition and the backup application partition generate their respective executable images, their reference addresses to external common function library functions are resolved to the fixed physical addresses in the shared static library partition. Because the two application partitions use the same linker script and link to the same static library, when the application layer programs of the current application partition and the backup application partition call the same common function library function, the target address they jump to is exactly the same, both pointing to the entry address of the function in the shared static library partition.

[0047] To facilitate understanding, the following example illustrates the concept, but does not impose specific limitations on this embodiment. For instance, in the development environment of a charging pile controller, a common function library containing energy metering and encryption algorithms is pre-compiled as a static library file named libcommon.a. Developers write a linker script that uses the SECTIONS command to force the .text and .rodata sections in libcommon.a to the starting address 0x080C0000 of the shared static library partition. This linker script is included in the project configurations of both the current application partition and the backup application partition. When the application layer program calls the metering function meter_calculate(), the linker resolves the function's reference address to 0x080C0120 (the specific entry address of the function in the shared static library partition). Because the two application partitions share the same linker script, application layer programs in both partitions will jump to 0x080C0120 when calling the same function.

[0048] Furthermore, to enhance the security and system reliability of the upgrade process, before the step of writing the OTA upgrade image to the backup application partition via a unified erase / write interface, the method further includes: Upon detecting an OTA upgrade image write request, obtain the write address indicated by the OTA upgrade image write request; Determine whether the write address falls within the prohibited address range, wherein the prohibited address range includes at least the address range of the shared static library partition; If the condition is met, the OTA upgrade image write request will be rejected and an error message will be returned. If the request does not fall within the specified range, then the OTA upgrade image write request is allowed to be executed.

[0049] It should be explained that the aforementioned OTA upgrade image write request can be an operation instruction initiated by the bootloader or application layer program to write the OTA upgrade image to non-volatile memory. This request must at least carry the target address to be written and the data to be written. The aforementioned prohibited address range can be a pre-defined set of protected regions in the non-volatile memory that do not allow erase / write operations.

[0050] In its implementation, when the aforementioned electronic device detects an OTA upgrade image write request, it first parses the target write address from the request. Then, it obtains a pre-configured prohibited address range, which includes at least the address range of the shared static library partition. The electronic device compares the write address with the prohibited address range to determine if the write address falls within it. If the write address falls within the prohibited address range, the electronic device rejects the OTA upgrade image write request and returns an error message to the request initiator, indicating that the write address is out of bounds or the write operation is prohibited. If the write address does not fall within the prohibited address range, the electronic device allows the OTA upgrade image write request and continues with subsequent erase / write operations.

[0051] For ease of understanding, the following explanation uses examples, but does not limit the scope of this embodiment. For example, in a charging pile controller, the address range of the shared static library partition is 0x080C0000 to 0x080D7000. The electronic device receives an OTA upgrade image write request, which carries a write address of 0x080C1000. The electronic device compares this write address with the prohibited address range, detects that the address falls within the address range of the shared static library partition, and therefore rejects the write request and returns a "write address out of bounds" error message. If the write address carried by the write request is 0x08020000, which is within the address range of the backup application partition and does not fall within the prohibited address range, then the electronic device allows the write request to be executed, writing the OTA upgrade image to the backup application partition.

[0052] This embodiment of the OTA upgrade method employs a storage optimization architecture with a shared static library partition. The current application partition and the backup application partition share a common function library within the shared static library partition. Therefore, during the actual upgrade process, the two application partitions do not need to store their own copies of the same common function library code; instead, they access the common function library in the shared static library partition uniformly through address mapping or symbolic links. Compared to existing solutions that independently store a complete firmware image for each application partition, resulting in duplicate storage of the common function library and low utilization of non-volatile memory space, this embodiment, by introducing a shared static library partition, effectively reduces redundant system firmware usage in memory. Thus, when electronic devices perform OTA upgrades with limited storage resources, they can support dual-partition redundant upgrades while retaining more user data storage space, improving storage resource utilization efficiency and the practicality of the upgrade solution.

[0053] Based on the first embodiment, in the second embodiment, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart of a second embodiment of the OTA upgrade method proposed in this application. Further, before the step of writing the OTA upgrade image to the backup application partition via a unified erase / write interface upon receiving the OTA upgrade image, the method further includes: Step S01: Obtain the dependency library version information declared by the OTA upgrade image; Step S02: Obtain the library version information stored in the shared static library partition.

[0054] It should be explained that the aforementioned dependency library version information can be version identifiers of common function libraries that the OTA upgrade image depends on, carried in the header or metadata. This library version information can also be version identifiers of common function libraries actually stored in the shared static library partition, which can be stored in the header area of ​​the shared static library partition.

[0055] In its implementation, before receiving the OTA upgrade image and preparing to write it to non-volatile memory, the aforementioned electronic device first parses the header structure of the OTA upgrade image and extracts the dependency library version information declared by the image from the header. This dependency library version information indicates which version range of common function libraries the application layer program in the OTA upgrade image needs to rely on to function correctly. Simultaneously, the aforementioned electronic device reads the library version information stored in the shared static library partition.

[0056] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, in a charging pile controller, the header of the OTA upgrade image stores a dependency library version field at a fixed offset position. After receiving the OTA upgrade image, the aforementioned electronic device reads the dependency library version information as "v2.0" from this fixed offset position. Subsequently, the aforementioned electronic device reads the library version information from the header structure of the shared static library partition. This header structure stores a version number field at an offset of 0x10 from the starting address of the shared static library partition. The aforementioned electronic device reads this field to obtain the current library version information as "v2.0".

[0057] Step S03: Determine whether the dependency library version information matches the library version information; Step S04: If a match is found, the OTA upgrade image is allowed to be written to the backup application partition.

[0058] It should be explained that matching dependency library version information with library version information can refer to a compatibility relationship between the dependency library versions declared in the OTA upgrade image and the actual library versions stored in the shared static library partition. This matching can be either an exact match in version numbers, or the version range indicated by the dependency library version information covering the actual library versions stored in the shared static library partition.

[0059] In its implementation, the aforementioned electronic device, after obtaining the dependency library version information declared in the OTA upgrade image and the library version information stored in the shared static library partition, compares the two to determine whether the dependency library version information matches the library version information. The electronic device performs this determination according to preset version matching rules. For example, the electronic device can determine whether the library version in the shared static library partition falls within the range of dependency library versions declared in the OTA upgrade image. If the determination result is a match, the electronic device allows the OTA upgrade image to be written to the backup application partition. If the determination result is a mismatch, the electronic device will refuse to write and terminate the upgrade process.

[0060] For ease of understanding, the following example illustrates the concept, but does not impose specific limitations on this embodiment. For instance, in a charging pile controller, the header of the OTA upgrade image declares that its dependent library version range is "v2.0 to v3.0". The aforementioned electronic device reads the current library version as "v2.5" from the header of the shared static library partition. The electronic device determines that "v2.5" falls within the range of "v2.0 to v3.0", therefore confirming that the dependent library version information matches the library version information and allowing the OTA upgrade image to be written to the backup application partition. If the current library version is "v3.5", then "v3.5" does not fall within the range of "v2.0 to v3.0", and the electronic device determines that there is a mismatch and refuses to write the OTA upgrade image to the backup application partition.

[0061] Furthermore, the non-volatile memory also includes a download area. The step of writing the OTA upgrade image to the backup application partition via a unified erase / write interface upon receiving the OTA upgrade image includes: The OTA upgrade image is written to the download area through the unified erase / write interface; After the OTA upgrade image is written, it is copied from the download area to the backup application partition through a unified erase / write interface.

[0062] It should be explained that the aforementioned download area can be a pre-allocated storage area in non-volatile memory, independent of the current application partition and the backup application partition, specifically used for temporarily storing received OTA upgrade images.

[0063] In its implementation, after receiving the OTA upgrade image and passing a compatibility check, the aforementioned electronic device first calls the unified erase / write interface to write the OTA upgrade image to the download area. During the writing process, the unified erase / write interface verifies the target address of each write operation to ensure that the OTA upgrade image is correctly written within the address range of the download area. After the OTA upgrade image is fully written to the download area, the electronic device performs an integrity check on the image data in the download area to confirm that no data errors occurred during the writing process. After the integrity check passes, the electronic device calls the unified erase / write interface again to copy the OTA upgrade image from the download area to the backup application partition. During the copying process, the unified erase / write interface also verifies the target address of each erase / write operation to ensure that the target address of the copy operation is within the address range of the backup application partition. After the OTA upgrade image is successfully copied to the backup application partition, the electronic device updates the boot flag to indicate booting from the backup application partition.

[0064] For ease of understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, in a charging pile controller, the non-volatile memory is pre-allocated to an independent download area, with the address range of this download area being 0x08060000 to 0x08070000. After receiving the OTA upgrade image, the aforementioned electronic device calls the unified erase / write interface to write the 744KB upgrade image to the download area. After writing is complete, the aforementioned electronic device performs a CRC check on the image in the download area to confirm that the data is complete and error-free. Subsequently, the aforementioned electronic device calls the unified erase / write interface again to copy the image in the download area to the backup application partition. During the copying process, the unified erase / write interface checks that the target addresses are all within the address boundaries of the backup application partition. After the copy is complete, the aforementioned electronic device updates the boot flag, setting the value of the boot flag to indicate booting from the backup application partition.

[0065] Further, the step of starting the backup application partition based on the startup identifier includes: Perform an integrity check on the shared static library partition; If the integrity check passes, the backup application partition is started based on the startup identifier; If the integrity check fails, the library recovery flag stored in the electronic device is obtained; If the library recovery flag is the first value, then the contents of the shared static library partition are restored from the preset factory backup area; If the library recovery flag is the second value, then load the library compatibility pad that is pre-embedded in the current application partition or the backup application partition, and use the library compatibility pad to replace the damaged public function library in the shared static library partition. If the library recovery flag is a third value, then the recovery mode of the electronic device is activated. This recovery mode is a mode that responds to external recovery commands and refuses to jump to any application partition.

[0066] It should be explained that the aforementioned integrity verification can be a process of checking the correctness and integrity of the data stored in the shared static library partition to confirm that the common function library has not been corrupted or tampered with. The aforementioned library recovery flag can be a preset parameter stored in non-volatile memory, used to indicate the recovery strategy to be taken when the integrity verification of the shared static library partition fails. The aforementioned factory backup area can be a pre-allocated area in non-volatile memory storing a copy of the original common function library at the time of manufacture. The aforementioned library compatibility pad can be a preset lightweight compatibility code that can simulate the interface behavior of the corrupted common function library, ensuring that the electronic device can still perform basic functions when the shared library is corrupted. The aforementioned recovery mode can be a running state where, when the shared library of the electronic device is corrupted and cannot be automatically recovered, the electronic device only responds to externally input recovery commands and no longer jumps to any application partition to execute application-layer programs.

[0067] In its implementation, the aforementioned electronic device performs an integrity check on the shared static library partition during system startup. This integrity check includes reading a predetermined number of bytes at the beginning of the shared static library partition to determine if the original data in that area has been erased or corrupted, and reading the library header structure at the beginning of the shared static library partition. This check structure contains a version number and a checksum, which the electronic device uses to confirm the data integrity of the shared static library partition. If the integrity check passes, the electronic device confirms the validity of the common function libraries in the shared static library partition and then starts the backup application partition based on the aforementioned startup identifier. If the integrity check fails, the electronic device obtains a pre-stored library recovery flag and selects an appropriate recovery strategy based on the value of the library recovery flag. If the library recovery flag is the first value, the electronic device reads the original common function library data from the preset factory backup area and writes this data to the shared static library partition to complete the content recovery of the shared static library partition. If the aforementioned library recovery flag is a second value, the electronic device extracts a pre-embedded library-compatible pad from the current application partition or a backup application partition, loads the library-compatible pad to replace the damaged public function library, and enables the electronic device to continue operating with limited functionality. If the aforementioned library recovery flag is a third value, the electronic device initiates a recovery mode. In this mode, the electronic device only responds to external recovery commands and refuses to jump to any application partition to execute application-level programs.

[0068] For ease of understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For example, in a charging pile controller, when the aforementioned electronic device starts up, it performs an integrity check on the shared static library partition. The check process includes reading the first four bytes of the shared static library partition and confirming that they are not all 0xFF or all 0x00, and reading the CRC32 field in the library header structure and comparing it with the calculated value. If the check passes, the aforementioned electronic device jumps to the backup application partition for execution. If the check fails, the aforementioned electronic device reads the library recovery flag. If the library recovery flag is a first value, the aforementioned electronic device writes the original library data stored in the factory backup area to the shared static library partition, completes the recovery, and restarts. If the library recovery flag is a second value, the aforementioned electronic device extracts a library compatibility pad from the backup application partition, loads the pad to simulate the interface of the damaged library, enabling the charging pile to operate with basic functions. If the library recovery flag is a third value, the aforementioned electronic device starts the recovery mode, stops jumping to any application partition, and only waits for external recovery instructions through the communication interface.

[0069] Based on the first and second embodiments, in the third embodiment, the content that is the same as or similar to that in Embodiments 1 and 2 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart of a third embodiment of the OTA upgrade method proposed in this application. Further, the step of starting the backup application partition based on the startup identifier also includes: Step S21: Obtain the dependency library version information declared by the backup application partition; Step S22: Obtain the library version information stored in the shared static library partition.

[0070] It should be explained that the aforementioned dependency library version information can be version identifiers carried in the image header of the standby application partition, used to describe the version of common function libraries that the application partition depends on. Alternatively, the aforementioned library version information can be version identifiers of common function libraries actually stored in the shared static library partition, which can be stored in the header area of ​​the shared static library partition.

[0071] In its implementation, after determining the application partition to be launched as the backup application partition based on the startup identifier, the electronic device parses the header structure of the backup application partition and extracts the dependency library version information declared by the application partition from the header. This dependency library version information indicates which version range of common function libraries the application-layer program in the backup application partition needs to run normally. Simultaneously, the electronic device reads the library version information stored in the shared static library partition. Specifically, the electronic device can read a preset library version field from a specific offset at the beginning of the shared static library partition.

[0072] Step S23: Determine whether the dependency library version information matches the library version information; Step S24: If a match is found, proceed to the backup application partition for execution; Step S25: If there is no match, try to start the current application partition.

[0073] It should be explained that the aforementioned matching of dependency library version information with library version information can refer to a compatibility relationship between the dependency library versions declared in the standby application partition and the actual library versions stored in the shared static library partition. This matching can be either an exact match in version numbers, or the version range indicated by the dependency library version information covering the actual library versions stored in the shared static library partition. The aforementioned jump to the standby application partition for execution can mean that the electronic device transfers the program execution flow to the starting address of the standby application partition and begins running the application-layer program in that partition.

[0074] In its implementation, the electronic device, after obtaining the dependency library version information declared in the backup application partition and the library version information stored in the shared static library partition, compares the two to determine whether the dependency library version information matches the library version information. The electronic device performs this determination according to a preset version matching rule. For example, the electronic device can determine whether the library version in the shared static library partition falls within the range of dependency library versions declared in the backup application partition. If the determination result is a match, the electronic device jumps the program execution flow to the backup application partition and begins running the application-layer program in that partition. If the determination result is a mismatch, the electronic device abandons starting from the backup application partition and instead attempts to start the current application partition.

[0075] To facilitate understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, in a charging pile controller, the header of the backup application partition declares that its dependent library version range is "v2.0 to v3.0". The aforementioned electronic device reads the current library version as "v2.5" from the header of the shared static library partition. The aforementioned electronic device determines that "v2.5" falls within the range of "v2.0 to v3.0", thus confirming that the dependent library version information matches the library version information, and the aforementioned electronic device jumps to the backup application partition for execution. If the current library version is "v3.5", then "v3.5" does not fall within the range of "v2.0 to v3.0", the aforementioned electronic device determines a mismatch, abandons starting from the backup application partition, and instead attempts to start the current application partition.

[0076] Furthermore, after the jump to the backup application partition for execution, the process also includes: If the backup application partition fails to start, the number of startup failures will be accumulated. If the number of startup failures reaches a predetermined threshold, the system switches to the current application partition for startup and marks the backup application partition as unavailable.

[0077] It should be explained that the aforementioned number of startup failures can be a cumulative count of startup failures for the backup application partition. The aforementioned predetermined threshold can be a preset value used to determine whether the backup application partition needs to be marked as unavailable due to consecutive failures. The aforementioned unavailable state can be a flag indicating that the contents of the application partition are unreliable or cannot start normally.

[0078] In its implementation, after switching to the backup application partition, the electronic device monitors whether the backup application partition starts normally. If the backup application partition fails to start, the electronic device accumulates the number of startup failures. The electronic device compares the accumulated number of startup failures with a predetermined threshold to determine if the threshold has been reached. If the number of startup failures has not reached the predetermined threshold, the electronic device can retry starting from the backup application partition or perform other operations according to a preset strategy. If the number of startup failures reaches the predetermined threshold, the electronic device switches to the current application partition to ensure normal operation. Simultaneously, the electronic device marks the backup application partition as unavailable.

[0079] For ease of understanding, the following explanation uses examples, but does not impose specific limitations on this embodiment. For instance, in a charging pile controller, after the aforementioned electronic device switches to the backup application partition, the backup application partition fails to start due to an error in the image data. The cumulative number of startup failures for the aforementioned electronic device is 1, and the predetermined threshold is 3. The aforementioned electronic device attempts to start from the backup application partition again, but fails again, and the cumulative number becomes 2. The third attempt to start the backup application partition also fails, and the cumulative number reaches 3. The aforementioned electronic device determines that the number of startup failures has reached the predetermined threshold, switches to the current application partition for startup, and marks the backup application partition as unavailable.

[0080] This embodiment also provides a first embodiment of an OTA upgrade device, please refer to... Figure 5 , Figure 5 This is a diagram of an OTA upgrade device provided in an embodiment of this application. The OTA upgrade device includes: The upgrade writing module is used to write the OTA upgrade image to the backup application partition through a unified erase and write interface when the OTA upgrade image is received, and to update the boot identifier, which is used to indicate the application partition to be started on the next boot. The startup switching module is used to start the backup application partition based on the startup identifier after detecting a restart operation, and use the backup application partition as the new current application partition, and the current application partition as the new backup application partition.

[0081] The startup switching module is further configured to, upon detecting an OTA upgrade image write request, obtain the write address indicated by the OTA upgrade image write request; determine whether the write address falls within the prohibited address range, wherein the prohibited address range includes at least the address range of the shared static library partition; if it falls within the prohibited address range, refuse to execute the OTA upgrade image write request and return an error message; if it does not fall within the prohibited address range, allow the execution of the OTA upgrade image write request.

[0082] Referring to the first embodiment of the OTA upgrade device, this embodiment also proposes a second embodiment of the OTA upgrade device. The contents that are the same as or similar to those in the first embodiment of the OTA upgrade device can be referred to the above description, and will not be repeated hereafter.

[0083] The upgrade writing module is further configured to obtain the dependency library version information declared by the OTA upgrade image; obtain the library version information stored in the shared static library partition; determine whether the dependency library version information matches the library version information; if they match, allow the OTA upgrade image to be written to the backup application partition. The upgrade writing module is further configured to write the OTA upgrade image to the download area through the unified erase / write interface; after the OTA upgrade image is written, the OTA upgrade image is copied from the download area to the backup application partition through the unified erase / write interface; the upgrade writing module is further configured to perform an integrity check on the shared static library partition; if the integrity check passes, the backup application partition is started based on the startup identifier; if the integrity check fails, the library recovery flag stored in the electronic device is obtained; if the library recovery flag is a first value, the contents of the shared static library partition are restored from the preset factory backup area; if the library recovery flag is a second value, a library compatibility pad pre-embedded in the current application partition or the backup application partition is loaded, and the library compatibility pad is used to replace the damaged public function library in the shared static library partition; if the library recovery flag is a third value, the recovery mode of the electronic device is started, the recovery mode is a mode that responds to external recovery commands and refuses to jump to any application partition.

[0084] Referring to the first and second embodiments of the OTA upgrade device, this embodiment also proposes a third embodiment of the OTA upgrade device. The contents that are the same as or similar to the first and second embodiments of the OTA upgrade device can be referred to the above description, and will not be repeated hereafter.

[0085] The upgrade writing module is further configured to obtain the dependency library version information declared by the backup application partition; obtain the library version information stored in the shared static library partition; determine whether the dependency library version information matches the library version information; if they match, jump to the backup application partition for execution; if they do not match, attempt to start the current application partition.

[0086] The OTA upgrade device provided in this embodiment, employing the OTA upgrade method described in the above embodiments, can solve the technical problem of how to improve the utilization efficiency of memory space. Compared with the prior art, the beneficial effects of the OTA upgrade device provided in this embodiment are the same as those of the OTA upgrade method described in the above embodiments, and other technical features in the OTA upgrade device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0087] This embodiment provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the OTA upgrade method in the above embodiment.

[0088] The computer-readable storage medium provided in this embodiment may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0089] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0090] The aforementioned computer-readable storage medium carries one or more programs that, when executed by an electronic device, cause the electronic device to perform an OTA (Over-The-Air) upgrade.

[0091] Computer program code for performing the operations of this embodiment can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed 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 remote computers, the remote computer can 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 can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of the system, method, and display according to various embodiments of this embodiment. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated 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, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0093] The modules described in this embodiment can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0094] The readable storage medium provided in this embodiment is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described OTA upgrade method, which can solve the technical problem of how to improve the viewing experience of the display screen. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this embodiment are the same as the beneficial effects of the OTA upgrade method provided in the above embodiments, and will not be repeated here.

[0095] The above descriptions are only some embodiments and do not limit the patent scope of this embodiment. All equivalent structural transformations made based on the technical concept of this application and the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the patent protection scope of this application.

Claims

1. An OTA upgrade method, characterized in that, The method is applied to an electronic device, which has non-volatile memory. The non-volatile memory is pre-divided into independent shared static library partitions, a current application partition, and a backup application partition. The current application partition and the backup application partition share a common function library within the shared static library partition. The method includes: Upon receiving an OTA upgrade image, the OTA upgrade image is written to the backup application partition through a unified erase / write interface, and the startup identifier is updated. The startup identifier is used to indicate the application partition to be started on the next startup. Upon detecting a restart operation, the backup application partition is started based on the startup identifier, and the backup application partition is used as the new current application partition, and the current application partition is used as the new backup application partition.

2. The method as described in claim 1, characterized in that, The common function library is linked in the form of a static library to the application layer program of the current application partition and the application layer program of the backup application partition respectively. The code segment and data segment of the common function library are mapped to the physical address of the shared static library partition through the linker script, so that the application layer program of the current application partition and the application layer program of the backup application partition jump to the same target address when calling the common function library.

3. The method as described in claim 1, characterized in that, Before the step of writing the OTA upgrade image to the backup application partition via a unified erase / write interface upon receiving the OTA upgrade image, the method further includes: Obtain the dependency library version information declared by the OTA upgrade image; Obtain the library version information stored in the shared static library partition; Determine whether the dependency library version information matches the library version information; If a match is found, the OTA upgrade image can be written to the backup application partition.

4. The method as described in claim 1, characterized in that, The non-volatile memory also includes a download area. The step of writing the OTA upgrade image to the backup application partition via a unified erase / write interface upon receiving the OTA upgrade image includes: The OTA upgrade image is written to the download area through the unified erase / write interface; After the OTA upgrade image is written, it is copied from the download area to the backup application partition through a unified erase / write interface.

5. The method as described in claim 1, characterized in that, The step of starting the backup application partition based on the startup identifier includes: Perform an integrity check on the shared static library partition; If the integrity check passes, the backup application partition is started based on the startup identifier; If the integrity check fails, the library recovery flag stored in the electronic device is obtained; If the library recovery flag is the first value, then the contents of the shared static library partition are restored from the preset factory backup area; If the library recovery flag is the second value, then load the library compatibility pad that is pre-embedded in the current application partition or the backup application partition, and use the library compatibility pad to replace the damaged public function library in the shared static library partition. If the library recovery flag is a third value, then the recovery mode of the electronic device is activated. This recovery mode is a mode that responds to external recovery commands and refuses to jump to any application partition.

6. The method as described in claim 1, characterized in that, The step of starting the backup application partition based on the startup identifier further includes: Obtain the dependency library version information declared by the backup application partition; Obtain the library version information stored in the shared static library partition; Determine whether the dependency library version information matches the library version information; If a match is found, execution will proceed to the backup application partition. If they do not match, then try to start the currently used application partition.

7. The method as described in claim 6, characterized in that, After the jump to the backup application partition for execution, the process also includes: If the backup application partition fails to start, the number of startup failures will be accumulated. If the number of startup failures reaches a predetermined threshold, the system switches to the current application partition for startup and marks the backup application partition as unavailable.

8. An OTA upgrade device, characterized in that, The device includes: The upgrade writing module is used to write the OTA upgrade image to the backup application partition through a unified erase and write interface when the OTA upgrade image is received, and to update the boot identifier, which is used to indicate the application partition to be started on the next boot. The startup switching module is used to start the backup application partition based on the startup identifier after detecting a restart operation, and use the backup application partition as the new current application partition, and the current application partition as the new backup application partition.

9. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the OTA upgrade method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the OTA upgrade method as described in any one of claims 1 to 7.

Images