Firmware upgrading method, embedded device and readable storage medium

Abstract

The application discloses a firmware upgrading method, embedded equipment and a readable storage medium, relates to the technical field of firmware upgrading, and the method is applied to embedded equipment, which comprises an application core, a network core and a memory, the memory is configured with a first storage area, a second storage area and a third storage area, and the method comprises the following steps: in response to a firmware upgrading request, writing a new version of application core firmware and a new version of network core firmware into the first storage area and the second storage area respectively; writing old version application core firmware in an application core running area into the third storage area, writing the new version of application core firmware into the application core running area, and then writing the old version application core firmware in the third storage area into the first storage area; writing old version network core firmware in a network core running area into the third storage area, writing the new version of network core firmware into the network core running area, and then writing the old version network core firmware in the third storage area into the second storage area. The application improves the reliability of dual-core cooperative upgrading.

Description

Technical Field

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

[0002] With the widespread adoption of the Internet of Things (IoT) and smart devices, heterogeneous dual-core processors (such as application cores + network cores) are widely used in embedded systems. The application core handles system management and application logic, while the network core is dedicated to processing network communication protocols. Firmware upgrades are crucial for ensuring device functionality iteration and security fixes; however, the upgrade process under a dual-core architecture is more complex than that of a single-core architecture. Therefore, improving the reliability of dual-core collaborative upgrades has become an important issue in this field.

[0003] Currently, dual-core firmware upgrades generally adopt an independent upgrade approach: that is, the application core and the network core each complete their own firmware updates independently, and there is no unified version switching coordination mechanism between the two. In practice, the application core usually receives the complete upgrade package first, completes its own firmware upgrade, and then transmits the network core firmware to the network core, which then independently executes its upgrade process.

[0004] However, this dual-core independent upgrade method has significant reliability flaws. Because the upgrades of the two cores occur independently, the version switching cannot be completed synchronously, inevitably creating a time window. Within this window, the system is in a state where the application core and network core versions are inconsistent. If a power outage, communication failure, or upgrade failure of either core occurs during this time, it will lead to a permanent mismatch between the two core versions, subsequently causing network protocol stack errors, inter-core communication failures, and even device boot failure. Therefore, improving the reliability of dual-core collaborative upgrades is a pressing technical problem that needs to be solved. Summary of the Invention

[0005] The main purpose of this application is to provide a firmware upgrade method, an embedded device, and a readable storage medium, aiming to solve the technical problem of how to improve the reliability of dual-core collaborative upgrades.

[0006] To achieve the above objectives, this application provides a firmware upgrade method applied to an embedded device. The embedded device includes an application core, a network core, and a memory. The memory includes a first storage area, a second storage area, and a third storage area. The firmware upgrade method includes the following steps: In response to a firmware upgrade request, the new version of the application kernel firmware and the new version of the network kernel firmware are written to the first storage area and the second storage area, respectively. Write the old version of the application core firmware in the application core runtime area to the third storage area, write the new version of the application core firmware to the application core runtime area, and then write the old version of the application core firmware in the third storage area to the first storage area. Write the old version of the network core firmware in the network core running area to the third storage area, write the new version of the network core firmware to the network core running area, and then write the old version of the network core firmware in the third storage area to the second storage area. Run the new version of the application core firmware in the application core runtime area and the new version of the network core firmware in the network core runtime area to complete this firmware upgrade.

[0007] In addition, to achieve the above objectives, this application also provides an embedded device, including: an application core, a network core, and a memory, wherein the memory includes a first storage area, a second storage area, and a third storage area, and the application core is used to execute the steps of the firmware upgrade process as described above.

[0008] In addition, to achieve the above objectives, this application also provides a readable storage medium, which is a computer-readable storage medium storing a computer program that is executed by a processor to implement the steps of the firmware upgrade method described above.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the firmware upgrade method described above.

[0010] One or more technical solutions proposed in this application have at least the following technical effects: This application improves upon the reliability deficiencies of traditional dual-core independent upgrades by introducing a third storage area as a unified switching area and designing independent and reversible atomic switching processes for the application core and network core respectively. Specifically, during the upgrade preparation phase, the new version of the application core firmware and the new version of the network core firmware are written to the first storage area and the second storage area, respectively. These two storage areas act as backup areas for their respective cores, and atomic switching operations are performed independently for each core: taking the application core as an example, the old version firmware in the runtime area is first written to the third storage area, then the new version firmware in the first storage area is written to the runtime area, and finally the old version firmware in the third storage area is written back to the first storage area, thus completing the version swap between the runtime area and the backup area. The network core also uses the third storage area to perform a symmetrical three-step switching process to achieve the version swap between its own runtime area and the second storage area. Because the swapping operation of each core can be rolled back at any intermediate step, there is no vulnerable window where one core has switched to the new version while the other remains on the old version and cannot be recovered during the entire upgrade process. Even if an anomaly occurs during the swapping of any core, the old firmware version in the swap area or backup area can be used to restore both cores to a consistent state before the upgrade, thus avoiding permanent version mismatch. Finally, after both cores have successfully completed the atomic swap, the application core and network core can run the new firmware version, and their respective backup areas fully retain the old version for subsequent rollback, improving the reliability of dual-core collaborative upgrades. Attached Figure Description

[0011] 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.

[0012] 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.

[0013] Figure 1 This is a flowchart illustrating the first embodiment of the firmware upgrade method of this application; Figure 2 This is a schematic diagram of the embedded device architecture involved in one embodiment of the firmware upgrade method of this application; Figure 3 This is a timing diagram of a symmetric switching process involved in an embodiment of the firmware upgrade method of this application; Figure 4 This is a schematic diagram of the single-core atomic exchange state machine setting process involved in one embodiment of the firmware upgrade method of this application; Figure 5 This is a schematic diagram of an anomaly recovery process involved in an embodiment of the firmware upgrade method of this application; Figure 6 This is a schematic diagram of the power outage recovery process involved in one embodiment of the firmware upgrade method of this application.

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

[0015] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0016] Currently, dual-core heterogeneous MCUs (Microcontroller Units) mainly adopt the following technical solutions for firmware upgrades: (1) Serial independent upgrade scheme Existing dual-core MCUs typically employ a serial approach for DFU functionality: first upgrade the application core, then upgrade the network core. The application core, acting as the master control core, receives the upgrade package, completes its own firmware update, and then transmits the network core firmware to the network core for upgrade. This approach suffers from a time window difference, preventing both cores from switching versions simultaneously.

[0017] (2) A / B partition backup scheme Network cores typically cannot directly access external Flash memory and must access it through an application core proxy. Existing solutions utilize inter-core communication mechanisms such as PCD for data transmission, but they do not form a complete symmetrical switching and dual-core rollback mechanism.

[0018] (3) Inter-core communication-assisted upgrade Network cores typically cannot directly access external Flash memory and must access it through an application core proxy. Existing solutions utilize inter-core communication mechanisms such as PCD (Peripheral Core Direct) or IPCC (Inter-Processor Communication Controller) for data transmission, but these are mainly used for data pass-through and have not formed a complete upgrade coordination protocol.

[0019] The above dual-core firmware upgrade methods have at least the following technical drawbacks: (1) Version swapping is non-atomic: The existing scheme lacks a symmetric atomic swapping mechanism. There is a time difference in the dual-core version switching, which may lead to version mismatch.

[0020] (2) Incomplete dual-core rollback: The existing rollback mechanism is usually a single-core independent rollback, lacking the complete rollback capability of dual-core linkage. When one core fails to upgrade, the other core may have already completed the upgrade, resulting in version inconsistency.

[0021] (3) Waste of storage resources: Traditional solutions allocate a fixed-size backup area for each core independently and require additional rollback space, resulting in waste of storage resources.

[0022] (4) Complexity caused by network core access restrictions: The network core cannot directly access external Flash and must be proxied by the application core. Existing solutions do not make full use of this architectural feature to design an efficient symmetric switching mechanism.

[0023] To address the aforementioned issues, the main solution of this application is as follows: the embedded device includes an application core, a network core, and a memory, wherein the memory includes a first storage area, a second storage area, and a third storage area; in response to a firmware upgrade request, the new version of the application core firmware and the new version of the network core firmware are written to the first storage area and the second storage area, respectively; the old version of the application core firmware in the application core runtime area is written to the third storage area, the new version of the application core firmware is written to the application core runtime area, and then the old version of the application core firmware in the third storage area is written to the first storage area; Write the old version of the network core firmware in the network core runtime area to the third storage area, write the new version of the network core firmware to the network core runtime area, and then write the old version of the network core firmware in the third storage area to the second storage area; run the new version of the application core firmware in the application core runtime area and the new version of the network core firmware in the network core runtime area to complete this firmware upgrade.

[0024] This application improves the reliability deficiencies of traditional independent dual-core upgrades by introducing a third storage area as a unified swap area and designing independent and reversible atomic swap processes for the application core and network core respectively. Specifically, during the upgrade preparation phase, the new version of the application core firmware and the new version of the network core firmware are written to the first and second storage areas respectively. These two storage areas act as backup areas for their respective cores, and atomic swap operations are performed independently for each core. Since the swap operation of each core can be rolled back at any intermediate step, there will be no vulnerable window where one core has switched to the new version while the other core is still on the old version and cannot be recovered during the entire upgrade process. Even if an anomaly occurs during the swap process of any core, the old version firmware in the swap area or backup area can be used to restore both cores to a consistent state before the upgrade, thereby avoiding permanent version mismatch. Finally, after both cores have successfully completed the atomic swap, the application core and network core can run the new version firmware, and their respective backup areas fully retain the old version for subsequent rollback, improving the reliability of dual-core collaborative upgrades.

[0025] Based on this, this application proposes a firmware upgrade method according to a first embodiment. In this embodiment, the firmware upgrade method is applied to an embedded device, which includes an application core, a network core, and a memory. The memory includes a first storage area, a second storage area, and a third storage area. (Refer to...) Figure 1 As shown, the firmware upgrade method includes the following steps S10~S40: Step S10: In response to the firmware upgrade request, write the new version of the application core firmware and the new version of the network core firmware to the first storage area and the second storage area respectively. In response to a firmware upgrade request (which may originate from a cloud server, a local maintenance tool, or be triggered by a user), the embedded device first obtains the new version of the application core firmware and the new version of the network core firmware. These two firmware files can be different partitions within the same upgrade package, or they can be two separate firmware files. The memory can be off-chip Flash memory, providing physical storage space for the first, second, and third storage areas.

[0026] The device writes the new version of the application kernel firmware to the first storage area in the memory, and simultaneously writes the new version of the network kernel firmware to the second storage area. The first storage area serves as a backup area for the application kernel, and the second storage area serves as a backup area for the network kernel. During subsequent atomic swaps, the two storage areas respectively store the new version of the firmware for their respective kernels.

[0027] Step S20: Write the old version of the application core firmware in the application core runtime area to the third storage area, write the new version of the application core firmware to the application core runtime area, and then write the old version of the application core firmware in the third storage area to the first storage area. The application kernel performs a three-step atomic swap: "run area → swap area → backup area". First, the old version of the application kernel firmware currently running in the application kernel's run area is read out and written to the third storage area (swap area). At this time, the old version of the application kernel firmware is temporarily stored in the third storage area.

[0028] Secondly, the new version of the application kernel firmware, which has been prepared in the first storage area, is written into the application kernel runtime area, so that the runtime area is switched to the new version.

[0029] Finally, the old version of the application kernel firmware in the third storage area is written back to the first storage area, restoring the first storage area (backup area) to the old version of firmware.

[0030] At this point, the application kernel has completed the version swap between the running area and the backup area: the running area has changed from old to new, and the backup area has changed from new to old.

[0031] Step S30: Write the old version of the network core firmware in the network core running area to the third storage area, write the new version of the network core firmware to the network core running area, and then write the old version of the network core firmware in the third storage area to the second storage area. The network core performs atomic swap operations symmetrical to those of the application core, and can reuse the same third memory area as the swap area. It should be noted that the network core itself may not have the ability to directly manipulate memory, or for the sake of unified control of the upgrade process, the network core's swap operations are handled by the application core through an inter-core communication channel (such as the PCD channel, i.e., the inter-processor communication channel). Specifically, the application core sends control commands to the network core through inter-core communication, and the application core performs read and write operations on the network core, thereby realizing the version swapping of the network core's runtime area and second memory area.

[0032] First, the application kernel agent writes the old version of the network kernel firmware from the network kernel runtime area to the third storage area.

[0033] Secondly, the application kernel agent writes the new version of the network kernel firmware, which has been prepared in the second storage area, into the network kernel runtime area, thereby switching the network kernel runtime area to the new version.

[0034] Finally, the application kernel agent writes the old version of the network kernel firmware from the third storage area back to the second storage area, restoring the second storage area (the backup area of ​​the network kernel) to the old version of the firmware.

[0035] The application core runtime area and the network core runtime area are storage spaces used by the application core and network core respectively for the firmware currently being executed. They are typically located in on-chip memory (such as on-chip SRAM or on-chip Flash) to ensure high-speed access and execution efficiency. During normal device operation, the firmware code in these two runtime areas is directly read and executed by their respective cores.

[0036] It should be noted that the execution order of steps S20 and S30 is not strictly limited. Step S20 can be executed before or after step S30, as the two core exchange operations are independent and each has complete rollback capabilities, preventing version mismatch risks due to sequential exchange. However, for ease of description and understanding, the embodiments of this application are preferably described in the order of executing step S20 before step S30. This preferred order is based on the fact that the application core is typically responsible for system management and upgrade process control. Prioritizing the application core's version switching ensures that during subsequent network core exchange, the application core is already running the new firmware version and can provide necessary monitoring and anomaly handling support (including performing network core exchange operations through inter-core communication proxies), thereby further improving the reliability of the upgrade process.

[0037] Step S40: Run the new version of the application core firmware in the application core runtime area and the new version of the network core firmware in the network core runtime area to complete this firmware upgrade.

[0038] After both the application core and the network core have successfully completed their respective atomic swap operations, the device can trigger a reset to execute the boot and verification process for the new firmware. Specifically, a reset operation (such as a hardware reset or a software reset) is performed, and after the reset, the two cores read the new version of the application core firmware and the new version of the network core firmware from their respective runtime addresses.

[0039] During the boot process after reset, necessary integrity checks (such as checksum or signature verification) are performed on the newly read firmware to confirm that the firmware has not been tampered with and has been written correctly. After the verification passes, the two cores initialize normally and run the new firmware version synchronously.

[0040] Meanwhile, the first storage area retains older firmware versions for the application core, and the second storage area retains older firmware versions for the network core. These older versions can serve as backups for subsequent version rollbacks. If an anomaly is detected during operation after a reset (such as dual-core communication failure or protocol stack error), the device can utilize the older firmware versions in the first and second storage areas to restore to the version before the upgrade by following the reverse swapping process.

[0041] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Furthermore, before the step of writing the old version of the application kernel firmware in the application kernel runtime area to the third storage area, the method further includes: Step A10: Set the application core switching in progress flag; Set the APP_SWAPPING flag to indicate that the application core is undergoing a swap. This flag can be stored in a specific area of ​​the off-chip Flash or in an on-chip non-volatile register. It is used to indicate that the atomic swap operation of the application core has started but not yet completed. The significance of setting this flag is that if an abnormal power outage, reset, or inter-core communication failure occurs during subsequent swapping, the system can determine whether the previous upgrade process was interrupted by reading this flag after restarting.

[0042] Because this flag is set before the first step of the swap operation (writing the old version to the swap area), it can cover the entire range of the atomic swap process, avoiding the omission of early interruptions due to the flag being set too late. At the same time, this flag works in conjunction with the subsequent swap completion flag to provide a clear indication of the system's upgrade status.

[0043] After the step of writing the old version application kernel firmware from the third storage area to the first storage area, the method further includes: Step A20: Clear the application core swap in progress flag and set the application core swap complete flag.

[0044] Clearing the "In Progress" flag indicates that the atomic swapping process of the application core has completed normally and is no longer at risk of interruption. Setting the "Application Core Swap Complete" flag (APP_SWAPPED) indicates that the application core has successfully completed the version switch, meaning the runtime area has been updated to the new version and the backup area has been restored to the old version. This completion flag can be queried by subsequent system startup procedures or upper-level management software to confirm that the upgrade operation has been fully executed.

[0045] Furthermore, if the application core swap in progress flag is valid while the completion flag is invalid during the startup process after reset, it indicates that the previous swap process was abnormally interrupted. Based on this, a rollback operation can be actively triggered to restore the application core to its stable state before the upgrade using the old firmware version in the first or third storage area, thereby avoiding version inconsistency issues caused by upgrade interruption.

[0046] In one possible implementation, prior to the step of writing the older version of the network kernel firmware from the network kernel runtime area to the third storage area, the method further includes: Step B10: Set the network core switching in progress flag; Similar to the application core switching flag, the network core switching in progress flag NET_SWAPPING is set before the first step of the switching operation (writing the old version to the swap area), thus enabling it to fully cover the entire range of the network core switching process.

[0047] After the step of writing the old version of the network kernel firmware from the third storage area to the second storage area, the method further includes: Step B20: Clear the network core switching in progress flag and set the network core switching completed flag.

[0048] Clearing the "In Progress" flag indicates that the atomic swap process of the network core has completed normally and is no longer at risk of interruption. Setting the "NET_SWAPPED" flag indicates that the network core has successfully completed the version switch, meaning the running area has been updated to the new version and the backup area has been restored to the old version. This completion flag can be queried by the application core or system startup process to confirm that both dual-core upgrades have been fully executed.

[0049] If, after a reset, the network core switching in progress flag is valid while the completion flag is invalid, it indicates that the previous network core switching was abnormally interrupted. In this case, the old version firmware in the second or third storage area can be used to perform a reverse recovery operation through the application core agent to restore the network core to a consistent state before the upgrade, thereby ensuring that the dual-core versions always match and can be rolled back.

[0050] In one possible implementation, prior to the step of running the new version of the application kernel firmware in the application kernel runtime area and the new version of the network kernel firmware in the network kernel runtime area, the method further includes: Step C10: After both the application core and the network core have completed the symmetric switching process, perform a dual-core joint debugging test to obtain the test results; Dual-core co-firing test is used to verify the collaborative working capability of the two cores under the new firmware version. Specifically, it may include, but is not limited to: connectivity test of inter-core communication channels (such as PCD channel), protocol interaction test between application core and network core, basic function test of network protocol stack (such as TCP / IP packet sending and receiving), Bluetooth communication function test (such as embedded device scanning, connection establishment and data sending and receiving), and response timeout test of application core calling network core interface.

[0051] Tests can be initiated by the application core, which sends test commands to the network core via inter-core communication and waits for a response. A timeout timer can also be set. The test result can be "normal" or "abnormal". For example, if all tests pass, the result is normal; if any test fails or times out, the result is abnormal.

[0052] This test aims to detect collaborative failures caused by firmware version incompatibility or data errors introduced during the upgrade process in advance, so as to prevent the device from running abnormal firmware directly after a reset and becoming unusable.

[0053] Step C20: If the test result indicates that the application core and the network core are working together normally, then set the upgrade completion flag and execute the steps of running the new version of the application core firmware in the application core running area and the new version of the network core firmware in the network core running area. The upgrade completion flag NET_SWAPPED can be stored in a dedicated area of ​​the external Flash memory or the on-chip non-volatile memory to persistently record that the dual-core upgrade has been successfully completed and the joint debugging test has passed. After setting this flag, the device will trigger a reset or directly jump to the new firmware.

[0054] The purpose of this flag is to ensure that if the upgrade completion flag is detected to be valid during subsequent startups, the new firmware will start normally without needing to perform the upgrade or rollback again; it also prevents the same upgrade process from being triggered repeatedly after a successful upgrade.

[0055] After setting the flag, run the new firmware version (e.g., trigger a reset and execute the new firmware). At this point, the dual cores have been confirmed to be working together normally and can be safely put into production operation.

[0056] Step C30: If the test result indicates that the application core and the network core are not working together properly, then the old version of the application core firmware in the first storage area is written into the application core runtime area, and the old version of the network core firmware in the second storage area is written into the network core runtime area to complete the dual-core rollback.

[0057] The rollback operation utilized the old firmware version stored in the backup area during the previous atomic swap: the first storage area stores the old version before the application core swap, and the second storage area stores the old version before the network core swap.

[0058] The rollback process can be led by the application core, which proxies the firmware write operation of the network core through inter-core communication, sequentially restoring the application core runtime area and the network core runtime area to the old firmware version. After the rollback is complete, the application core switch completion flag and the network core switch completion flag are cleared, and a rollback completion flag can be set for subsequent status queries.

[0059] The device can then trigger a reset, causing both cores to run the rolled-back older firmware, thus restoring it to a stable state before the upgrade. This mechanism ensures that even if the new firmware has compatibility issues, the device can automatically revert to a working version, preventing device malfunctions caused by version incompatibility or functional abnormalities.

[0060] In one possible implementation, the method further includes: Step D10: In the symmetrical exchange process between the application core and the network core, if a power failure event occurs, the currently stored status flag is read after power-on. In the symmetric exchange process between the application core and the network core (i.e., at any time from the start of step S20 to the end of step S30), if a power failure event occurs, the device will first read the currently stored status flag after the next power-on.

[0061] Status flags can be stored in a dedicated area of ​​off-chip Flash or on-chip non-volatile memory, including but not limited to: application core switching in progress flag, application core switching completed flag, network core switching in progress flag, network core switching completed flag, and upgrade completed flag. These flags are read by the boot code (such as the bootloader) after power-on to determine the interruption point of the previous upgrade process.

[0062] Step D20: If the status flag is an upgrade complete flag, then start the application core and the network core; The upgrade completion indicator signifies that the dual-core upgrade has been successfully completed and the joint debugging test has passed. The system is in a state of version consistency and normal collaboration. At this point, no rollback or repair operations are required. The boot code can directly guide the two cores to load the new firmware version from their respective runtime areas and run normally.

[0063] Step D30: If the status flag is an application core swap in progress flag, then write the old version of the application core firmware in the third storage area into the application core runtime area and clear the application core swap in progress flag. If the read status flag is "Application kernel swap in progress", the validity of the data in the third storage area can be checked (e.g., by CRC check or integrity flag), and then appropriate processing can be performed based on the check results.

[0064] If the data in the third storage area is valid, it means that the first write operation (writing the old version firmware from the application core runtime area to the third storage area) was successfully completed before the power failure. At this point, the old version application core firmware from the third storage area is written to the application core runtime area to restore the runtime area to its previous state before the swap. After writing is complete, the application core swap in progress flag is cleared.

[0065] If the data in the third storage area is invalid, it indicates that the first step of the write operation was incomplete or an error occurred during the write process. At this time, the application core runtime area still contains the original old firmware version (because the runtime area has not been modified). Therefore, there is no need to perform a rollback write; simply clear the application core swap in progress flag.

[0066] The above process ensures that regardless of when the power outage occurs after the in-process switching flag is set, the system can restore the application cores to their stable state before the switch (the running area uses the old version, and the backup area uses the new version), thus avoiding version inconsistencies caused by upgrade interruptions. After clearing the flag, the device can boot normally using the old version.

[0067] Step D40: If the status flag is the application core swap completion flag, then write the old version of the application core firmware in the first storage area into the application core runtime area and clear the application core swap completion flag. The application core swap completion flag being set indicates that the atomic swap operation of the application core has been completed normally (the running area is updated to the new version, and the backup area is restored to the old version). If this flag exists but the upgrade completion flag does not exist, it means that a power outage occurred after the application core swap was completed, and subsequent processes (such as network core swap or dual-core joint debugging tests) were interrupted.

[0068] At this point, the application core is running the new firmware, but the network core may still be using the old version or be in a switching interruption state, resulting in inconsistencies between the two cores. For safety reasons, the application core should be rolled back to the old version to unify both cores with the old version before attempting an upgrade again or maintaining the original working state.

[0069] The first storage area contains the old firmware version before the application core swap. This firmware was fully preserved after the swap, so no validity check is needed, and it can be directly written back to the application core runtime area to complete the rollback. After completion, the application core swap completion flag is cleared. The device can then normally boot the old firmware version of the application core, and the network core should also be restored to the old version through its own flag processing, ultimately achieving version consistency between the two cores.

[0070] Step D50: If the status flag is a network core switching in progress flag, then write the old version of the network core firmware in the third storage area into the network core running area and clear the network core switching in progress flag. If the read status flag is "Network core switching in progress", the validity of the data in the third storage area can be checked (e.g., by CRC check or integrity flag), and then appropriate processing can be performed based on the check results.

[0071] The "Network Core Exchange in Progress" flag is set, indicating that the atomic exchange operation of the network cores has begun but has not yet been completed. If this flag is valid while the corresponding "Completion" flag is invalid, it indicates that a power outage or abnormal interruption occurred during the network core exchange process.

[0072] If the data in the third storage area is valid, it means that the first write operation (writing the old version firmware from the network core runtime area to the third storage area) was successfully completed before the power failure. At this point, the old version network core firmware from the third storage area is written to the network core runtime area to restore the runtime area to its previous state before the switch. After writing is complete, the network core switching in progress flag is cleared.

[0073] If the data in the third storage area is invalid, it indicates that the first step of the write operation was not completed or an error occurred during the write process. At this time, the network core runtime area still contains the original old firmware version (because the runtime area has not been modified). Therefore, there is no need to perform a rollback write; simply clear the network core switching in progress flag.

[0074] Since the network core's switching operations are typically performed by the application core through an inter-core communication agent, the rollback operation after a power outage is also completed by the application core agent. This process ensures that the network core can be restored to its stable state before the switch, and after clearing the flags, it can start normally as the old version.

[0075] Step D60: If the status flag is a network core exchange completion flag, then write the old version of the network core firmware in the second storage area into the network core running area, and clear the network core exchange completion flag.

[0076] If the read status flag is the network core exchange completion flag, then the old version of the network core firmware in the second storage area is written into the network core runtime area, and the network core exchange completion flag is cleared.

[0077] The network core swap completion flag being set indicates that the atomic swap operation of the network cores has been completed normally (the running area is updated to the new version, and the backup area is restored to the old version). The presence of this flag but the absence of the upgrade completion flag indicates that a power outage occurred after the network core swap was completed but before the dual-core debugging test or the upgrade completion flag was set.

[0078] At this point, the network core is running the new firmware version, while the application core may still be the old version or may have been switched to the new version but failed the integration test. To avoid inconsistency between the two cores, the network core is rolled back to the old version.

[0079] The second storage area contains the old firmware version before the network core swap. This firmware has been fully preserved after the swap and can be written back to the network core runtime area to complete the rollback. After completion, the network core swap completion flag is cleared.

[0080] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the first and second embodiments described above can be referred to the above description and will not be repeated hereafter. In addition, after the step of writing the old version of the application kernel firmware in the application kernel runtime area to the third storage area, the method further includes: Step E10: If an error occurs during the process of writing the new version of the application core firmware into the application core runtime area, or during the process of writing the old version of the application core firmware from the third storage area into the first storage area, then the old version of the application core firmware from the third storage area is written into the application core runtime area to complete the application core rollback.

[0081] After successfully writing the old version of the application core firmware from the application core runtime area to the third storage area, two subsequent operations will be performed: writing the new version of the application core firmware to the application core runtime area, and writing the old version of the application core firmware from the third storage area back to the first storage area. If an exception occurs during either of these operations (such as write verification failure, external Flash programming error, power failure, or system reset), the old version of the application core firmware from the third storage area will be written to the application core runtime area to complete the application core rollback.

[0082] Specifically, if an exception occurs during the process of writing the new version of the application kernel firmware to the application kernel runtime area, the application kernel runtime area may be in a partially updated or corrupted state and unable to execute normally. At this time, the old version of firmware moved from the runtime area is still completely stored in the third storage area. The system can rewrite the old version of firmware from the third storage area back to the application kernel runtime area, overwriting the incomplete or incorrect new version data, thus restoring the runtime area to its stable state before the upgrade.

[0083] When an anomaly occurs during the process of writing the old version of the application kernel firmware from the third storage area back to the first storage area, the first storage area may fail to successfully restore the old version firmware, but the application kernel runtime area has already successfully switched to the new version. Since subsequent processes (such as network kernel upgrades or dual-core co-firing tests) may rely on the old version in the first storage area as a backup, if the backup data is invalid, a reliable old version image cannot be provided for possible subsequent rollback operations. Therefore, the application kernel runtime area is also rolled back to the old version to ensure that the dual-core versions are consistent and have complete rollback capabilities. The rollback operation also utilizes the old version firmware stored in the third storage area, rewriting it into the application kernel runtime area.

[0084] After the rollback is complete, the "Application Core Switching in Progress" flag (if set) and the "Application Core Switching Completed" flag (if present) should be cleared to prevent the system from mistakenly believing that the upgrade was successful. Afterward, the device can continue to run the older version of the network core firmware, ensuring that the device is always in a working state.

[0085] This exception handling mechanism works in conjunction with the power failure recovery mechanism: the power failure recovery mechanism handles the recovery after a power failure, while this exception handling mechanism handles write exceptions that occur in real time during the upgrade process. Together, they ensure that the application core can be rolled back to the old version under any abnormal situation, thereby further improving the reliability of dual-core collaborative upgrades.

[0086] In one possible implementation, after the step of writing the older version of the network kernel firmware from the network kernel runtime area to the third storage area, the method further includes: Step F10: If an error occurs during the process of writing the new version of the network core firmware into the network core runtime area, or if an error occurs during the process of writing the old version of the network core firmware from the third storage area into the second storage area, then the old version of the network core firmware from the third storage area is written into the network core runtime area to complete the network core rollback.

[0087] After successfully writing the old version of the network core firmware from the network core runtime area to the third storage area, two subsequent operations will be performed: writing the new version of the network core firmware to the network core runtime area, and writing the old version of the network core firmware from the third storage area back to the second storage area. If an exception occurs during either of these operations (such as write verification failure, external Flash programming error, inter-core communication interruption, power failure, or system reset), the old version of the network core firmware from the third storage area will be written to the network core runtime area to complete the network core rollback.

[0088] Specifically, when an anomaly occurs during the process of writing the new version of the network core firmware to the network core runtime area, the network core runtime area may be in a partially updated or corrupted state, unable to execute network protocol stack functions normally. At this time, the old version of firmware moved from the network core runtime area is still fully stored in the third storage area. The application core should perform a rollback operation through an inter-core communication channel (such as the PCD channel) to rewrite the old version of firmware from the third storage area back to the network core runtime area, overwriting the incomplete or erroneous new version data, thus restoring the network core runtime area to its stable state before the upgrade.

[0089] When an anomaly occurs during the process of writing the old version of the network core firmware from the third storage area back to the second storage area, the second storage area (the backup area for the network core) may fail to successfully restore the old firmware version, but the network core runtime area has already successfully switched to the new version. Since subsequent processes (such as dual-core co-firing tests or version rollback) may rely on the old version in the second storage area as a backup, the network core runtime area is also rolled back to the old version to ensure dual-core version consistency and full rollback capability. The rollback operation also utilizes the old firmware version stored in the third storage area, rewriting it to the network core runtime area through the application core agent.

[0090] After the rollback is complete, the network core switching in progress flag (if set) and the network core switching complete flag (if present) should be cleared to prevent the system from mistakenly believing that the network core upgrade was successful.

[0091] For example, to aid in understanding the technical concept or principle of the firmware upgrade method combined with the first and second embodiments described above, a specific embodiment is now provided. In this specific embodiment, the firmware upgrade is applied to an embedded device, referring to... Figure 2As shown, the embedded device includes a heterogeneous dual-core MCU and an external Flash memory. The heterogeneous dual-core MCU internally houses an application core (main control core) and a network core (coprocessor core). The application core has direct access to the external Flash memory, while the network core interacts with the application core via the PCD channel to operate the external Flash memory through proxy access. The external Flash memory is divided into an application core backup area (i.e., the first storage area), a network core backup area (i.e., the second storage area), a shared switching area (i.e., the third storage area), and an upgrade status flag area. The application core backup area has a size of Size_A and stores the new version of the application core firmware before the upgrade and the old version of the application core firmware after the upgrade, enabling rollback. The network core backup area has a size of Size_N and stores the new version of the network core firmware before the upgrade and the old version of the network core firmware after the upgrade, also enabling rollback. The shared switching area has a size of max(Size_A, Size_N), with phase one storing the old application core firmware and phase two storing the old network core firmware. The application core can directly access the external Flash memory, while the network core accesses it through the PCD channel via proxy.

[0092] Based on the aforementioned embedded device, referring to Figure 3 As shown, the firmware upgrade process includes: Phase 1: Applying kernel-symmetric swaps

[0093] Phase Two: Network Core Symmetric Switching

[0094] Phase 3: Confirmation Completed

[0095] During the upgrade process, the state machine for single-core atom exchange is as follows: Figure 4 As shown. Triggered by the start of the swap, the system first enters the SWAPPING state. In this state, three operations are performed simultaneously: migrating the firmware from the running area to the swap area, writing the new version firmware from the backup area to the running area and running it with the new version, and archiving the old version firmware from the swap area to the backup area. After these three steps are completed, the state transitions to the SWAPPED state (swap complete, rollback possible), and then enters the testing and confirmation phase. If the test passes, the state changes to COMPLETED; if the test fails, it enters the ROLLBACK state, restoring the old version firmware from the backup area to the running area, completing the firmware version rollback operation.

[0096] The firmware upgrade process also includes a complete rollback mechanism, see below. Figure 5As shown, after power-on or reset, the device enters the IDLE state (flag value 0x00). Upon receiving the upgrade command, the APP_SWAPPING flag is set, and the symmetric switching process of the application cores is executed (corresponding to sections 4.1 to 4.3 above). If the application core switching is successful, the APP_SWAPPED flag is set; if the switching fails, the ROLLBACK flag is set, the application cores are restored to their original state, and the device returns to the application core switching stage. After the application core symmetric switching is completed, the NET_SWAPPING flag is set, and the symmetric switching process of the network cores is executed (corresponding to sections 4.4 to 4.6). If the network core switching is successful, the NET_SWAPPED flag is set; if the switching fails, the ROLLBACK flag is set, the network cores are restored to their original state, and the device reverts to the application core switching stage. After the dual-core switching is completed sequentially, a dual-core integration test is executed (4.7). If the integration test is successful, the COMPLETED flag is set; if the integration test fails, the device enters the dual-core ROLLBACK state, and the dual-core rollback operation of restoring the application core from the backup area to the running area and the network core from the backup area to the running area is executed synchronously.

[0097] The power-off recovery process for firmware upgrades is as follows: Figure 6 As shown, after the device powers on, the application core reads the status flags and processes them accordingly. If the flag value is IDLE or COMPLETED, the device starts normally. If the flag value is APP_SWAPPING, the old firmware version in the shared switch area is restored to the application core runtime area, the flag is cleared, and the device starts normally. If the flag value is APP_SWAPPED, the old firmware version in the application core backup area is restored to the application core runtime area, the flag is cleared, and the device starts normally. If the flag value is NET_SWAPPING, the old firmware version in the shared switch area is restored to the network core runtime area via the PCD channel, the flag is cleared, and the device starts normally. If the flag value is NET_SWAPPED, the old firmware version in the network core backup area is restored to the network core runtime area via the PCD channel, the flag is cleared, and the device starts normally. If other abnormal values ​​are detected, the device enters safe mode. Safe mode serves as a fallback operating mode for device failures, restricting the loading of abnormal firmware, ensuring the stable operation of the dual-core basic kernel, preventing device crashes and paralysis, and awaiting manual intervention to repair abnormal states.

[0098] It should be noted that the above examples are only used to help understand this embodiment and do not constitute a limitation on the firmware upgrade process of this embodiment. Any simple modifications based on this technical concept are within the protection scope of this application.

[0099] Furthermore, this application also proposes an embedded device, which includes an application core, a network core, and a memory. The memory includes a first storage area, a second storage area, and a third storage area. The application core is used to execute the steps of the firmware upgrade process described above.

[0100] In one embodiment, the size of the first storage area is configured to the maximum size of the preset application kernel firmware, the size of the second storage area is configured to the maximum size of the preset network kernel firmware, and the size of the third storage area is configured to the maximum value between the maximum size of the preset application kernel firmware and the maximum size of the preset network kernel firmware.

[0101] The embedded device provided in this application, employing the firmware upgrade method described in the above embodiments, can solve the technical problem of how to improve the reliability of dual-core collaborative upgrades. Compared with the prior art, the beneficial effects of the embedded device provided in this application are the same as those of the firmware upgrade method provided in the above embodiments, and other technical features in this embedded device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0102] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0103] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0104] In addition, to achieve the above objectives, embodiments of this application also provide a readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the firmware upgrade method in the above embodiments.

[0105] The computer-readable storage medium provided in this application 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.

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

[0107] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by an embedded device, cause the embedded device to perform the process steps of any embodiment of the aforementioned firmware upgrade method.

[0108] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including 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).

[0109] 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 this application. 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 a 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.

[0110] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the modules themselves.

[0111] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described firmware upgrade method, thereby solving the technical problem of how to improve the reliability of dual-core collaborative upgrades. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the firmware upgrade method provided in the above embodiments, and will not be repeated here.

[0112] Furthermore, this application also proposes a computer program product, including a computer program that, when executed by a processor, implements the steps of the firmware upgrade method described above.

[0113] The specific implementation method of the computer program product in this application is basically the same as the embodiments of the firmware upgrade method described above, and will not be repeated here.

[0114] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0115] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0116] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software sensor. This computer software sensor is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause an embedded device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0117] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A firmware upgrade method characterized by comprising: Applied to embedded devices, the embedded devices include an application core, a network core, and a memory, the memory including a first memory area, a second memory area, and a third memory area, the firmware upgrade method includes the following steps: In response to a firmware upgrade request, the new version of the application kernel firmware and the new version of the network kernel firmware are written to the first storage area and the second storage area, respectively. Write the old version of the application core firmware in the application core runtime area to the third storage area, write the new version of the application core firmware to the application core runtime area, and then write the old version of the application core firmware in the third storage area to the first storage area. Write the old version of the network core firmware in the network core running area to the third storage area, write the new version of the network core firmware to the network core running area, and then write the old version of the network core firmware in the third storage area to the second storage area. Run the new version of the application core firmware in the application core runtime area and the new version of the network core firmware in the network core runtime area to complete this firmware upgrade.

2. The firmware upgrade method as described in claim 1, characterized in that, Before the step of writing the old version of the application kernel firmware in the application kernel runtime area to the third storage area, the method further includes: Set the application core switching in progress flag; After the step of writing the old version application kernel firmware from the third storage area to the first storage area, the method further includes: Clear the application core swap in progress flag and set the application core swap complete flag.

3. The firmware upgrade method as described in claim 2, characterized in that, Before the step of writing the old version of the network core firmware in the network core runtime area to the third storage area, the method further includes: Set the network core switching in progress flag; After the step of writing the old version of the network kernel firmware from the third storage area to the second storage area, the method further includes: Clear the network core switching in progress flag and set the network core switching complete flag.

4. The firmware upgrade method as described in claim 3, characterized in that, Before the step of running the new version of the application kernel firmware in the application kernel runtime area and the new version of the network kernel firmware in the network kernel runtime area, the method further includes: After both the application core and the network core have completed the symmetric switching process, a dual-core joint debugging test is performed to obtain the test results. If the test results indicate that the application core and the network core are working together normally, then set the upgrade completion flag and execute the steps of running the new version of the application core firmware in the application core running area and the new version of the network core firmware in the network core running area; If the test results indicate that the application core and the network core are not working together properly, the old version of the application core firmware in the first storage area is written into the application core runtime area, and the old version of the network core firmware in the second storage area is written into the network core runtime area to complete the dual-core rollback.

5. The firmware upgrade method as described in claim 4, characterized in that, The method further includes: In the symmetrical exchange process between the application core and the network core, if a power failure event occurs, the currently stored status flag is read after power-on. If the status flag is an upgrade complete flag, then start the application core and the network core; If the status flag is an application core swap in progress flag, then the old version of the application core firmware in the third storage area is written into the application core runtime area, and the application core swap in progress flag is cleared. If the status flag is the application core swap completion flag, then the old version of the application core firmware in the first storage area is written into the application core runtime area, and the application core swap completion flag is cleared. If the status flag is a network core switching in progress flag, then the old version of the network core firmware in the third storage area is written into the network core running area, and the network core switching in progress flag is cleared. If the status flag is a network core exchange completion flag, then the old version of the network core firmware in the second storage area is written into the network core runtime area, and the network core exchange completion flag is cleared.

6. The firmware upgrade method according to any one of claims 1 to 5, characterized in that, After the step of writing the old version of the application kernel firmware in the application kernel runtime area to the third storage area, the method further includes: If an error occurs during the process of writing the new version of the application kernel firmware into the application kernel runtime area, or during the process of writing the old version of the application kernel firmware from the third storage area into the first storage area, then the old version of the application kernel firmware from the third storage area is written into the application kernel runtime area to complete the application kernel rollback.

7. The firmware upgrade method according to any one of claims 1 to 5, characterized in that, After the step of writing the old version of the network core firmware in the network core runtime area to the third storage area, the method further includes: If an error occurs during the process of writing the new version of the network core firmware into the network core runtime area, or if an error occurs during the process of writing the old version of the network core firmware from the third storage area into the second storage area, then the old version of the network core firmware from the third storage area will be written into the network core runtime area to complete the network core rollback.

8. An embedded device, the embedded device comprising an application core, a network core, and a memory, the memory comprising a first storage area, a second storage area, and a third storage area, the application core being configured to perform the steps of the firmware upgrade process as described in any one of claims 1 to 7.

9. The embedded device as described in claim 8, characterized in that, The size of the first storage area is configured to the maximum size of the preset application kernel firmware, the size of the second storage area is configured to the maximum size of the preset network kernel firmware, and the size of the third storage area is configured to the maximum value between the maximum size of the preset application kernel firmware and the maximum size of the preset network kernel firmware.

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

Images