Energy-adaptive mcu low-power firmware upgrade method and system

Abstract

The application relates to the technical field of computer data processing, and specifically provides an MCU low-power-consumption firmware upgrading method based on energy self-adaptation, which comprises the following steps: a communication link between an upgrading initiator and an MCU device is established, and an energy state parameter is collected in real time through an energy monitoring terminal built in the MCU device; according to a preset energy state threshold interval, a comprehensive value of the energy state parameter is divided into a low energy state, a medium energy state and a high energy state; based on a current energy state grade, a preset adjustment rule is used to dynamically adjust an upgrading strategy parameter of a current firmware; based on the dynamically adjusted upgrading strategy parameter, target firmware data is transmitted to the MCU device through the communication link, and a firmware upgrading operation is performed until the upgrading is completed. The scheme constructs an adaptive system of energy state sensing-strategy dynamic adjustment-hardware collaborative optimization, and effectively solves the high power consumption, efficiency and reliability imbalance problem caused by not combining the energy state in the prior art.

Description

Technical Field

[0001] The present invention relates to the technical field of computer data processing, and in particular to an energy-adaptive MCU low-power firmware upgrade method and system. Background Art

[0002] With the development of IoT technology, MCUs (microcontroller units), core components of embedded devices, face critical requirements for firmware upgrade reliability, efficiency, and energy consumption control. Existing MCU firmware upgrade methods primarily utilize serial communication (such as UART), parallel communication, or transparent transmission protocols (such as those based on XMOS chips). A typical process includes: packaging firmware files into fragments, ensuring data integrity through verification mechanisms (such as CRC), employing encryption algorithms (such as RSA) to ensure transmission security, and supporting retransmission mechanisms and permission verification (such as product ID verification).

[0003] However, there are obvious defects in the existing technology. For example, existing upgrade methods mostly focus on the integrity and security of data transmission (such as fragment verification and encryption), and do not consider the impact of the device energy status on the upgrade process. Even if the device is low on power, it still maintains high power consumption operation, which can easily lead to upgrade interruption; and most of them use complete firmware transmission, which has large data volume and long time consumption, further increasing energy consumption; at the same time, although the fragment-by-fragment verification and instant retransmission strategies ensure reliability, frequent interactions will generate additional energy consumption. In addition, the multi-core capabilities of the transparent transmission chip and the MCU scheduling are not combined with the low power consumption goal, and the hardware potential is not used for energy consumption optimization, which makes it difficult to meet the needs of battery-powered devices.

[0004] Therefore, for battery-powered MCU devices, there is an urgent need for a low-power firmware upgrade solution that can adaptively adjust the upgrade strategy according to the energy state to balance the upgrade reliability, efficiency and energy consumption control, and solve the applicability defects of existing technologies in low-power scenarios. Summary of the Invention

[0005] In order to overcome the deficiencies of the prior art, the present invention provides an energy-adaptive MCU low-power firmware upgrade method and system to solve the problems in the prior art.

[0006] One embodiment of the present invention provides an MCU low-power firmware upgrade method based on energy adaptation, comprising the steps of:

[0007] Establish a communication link between the upgrade initiator and the MCU device, and collect energy status parameters in real time through the energy monitoring terminal built into the MCU device. The energy status parameters include at least one or more combinations of battery voltage value, remaining power percentage, and energy consumption rate;

[0008] According to a preset energy state threshold interval, the comprehensive value of the energy state parameter is divided into a low energy state, a medium energy state and a high energy state;

[0009] Based on the current energy state level, dynamically adjust the upgrade policy parameters of the current firmware according to preset adjustment rules, the upgrade policy parameters including the transmission parameters, verification parameters and retransmission policy parameters of the target firmware data;

[0010] Based on the dynamically adjusted upgrade policy parameters, the target firmware data is transmitted to the MCU device through the communication link, and the firmware upgrade operation is performed until the upgrade is completed;

[0011] The adjustment rules include differentiated adjustment strategies for different energy states, including:

[0012] When in a low-energy state, reduce data transmission power consumption, extend the check interval period, configure a non-instant retransmission mechanism, and optimize the multi-core collaboration mode according to the hardware resource status;

[0013] When in a high-energy state, data transmission efficiency is improved, the verification interval is shortened, an instant retransmission mechanism is configured, and the multi-core collaborative mode is activated according to the hardware resource status.

[0014] By adopting this solution, an energy monitoring terminal collects multi-dimensional energy state parameters in real time and comprehensively classifies them, enabling the MCU device to dynamically adapt its upgrade strategy based on its current energy state (low, medium, or high). In low-energy states, low-power optimization strategies such as reduced data transmission units, lowered baud rates, extended verification cycles, batch retransmissions, and multi-core sleep significantly reduce energy consumption during the upgrade process, avoiding upgrade interruptions due to low battery conditions. In high-energy states, efficiency-focused strategies such as increased transmission units, higher baud rates, shorter verification cycles, immediate retransmissions, and multi-core parallelization enable rapid upgrade completion when sufficient energy is available, balancing reliability and transmission efficiency. This solution, which builds an adaptive system of "energy state awareness - dynamic policy adjustment - hardware collaborative optimization," effectively addresses the imbalance between high power consumption, efficiency, and reliability caused by existing technologies that fail to incorporate energy state. This solution is particularly suitable for battery-powered devices, significantly improving energy efficiency while ensuring the integrity and security of firmware upgrades, extending device life, and increasing upgrade success rates.

[0015] In one embodiment:

[0016] When in a low energy state, specifically:

[0017] Dividing the target firmware data into sub-data blocks no larger than a preset minimum data transmission unit, thereby reducing the transmission baud rate of the communication link;

[0018] Extend the time interval between two adjacent verification operations to the preset maximum verification period;

[0019] Configure the retransmission policy to trigger batch retransmission when the cumulative number of errors reaches N, where N ≥ 2.

[0020] If the communication link includes multi-core hardware resources, configuring the multi-core hardware resources to enter a single-core working mode, and the non-main core units to enter a dormant state;

[0021] When in a high energy state, specifically:

[0022] Dividing the target firmware data into sub-data blocks no smaller than a preset maximum data transmission unit, thereby increasing the transmission baud rate of the communication link;

[0023] Shorten the time interval between two adjacent verification operations to the preset minimum verification period;

[0024] Configure the retransmission policy to immediate single-packet retransmission;

[0025] If the communication link includes multi-core hardware resources, waking up the multi-core hardware resources to process data transmission and verification operations in parallel;

[0026] When in the medium energy state, the preset default transmission unit, default baud rate, default check period and default retransmission strategy are used.

[0027] By adopting the above scheme, refined implementation strategies are provided for different energy states. In low-energy states, high-frequency interactions and instantaneous power consumption are reduced by limiting the size of sub-data blocks, reducing the baud rate, extending the verification period, and batch retransmission. The multi-core hardware sleep mechanism is combined to further reduce unnecessary energy consumption, effectively avoiding upgrade interruptions in low-power scenarios. In high-energy states, transmission and verification efficiency is improved by increasing the sub-data block size, increasing the baud rate, shortening the verification period, and performing instant retransmission, combined with multi-core parallel processing, allowing upgrades to be completed quickly when sufficient energy is available. In medium-energy states, a default strategy is used to achieve a smooth transition. This scheme achieves a dynamic balance between energy consumption and efficiency through the coordinated adjustment of transmission units, rates, verification mechanisms, retransmission strategies, and hardware scheduling. Compared with the fixed strategies of existing technologies, it significantly improves upgrade reliability and energy utilization efficiency under different energy conditions.

[0028] In one embodiment:

[0029] The transmission parameters of the target firmware data include the complete target firmware or a fragmentation strategy based on the difference data between the target firmware and the current firmware, wherein the difference data includes one or more combinations of incremental data, modified data, and non-overlapping data segments calculated by a differential algorithm;

[0030] The sub-data blocks are generated based on the difference data, and the sharding strategy is used to determine the size and number of the sub-data blocks;

[0031] Among them, the sharding strategy based on the difference data between the target firmware and the current firmware is preferentially adopted in the low energy state to reduce transmission power consumption.

[0032] By adopting the above solution and introducing a sharding strategy based on the difference data between the target firmware and the current firmware, the system prioritizes transmitting incremental data (such as incremental and modified data generated by differential transmission) rather than the complete firmware in low-energy states, significantly reducing the amount of data transmitted, and lowering transmission time and energy consumption. The sharding rules for differential data are further adapted to low-power requirements, matching the sub-data block size with the energy state, minimizing transmission power consumption while ensuring data integrity. This strategy addresses the existing technology's drawback of "high energy consumption for complete firmware transmission" by significantly improving the firmware upgrade efficiency of battery-powered devices through incremental transmission and differentiated sharding. This effectively extends device battery life and ensures upgrade success rates, especially in low-energy scenarios.

[0033] In one embodiment, the step of dividing the comprehensive value of the energy state parameter into a low energy state, a medium energy state, and a high energy state according to a preset energy state threshold interval specifically includes the following steps:

[0034] Preset the weight coefficient of each energy state parameter, and the weight coefficient is set according to the degree of influence of the parameter on the energy state;

[0035] Normalize the real-time collected battery voltage, remaining power percentage, and energy consumption rate to obtain standardized values ​​of each parameter;

[0036] Calculating a comprehensive value of the energy state parameter by weighted summation based on the weight coefficient and the normalized value;

[0037] The low energy threshold, medium energy threshold and high energy threshold are preset to form the energy state threshold range:

[0038] If the comprehensive value is ≤ the low energy threshold, it is determined to be in a low energy state;

[0039] If the low energy threshold < comprehensive value ≤ medium energy threshold, it is determined to be a medium energy state;

[0040] If the comprehensive value is greater than the medium energy threshold, it is determined to be a high energy state.

[0041] By adopting the above scheme, through weight setting, parameter normalization and weighted calculation, the comprehensive value of the energy state parameters is more closely aligned with the actual energy level of the equipment. Combined with clear threshold interval judgment rules, the accuracy and consistency of energy state classification are improved, providing a more reliable decision-making basis for the dynamic adjustment of subsequent upgrade strategies, and avoiding strategy adaptation deviations caused by misjudgment of a single parameter.

[0042] In one embodiment, the step of dynamically adjusting the upgrade policy parameters of the current firmware based on the current energy state level and according to a preset adjustment rule comprises the following steps:

[0043] Real-time monitoring of the duration of the current energy status level;

[0044] When the energy status level changes, determine whether the duration of the change exceeds the preset stability threshold:

[0045] If so, switch to the corresponding adjustment strategy according to the new energy state level;

[0046] If not, maintain the current adjustment strategy;

[0047] During the upgrade process, if the duration of the current energy status level exceeds the preset policy validity period, the energy status is re-evaluated and the upgrade policy parameters are adjusted.

[0048] By adopting the above solution and introducing a state change stability threshold and policy validity period, frequent policy switching caused by short-term fluctuations in energy status can be avoided (for example, keeping the policy stable when the power level fluctuates slightly near the threshold), reducing switching overhead and improving the stability of the upgrade process. This is especially suitable for scenarios with large energy state fluctuations (such as dynamic power consumption devices).

[0049] In one embodiment, when the energy state level changes, the step of determining whether the duration of the change exceeds a preset stability threshold specifically includes the following steps:

[0050] When a change in the energy state level is detected, a timer is started to record the duration of the change;

[0051] Get the stability threshold related to the direction of change of the current energy state level:

[0052] If the energy state level changes from low to high, obtain the first stable threshold ;

[0053] If the energy state level changes from medium to high, obtain the second stable threshold ;

[0054] If the energy state level changes from medium to low, obtain the third stable threshold ;

[0055] If the energy state level changes from high to low, obtain the fourth stable threshold ;

[0056] in, ;

[0057] Compare the duration of the change recorded by the timer with the corresponding stability threshold to determine whether it is exceeded.

[0058] By adopting the above solution, differentiated stability thresholds are set for different energy state change directions (for example, a longer stability threshold is used when the power changes from high to low), thus avoiding frequent strategy switching caused by instantaneous energy fluctuations. At the same time, a more reasonable response speed is provided for the risk level of different change directions (for example, a high→low change may indicate rapid power depletion), further improving the stability of the upgrade process and the accuracy of energy consumption control.

[0059] In one embodiment, during the upgrade process, if the duration of the current energy state level exceeds a preset policy validity period, the step of re-evaluating the energy state and adjusting the upgrade policy parameters specifically includes the following steps:

[0060] When the duration of the current energy status level exceeds the preset policy validity period, the energy status re-evaluation process is triggered;

[0061] Obtain the real-time value of the current energy state parameter and recalculate the comprehensive value of the energy state;

[0062] Compare the recalculated comprehensive value with the preset energy status threshold range to determine whether the energy status level needs to be adjusted;

[0063] If the energy status level needs to be adjusted, the upgrade strategy parameters are adjusted according to the differentiated adjustment strategy corresponding to the current energy status level;

[0064] If the energy status level does not need to be adjusted, but the change rate of the current energy status parameter exceeds the preset change rate threshold, the upgrade strategy parameters are adjusted according to the following rules:

[0065] If the energy consumption rate change rate is greater than the first change rate threshold, shorten the policy validity period;

[0066] If the remaining power percentage change rate is less than the second change rate threshold, the transmission baud rate is reduced.

[0067] By adopting the above solution and introducing a periodic energy state reassessment and parameter change rate response mechanism during the upgrade process, the defect of fixed strategy parameters in the existing technology is solved, so that the system can correct the initial evaluation error in real time, ensure that the strategy and energy state continue to match, and predict the energy fluctuation trend and make adjustments in advance, thereby enhancing system stability. By dynamically adjusting the evaluation frequency and transmission parameters, the optimal balance between energy consumption and efficiency is achieved.

[0068] In one embodiment, the step of transmitting target firmware data to the MCU device through a communication link based on the dynamically adjusted upgrade policy parameters and performing a firmware upgrade operation until the upgrade is completed specifically includes the following steps:

[0069] The protocol identification module detects the currently available communication protocol type in real time, wherein the communication protocol type includes at least one or more of Wi-Fi, CAN bus, Ethernet, and UART;

[0070] Real-time collection of network status parameters, and dynamic updating of a preset energy state-protocol adaptation mapping table based on the real-time collected network status parameters, wherein the mapping table includes unit data transmission energy consumption, transmission rate, and stability parameters of each communication protocol at different energy state levels;

[0071] Based on the current energy state level, the priority of each communication protocol is determined from the dynamically updated preset energy state-protocol adaptation mapping table. The optimal communication protocol is selected based on the determined priority, and the bandwidth parameters are dynamically configured based on the current energy state level:

[0072] When in a high energy state, select the protocol with the highest transmission rate and configure the bandwidth parameter to the highest supported value;

[0073] When in a low energy state, the protocol with the lowest unit energy consumption is selected and the bandwidth parameter is limited to the basic necessary value;

[0074] When in the medium energy state, select a protocol that balances energy consumption and efficiency and keep the bandwidth parameter at the default intermediate value;

[0075] Based on the selected communication protocol, optimized bandwidth parameters and dynamically adjusted upgrade strategy parameters, the target firmware data is transmitted to the MCU device through the communication link, and a firmware upgrade operation is performed until the upgrade is completed.

[0076] By adopting this solution, during the firmware data transmission phase, the optimal communication protocol can be selected and the corresponding bandwidth parameters configured based on the current energy state level and real-time network status through a dynamically updated "energy state-protocol adaptation" mapping table, achieving a precise match between the communication protocol and the energy state. This not only prioritizes low-power protocols in low-energy states to reduce energy consumption, and selects high-speed protocols in high-energy states to improve upgrade efficiency, but also ensures transmission stability through real-time adaptation to network fluctuations. This effectively solves the problem of balancing energy consumption and efficiency in fixed protocol transmission, significantly improving the adaptability and energy efficiency of MCU devices during firmware upgrades in complex network environments.

[0077] In one embodiment, the steps of determining the priority of each communication protocol from a dynamically updated preset energy state-protocol adaptation mapping table based on the current energy state level, selecting the optimal communication protocol according to the determined priority, and dynamically configuring bandwidth parameters based on the current energy state level further include the following steps:

[0078] Through the preset neural network prediction model, based on the real-time collected network status parameter sequence and current energy status level, the network load fluctuation trend within the future preset time period is predicted;

[0079] Dynamically adjust the sub-data block size of the target firmware data based on the predicted network load fluctuation trend and the current energy status level:

[0080] If the predicted network load will increase within a preset time and the current energy state is high, the sub-data block size is reduced to reduce the retransmission energy consumption;

[0081] If the predicted network load remains stable or decreases within the preset time and the current energy state is medium / low, increase the sub-data block size to reduce the number of transmission interactions;

[0082] If the predicted network load fluctuates significantly within the preset time, the sub-block size is kept at the default value to balance stability and energy consumption.

[0083] By adopting this approach, a neural network is introduced to predict network load fluctuations, and the sub-data block size of the target firmware data is dynamically adjusted based on the current energy state level, achieving forward-looking optimization of the transmission strategy. This approach reduces the size of sub-data blocks to reduce retransmission energy consumption when the network load is predicted to increase and energy is sufficient; it also increases the size of sub-data blocks to reduce transmission interaction overhead when the network load is stable / decreasing and energy is limited; and it also maintains the default configuration to balance stability and energy consumption during severe load fluctuations. This solution addresses the problem that traditional fixed sharding strategies are unable to cope with dynamic network changes, enabling the firmware upgrade process to achieve both transmission efficiency, energy control, and stability in complex network environments, further enhancing the practicality and robustness of energy-adaptive firmware upgrade methods.

[0084] This application also relates to an energy-adaptive MCU low-power firmware upgrade system, comprising:

[0085] The data acquisition module is used to establish a communication link between the upgrade initiator and the MCU device, and collect energy status parameters in real time through the energy monitoring terminal built into the MCU device;

[0086] A state classification module, configured to classify the comprehensive value of the energy state parameter into a low energy state, a medium energy state, and a high energy state according to a preset energy state threshold interval;

[0087] A policy adjustment module, configured to dynamically adjust the upgrade policy parameters of the current firmware based on the current energy state level and according to preset adjustment rules, wherein the upgrade policy parameters include transmission parameters, verification parameters, and retransmission policy parameters of the target firmware data;

[0088] The data transmission module is used to transmit the target firmware data to the MCU device through the communication link based on the dynamically adjusted upgrade policy parameters, and perform the firmware upgrade operation until the upgrade is completed.

[0089] The energy-adaptive MCU low-power firmware upgrade method and system provided in the above embodiments have the following beneficial effects:

[0090] 1. The energy monitoring module collects multi-dimensional energy state parameters in real time and comprehensively classifies them, enabling the MCU device to dynamically adapt its upgrade strategy based on the current energy state (low, medium, or high). In low energy states, low-power optimization strategies such as reduced data transmission units, lowered baud rates, extended verification cycles, batch retransmissions, and multi-core sleep significantly reduce energy consumption during the upgrade process, avoiding upgrade interruptions due to low battery conditions. In high energy states, efficiency-focused strategies such as increased transmission units, higher baud rates, shorter verification cycles, immediate retransmissions, and multi-core parallelization enable rapid upgrade completion when sufficient energy is available, balancing reliability and transmission efficiency. In medium energy states, a default strategy is used for smooth transitions. This solution, which builds an adaptive system of "energy state awareness - dynamic policy adjustment - hardware co-optimization," effectively addresses the imbalance between high power consumption, efficiency, and reliability caused by existing technologies that fail to incorporate energy state. It is particularly suitable for battery-powered devices, significantly improving energy efficiency while ensuring the integrity and security of firmware upgrades, extending device life, and increasing upgrade success rates.

[0091] 2. In one embodiment, by introducing a state change stability threshold and a policy validity period, frequent policy switching caused by short-term fluctuations in energy status is avoided (for example, the policy is kept stable when the power level fluctuates slightly near the threshold), reducing switching overhead and improving the stability of the upgrade process. This is particularly suitable for scenarios with large energy status fluctuations (such as dynamic power consumption devices).

[0092] 3. In one embodiment, during the firmware data transmission phase, a dynamically updated "energy state-protocol adaptation" mapping table selects the optimal communication protocol and configures the corresponding bandwidth parameters based on the current energy state level and real-time network status, achieving precise matching of communication protocol and energy state. This not only prioritizes low-power protocols in low-energy states to reduce energy consumption, and selects high-speed protocols in high-energy states to improve upgrade efficiency, but also ensures transmission stability through real-time adaptation to network fluctuations. This effectively solves the energy consumption and efficiency balance issue in fixed-protocol transmission, significantly improving the adaptability and energy efficiency of MCU firmware upgrades in complex network environments.

[0093] 4. In one embodiment, a neural network is introduced to predict network load fluctuations. The sub-data block size of the target firmware data is dynamically adjusted based on the current energy state level, achieving proactive optimization of the transmission strategy. This approach reduces the size of sub-data blocks to reduce retransmission energy consumption when the network load is predicted to increase and energy is sufficient. It also increases the size of sub-data blocks to reduce transmission interaction overhead when the network load is stable or decreasing and energy is limited. Furthermore, it maintains the default configuration during severe load fluctuations to balance stability and energy consumption. This solution addresses the inability of traditional fixed sharding strategies to cope with dynamic network changes. It enables the firmware upgrade process to achieve both transmission efficiency, energy control, and stability in complex network environments, further enhancing the practicality and robustness of the energy-adaptive firmware upgrade method. BRIEF DESCRIPTION OF THE DRAWINGS

[0094] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the structures shown in these drawings without paying any creative work.

[0095] Figure 1 A flowchart of an MCU low-power firmware upgrade method based on energy adaptation provided by an embodiment of the present invention;

[0096] Figure 2 A flowchart for implementing step S200 of an energy-adaptive MCU low-power firmware upgrade method provided in an embodiment of the present invention;

[0097] Figure 3 A flowchart for implementing step S300 of a method for upgrading MCU low-power firmware based on energy adaptation provided by an embodiment of the present invention;

[0098] Figure 4 This is a flowchart of step S400 of an energy-adaptive MCU low-power firmware upgrade method provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0099] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0100] It should be noted that if the embodiments of the present invention involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are only used to explain the relative position relationship, movement status, etc. between the various components under a certain specific posture. If the specific posture changes, the directional indications will also change accordingly.

[0101] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present invention, the descriptions of "first", "second", etc. are only for descriptive purposes and cannot be understood as indicating or suggesting their relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features limited to "first" and "second" may explicitly or implicitly include at least one of such features. In addition, if "and / or" or "and / or" appears in the full text, its meaning includes three parallel solutions. Taking "A and / or B" as an example, it includes solution A, solution B, or solutions that satisfy both A and B. In addition, the technical solutions between the various embodiments can be combined with each other, but it must be based on the ability of ordinary technicians in this field to implement. When the combination of technical solutions is mutually contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0102] This invention is suitable for battery-powered MCU devices (such as IoT terminals, portable medical instruments, and industrial sensor nodes). These devices are limited by their energy supply, and traditional firmware upgrade methods (such as fixed-rate transmission and high-frequency verification) can easily lead to rapid battery depletion or upgrade interruption. The core of this solution is to achieve "real-time energy status sensing and dynamic adjustment of upgrade strategies" to ensure upgrade reliability while minimizing energy consumption.

[0103] Reference Figure 1One embodiment of the present invention provides an MCU low-power firmware upgrade method based on energy adaptation, comprising the steps of:

[0104] S100: Establish a communication link between the upgrade initiator and the MCU device, and collect energy status parameters in real time through the energy monitoring terminal built into the MCU device. The energy status parameters include at least one or more combinations of battery voltage, remaining power percentage, and energy consumption rate;

[0105] S200, dividing the comprehensive value of the energy state parameter into a low energy state, a medium energy state, and a high energy state according to a preset energy state threshold interval;

[0106] S300: Based on the current energy state level, dynamically adjust the upgrade policy parameters of the current firmware according to preset adjustment rules, wherein the upgrade policy parameters include transmission parameters, verification parameters, and retransmission policy parameters of the target firmware data; wherein the adjustment rules include differentiated adjustment strategies for different energy states, including:

[0107] When in a low-energy state, reduce data transmission power consumption, extend the check interval period, configure a non-instant retransmission mechanism, and optimize the multi-core collaboration mode according to the hardware resource status;

[0108] When in a high-energy state, improve data transmission efficiency, shorten the verification interval, configure an instant retransmission mechanism, and activate multi-core collaborative mode based on hardware resource status;

[0109] S400: Based on the dynamically adjusted upgrade policy parameters, transmit the target firmware data to the MCU device through the communication link, and perform the firmware upgrade operation until the upgrade is completed.

[0110] As described in step S100 above, the upgrade initiator (e.g., industrial gateway, host computer) and the MCU device establish a connection via a compatible communication protocol (e.g., Wi-Fi, BLE, CAN bus, UART, etc.), forming a stable communication link. Simultaneously, the MCU device uses a built-in energy monitoring terminal (e.g., an integrated ADC module or an external fuel gauge chip) to collect energy status parameters in real time. These parameters include: battery voltage (obtained through ADC sampling, reflecting the battery's current output capacity), remaining battery percentage (calculated by combining the battery discharge curve or directly output by the fuel gauge, reflecting the remaining energy), and energy consumption rate (calculated by combining the difference in battery power between consecutive samples and the time interval, reflecting the rate of energy consumption). The collected parameters are digitally filtered (e.g., sliding average) to remove noise and prevent instantaneous fluctuations from affecting judgment. This multi-dimensional parameter collection prevents misjudgment of a single parameter due to transient load interference, providing accurate and comprehensive basic data for subsequent energy status assessment and ensuring accurate energy perception.

[0111] As described in step S200 above, based on the energy state parameters collected in step S100, the energy state is classified into different levels using preset energy state threshold intervals. The threshold intervals need to be pre-set in combination with the battery type (e.g., lithium battery, dry cell), application scenario (e.g., industrial control, IoT terminal), and energy characteristics of the MCU device. For example, for a 3.7V lithium battery (other types can be converted proportionally), the following can be set: "remaining power ≤ 30%, battery voltage ≤ 3.3V, energy consumption rate > 5mA / h" for a low energy state; "30% < remaining power < 70%, 3.3V < battery voltage < 3.6V, 2mA / h ≤ energy consumption rate ≤ 5mA / h" for a medium energy state; and "remaining power ≥ 70%, battery voltage ≥ 3.6V, energy consumption rate < 2mA / h" for a high energy state. The calculation of the comprehensive parameter value requires weighted fusion or priority determination of multi-dimensional parameters (e.g., prioritizing the remaining power percentage as the primary criterion and the voltage value as the auxiliary criterion) to ensure that the classification can accurately reflect the energy abundance of the device. By quantifying continuous energy parameters into discrete state levels, a clear and executable judgment basis is provided for the differentiated adjustment of subsequent upgrade strategies, avoiding frequent strategy switching.

[0112] It should be noted that when the remaining power, voltage, and energy consumption rate judgment results conflict (for example, the remaining power is 40% but the voltage is 3.2V), the following priority is used:

[0113] Prioritize the remaining power percentage (the remaining power directly output by the power meter is the most intuitive representation of the energy status);

[0114] Voltage value as a correction factor: If the voltage is lower than the corresponding state threshold (e.g., voltage < 3.3V at medium power), the energy state is downgraded by one level (e.g., from medium energy to low energy) to avoid false high voltage judgments due to battery aging;

[0115] The energy consumption rate is used as a dynamic adjustment factor: If the energy consumption rate exceeds the upper limit of the corresponding state (for example, the rate is greater than 5mA / h when the power is medium), the policy parameters are temporarily tightened (for example, the calibration interval of the low energy state is adopted) to prevent high-energy consumption operations from exacerbating power consumption.

[0116] Example 1: Conflict between remaining power and voltage:

[0117] Collection parameters: Remaining power 40% (corresponding to medium energy state), battery voltage 3.2V (the low energy voltage threshold of a 3.7V lithium battery is ≤3.3V), energy consumption rate 3mA / h (medium energy rate range 2-5mA / h).

[0118] Conflict point: 40% of the remaining power is considered medium energy, but the voltage is 3.2V < 3.3V (low energy voltage threshold).

[0119] Determination process:

[0120] Initially, the remaining power is determined to be 40% as the medium energy state;

[0121] The voltage value of 3.2V is less than the lower limit of 3.3V for medium energy voltage, which triggers the "voltage correction item" and lowers the energy state by one level, ultimately determining it as low energy state;

[0122] The energy consumption rate of 3mA / h is in the medium energy range and no additional adjustments are required.

[0123] Strategy application: Execute low-energy state parameters (such as reducing sub-data blocks and extending the verification interval) to avoid upgrade interruptions due to battery aging (low voltage).

[0124] Example 2: Conflict between remaining power and energy consumption rate:

[0125] Collection parameters: remaining power 60% (medium energy state), battery voltage 3.5V (medium energy voltage range 3.3-3.6V), energy consumption rate 6mA / h (medium energy rate upper limit is 5mA / h).

[0126] Conflict point: 60% of the remaining power is considered medium energy, but the energy consumption rate of 6mA / h is greater than 5mA / h (exceeding the medium energy rate limit).

[0127] Determination process:

[0128] The remaining power of 60% is considered as medium energy state;

[0129] The voltage of 3.5V is in the medium energy range and no correction is required;

[0130] When the energy consumption rate is 6mA / h > 5mA / h, the "dynamic adjustment factor of energy consumption rate" is triggered, temporarily tightening the policy parameters.

[0131] Strategy application: Basic parameters remain configured for medium energy (such as 512-byte sub-data blocks and 57,600 bps baud rate), but the check interval is extended from the default 50 ms to 100 ms (the check interval for low energy state) to reduce the rapid power consumption caused by high-energy operations (such as high-frequency checks).

[0132] Example 3: All three parameters conflict:

[0133] Collection parameters: remaining power 75% (high energy state), battery voltage 3.4V (medium energy voltage range), energy consumption rate 7mA / h (high energy rate upper limit is 2mA / h).

[0134] Conflict point: The remaining power is 75% of high energy, but the voltage is 3.4V (medium energy) and the rate is 7mA / h (far exceeding the high energy limit).

[0135] Determination process:

[0136] Initially, the remaining power is determined to be 75% as a high energy state;

[0137] When the voltage is 3.4V and lower than the high energy voltage limit of 3.6V, a correction is triggered, and the energy level is lowered to the medium energy state;

[0138] When the energy consumption rate is 7mA / h and exceeds the medium energy limit of 5mA / h, dynamic adjustment is triggered and the strategy is further tightened.

[0139] Strategy application: Use medium-energy basic parameters (such as 512-byte sub-data blocks) but enable a low-energy retransmission strategy (batch retransmission after three cumulative packet losses) to balance efficiency and energy consumption, and avoid high-energy operations (such as immediate retransmission) that increase power consumption.

[0140] As can be seen from the above example, the priority rules when multiple parameters conflict are based on the remaining power as the core benchmark, and voltage correction is used to avoid misjudgments caused by battery aging. The energy consumption rate is dynamically adjusted to prevent excessive power consumption under high load, ultimately achieving accurate energy status judgment and flexible strategy adjustment.

[0141] As described in step S300 above, based on the current energy state level determined in step S200, the upgrade strategy parameters are dynamically adjusted according to preset rules:

[0142] Transmission parameters: including communication protocol (e.g., BLE for low energy, Wi-Fi for high energy), transmission rate (e.g., lower baud rate for low energy), sub-data block size (e.g., reduce fragment length for low energy);

[0143] Verification parameters: including verification algorithm (e.g., lightweight CRC32 for low energy, high-strength SHA256 for high energy), verification interval (e.g., extended interval for low energy);

[0144] Retransmission strategy parameters: including retransmission trigger conditions (such as retransmission after cumulative packet loss when energy is low), retransmission wait time (such as extending the wait time when energy is low), and maximum number of retransmissions (such as reducing the number when energy is low).

[0145] Multi-core collaboration: Optimize the number of cores (such as shutting down redundant cores) when energy is low, and activate multi-core parallel processing when energy is high.

[0146] Through differentiated adjustments for different energy states, priority is given to controlling energy consumption in low energy states to ensure device endurance, and priority is given to improving efficiency in high energy states to shorten upgrade time, thus achieving a dynamic balance between energy consumption and efficiency and solving the problem that traditional fixed strategies cannot adapt to energy fluctuations.

[0147] As described in step S400 above, based on the upgrade policy parameters adjusted in step S300, the firmware upgrade is performed through the established communication link: the upgrade initiator splits the target firmware data according to the adjusted sub-data block size and sends it according to the transmission rate and protocol; after the MCU device receives the data, it performs verification according to the verification parameters (such as triggering verification according to the interval period), and after the verification passes, the data is written to the flash memory (using batch writing to reduce erase and write energy consumption), and the upgrade progress is fed back to the initiator as needed; after all data transmission is completed, the firmware integrity check is performed (such as comparing the hash value of the entire package), and if the verification passes, the firmware is updated and restarted, and if it fails, it rolls back to the original firmware. By adapting the transmission and execution mechanism to the energy state, it is ensured that the upgrade can be completed reliably under different energy conditions, avoiding upgrade interruptions due to excessive energy consumption during low energy conditions, or wasting resources due to inefficiency during high energy conditions.

[0148] In one feasible embodiment, assume that an IoT terminal uses an STM32L051 MCU (powered by a 3.0V button battery and supporting BLE and UART communication) and needs to upgrade 16KB of sensor firmware through a gateway:

[0149] Step S100: The gateway and the MCU establish a communication link via BLE (the broadcast interval is set to 2 seconds to reduce connection energy consumption). The MCU collects parameters every 200ms using the built-in ADC: battery voltage 2.8V (corresponding to 25% remaining power), energy consumption rate 0.5mA / h, and the data is stored after sliding filtering.

[0150] Step S200: According to a preset threshold (remaining power ≤ 30% is low energy), it is determined that the current state is low energy.

[0151] Step S300: In the low-energy state, adjust the policy parameters as follows: select BLE as the transmission protocol (discard the high-power UART), reduce the transmission rate to the lowest BLE rate (125kbps), and set the sub-data block size to 256 bytes; use CRC32 as the verification algorithm, and extend the verification interval to once every 8 sub-blocks; the retransmission strategy is to retransmit after 4 cumulative packet losses, with a waiting time of 500ms and a maximum retransmission number of 2 times; turn off the MCU's backup core and keep only one core working.

[0152] Step S400: The gateway splits the firmware into 64 sub-blocks of 256 bytes and transmits them according to the adjusted parameters; the MCU performs a CRC32 check every time it receives 8 sub-blocks, and writes them to the flash memory in batches after passing the check (once for every 4 sub-blocks). A 1-byte feedback is sent to the gateway every time 50% of the progress is completed; after all the transmissions are completed, the firmware CRC32 value is calculated to be consistent with the pre-stored value in the gateway, confirming that the upgrade is successful, and the system restarts to load the new firmware.

[0153] In one embodiment:

[0154] When in a low energy state, specifically:

[0155] Dividing the target firmware data into sub-data blocks no larger than a preset minimum data transmission unit, thereby reducing the transmission baud rate of the communication link;

[0156] Extend the time interval between two adjacent verification operations to the preset maximum verification period;

[0157] Configure the retransmission policy to trigger batch retransmission when the cumulative number of errors reaches N, where N ≥ 2.

[0158] If the communication link includes multi-core hardware resources, configuring the multi-core hardware resources to enter a single-core working mode, and the non-main core units to enter a dormant state;

[0159] When in a high energy state, specifically:

[0160] Dividing the target firmware data into sub-data blocks no smaller than a preset maximum data transmission unit, thereby increasing the transmission baud rate of the communication link;

[0161] Shorten the time interval between two adjacent verification operations to the preset minimum verification period;

[0162] Configure the retransmission policy to immediate single-packet retransmission;

[0163] If the communication link includes multi-core hardware resources, waking up the multi-core hardware resources to process data transmission and verification operations in parallel;

[0164] When in the medium energy state, the preset default transmission unit, default baud rate, default check period and default retransmission strategy are used.

[0165] In this embodiment:

[0166] (1) Specific adjustment strategies for low energy state:

[0167] For example, when the MCU device is in a low-energy state with a remaining battery level ≤ 30% (or the equivalent voltage / energy consumption rate threshold), with minimizing energy consumption as the core goal, adjust the upgrade policy parameters in the following ways:

[0168] Sub-data block division: The target firmware data is divided into sub-data blocks no larger than the preset minimum data transmission unit (for example, the preset minimum data transmission unit is 128 bytes). This transmission unit size is combined with the optimal transmission frame length setting of low-power communication protocols (such as BLE and UART) to avoid a surge in energy consumption in a single transmission due to excessively large data blocks. For example, the MTU (maximum transmission unit) of BLE is typically 23 bytes. In actual applications, the sub-data block can be set to 64 bytes (3 MTU payloads), ensuring that energy consumption per single transmission is reduced in low-power mode.

[0169] Baud rate adjustment: Reduces the baud rate of the communication link to a preset low-power baud rate. For example, for a UART communication link, you can directly reduce the baud rate from the default 115200 bps to 9600 bps; for a Wi-Fi communication link, you can directly reduce the baud rate from the default 54 Mbps to 11 Mbps.

[0170] Extend the verification cycle: Extend the time interval between two adjacent verification operations to the preset maximum verification cycle (for example, from the default 50ms to 200ms), and reduce the computational complexity of a single verification (for example, only verify the CRC8 of the data frame header instead of the CRC32 of the entire frame) to avoid frequent MCU wake-up caused by high-frequency verification.

[0171] Retransmission policy configuration: A batch retransmission mechanism is triggered by the cumulative number of errors (N ≥ 2, for example, N = 3). This mechanism requests retransmission of all erroneous data at once when N consecutive sub-blocks fail to be received, rather than retransmitting each one individually. For example, after three cumulative packet losses, the MCU sends a batch retransmission command containing the error packet number, which reduces control frame interaction energy consumption compared to immediate single-packet retransmission.

[0172] Multi-core resource optimization: If the MCU has a multi-core architecture (such as the XMOS XU208), the clock signals of non-main cores are turned off through the power management module, causing the non-main core units to enter a deep sleep state (such as the STOP mode of the ARM Cortex-M, which reduces power consumption to the μA level). Only one main core is retained to handle data reception and basic verification. Compared with the full-core mode, this reduces static power consumption to a certain extent.

[0173] (2) Specific adjustment strategies for high energy states:

[0174] For example, when the MCU device is in a high-energy state with a remaining battery level of ≥ 70% (or an equivalent threshold), with maximizing transmission efficiency as the core goal, adjust the upgrade policy parameters in the following ways:

[0175] Sub-data block division: Divide the target firmware data into sub-data blocks that are no smaller than the preset maximum data transmission unit (for example, the preset maximum unit is 2048 bytes). This unit size matches the maximum transmission unit (MTU) of high-speed communication protocols (such as Ethernet and CAN FD). For example, if the Ethernet MTU is 1500 bytes, the actual sub-data block is set to 1400 bytes. This reduces the protocol overhead caused by data fragmentation and improves the payload rate of a single transmission.

[0176] Baud rate adjustment: Increase the baud rate of the communication link to the maximum rate supported by the protocol. For example, for a UART communication link, directly increase the baud rate from the default 9600 bps to 115200 bps. For a Wi-Fi communication link, directly increase the baud rate from the default 11 Mbps to 54 Mbps and enable the protocol's high-speed mode (such as the 40 MHz channel bandwidth of Wi-Fi's 802.11n).

[0177] Shortened verification cycle: The time interval between two adjacent verification operations is shortened to the preset minimum verification cycle (for example, from the default 50ms to 10ms), and a high-strength verification algorithm is adopted (such as SHA256 instead of CRC32) to ensure high-frequency and high-reliability real-time verification, reducing the risk of full retransmission due to data errors.

[0178] Retransmission strategy configuration: Adopts an immediate single-packet retransmission mechanism. That is, once a sub-data block verification failure is detected (such as through ACK / NACK feedback), a single-packet retransmission request is immediately triggered. The retransmission wait time is set to the minimum response interval of the protocol (such as 50μs for Ethernet), giving priority to ensuring the real-time performance of data transmission. It is suitable for scenarios that are sensitive to upgrade time in high-energy states (such as the need for rapid restart of industrial equipment).

[0179] Multi-core resource activation: If the MCU has a multi-core architecture, the task scheduler will assign data transmission, verification, flash memory write and other operations to different cores for parallel processing (for example, core 1 is responsible for receiving data, core 2 is responsible for SHA256 verification, and core 3 pre-reads the next packet of data), utilizing the multi-core parallel computing capabilities to improve overall processing efficiency.

[0180] (3) Default adjustment strategy for medium energy state:

[0181] When the MCU device is in a medium energy state (30% < remaining power < 70%), the preset default strategy is used to balance energy consumption and efficiency. The specific parameters are set as follows:

[0182] Sub-data block size: Take the middle value between the preset minimum and maximum units (e.g. 512 bytes), compatible with the standard MTU of most communication protocols (e.g. 8 bytes × 64 frames = 512 bytes for CAN bus);

[0183] Transmission baud rate: Use a medium rate for the protocol (such as UART 57600bps, Wi-Fi 2.4GHz 11Mbps), taking into account both transmission speed and power consumption;

[0184] Verification period: The default verification interval is set to 50ms, using the CRC32 algorithm to achieve a balance between reliability and computing energy consumption;

[0185] Retransmission strategy: Configure the system to trigger retransmission after two cumulative packet losses, with a retransmission wait time of 100ms. This avoids both the high-frequency interaction of immediate retransmissions and the accumulation of delays in batch retransmissions.

[0186] Multi-core resources: For multi-core MCUs, only the necessary cores are awakened (for example, one of two cores is operational), and non-operating cores enter standby mode (rather than deep sleep) to quickly respond to possible load changes.

[0187] Through the above-mentioned differentiation strategy, the adjustment rules are concretized into quantifiable and executable parameter configurations, so that the upgrade process under different energy states can maintain a dynamic balance between energy consumption and efficiency. It is especially suitable for power-sensitive embedded devices and time-sensitive industrial control equipment.

[0188] In one embodiment:

[0189] The transmission parameters of the target firmware data include the complete target firmware or a fragmentation strategy based on the difference data between the target firmware and the current firmware, wherein the difference data includes one or more combinations of incremental data, modified data, and non-overlapping data segments calculated by a differential algorithm;

[0190] The sub-data blocks are generated based on the difference data, and the sharding strategy is used to determine the size and number of the sub-data blocks;

[0191] Among them, the sharding strategy based on the difference data between the target firmware and the current firmware is preferentially adopted in the low energy state to reduce transmission power consumption.

[0192] In this embodiment:

[0193] (1) Types and generation methods of difference data.

[0194] For incremental data:

[0195] Only the newly added code segments or configuration parameters in the target firmware (such as version number updates and new functional modules) are transferred. By comparing the file directories of the current firmware with the target firmware, the binary data of the newly added files is generated (such as the incremental part of the RPM package in the Linux system upgrade).

[0196] For modifying data:

[0197] Only the modified code segments or data blocks (such as vulnerability-fixing functions and parameter-adjusted configuration files) are transmitted. The area where the hash value changes in the firmware is located through hash verification (such as SHA256), and the difference byte sequence before and after the modification is extracted.

[0198] For non-overlapping data segments:

[0199] For update areas in the firmware where the address space does not overlap (such as independent partitions during bootloader upgrades, and isolated updates of application and data partitions), directly extract the independent data segments of the corresponding partitions in the target firmware (such as only updating the bootloader area at Flash address 0x8000000-0x8002000).

[0200] (2) Implementation of sharding strategy based on differential data.

[0201] For sub-data block generation logic:

[0202] The difference data is divided into sub-data blocks according to the following rules:

[0203] Low-energy state: The sub-data block size is ≤ the preset minimum transmission unit (e.g., 128 bytes) to ensure the lowest energy consumption for a single transmission. For example, the difference data is divided into N blocks of 128 bytes, and each block is appended with a 1-byte block number and a 1-byte CRC8 checksum, for a total length of 130 bytes (compliant with the BLE MTU limit).

[0204] Medium / high energy state: The sub-data block size is dynamically adjusted based on the transport protocol MTU (for example, 1400 bytes when the Wi-Fi MTU is 1500 bytes), reducing the number of fragments to improve efficiency.

[0205] Priority control for differential sharding strategies:

[0206] Low energy state is forced to enable:

[0207] When the energy level is low (remaining battery ≤ 30%), differential data transmission is preferred over full firmware transmission, regardless of the size of the firmware differences. For example, even if the target firmware differs by 90% from the current firmware, the differential portion is extracted using a differential algorithm (avoiding the transmission of a 100% complete firmware) and fragmented into the smallest possible chunk size, reducing the data volume by over 80% compared to a full firmware transmission.

[0208] Medium / high energy state optional:

[0209] In medium energy mode, if the differential data volume is less than 50% of the full firmware, differential sharding is used; otherwise, full firmware sharding is used (to prevent the computational energy consumption of the differential algorithm from exceeding the energy saved by transmission). In high energy mode, full firmware sharding (4096-byte block transmission) is used by default, and differential sharding is enabled only when the user configures "Fast Upgrade".

[0210] (3) Energy consumption optimization mechanism for differential data transmission.

[0211] Exclusive optimization for low energy state:

[0212] Differential algorithm selection: Prioritize lightweight differential algorithms (such as xdelta3's fast mode) to reduce the CPU time consumed by the MCU in calculating difference data (reducing calculation cycles by 30% compared to bsdiff) and avoid additional energy consumption caused by complex calculations.

[0213] Simplified fragment verification: For the difference sub-data blocks, only the CRC32 of the difference part is verified (rather than the hash of the entire packet), which reduces the verification time by 50% compared to the complete firmware. Combined with the extended verification interval (such as the low-energy verification strategy mentioned above), computing power consumption is further reduced.

[0214] Retransmission strategy adaptation: If a sub-block fails to transmit, only the corresponding differential fragment of the block (rather than the entire firmware package) is retransmitted, reducing the amount of retransmitted data by over 90% compared to the complete firmware (for example, if a 128-byte block fails, only 130 bytes need to be retransmitted, rather than the 1MB of the complete firmware).

[0215] Collaborative logic with energy state:

[0216] Dynamic adjustment of data volume threshold:

[0217] In low-energy state, the difference data volume threshold is set to 200KB (if exceeded, it will be upgraded in batches); in high-energy state, the threshold is increased to 2MB (allowing larger difference packages to be transmitted at one time).

[0218] Hardware resource allocation:

[0219] When processing difference data, if the MCU is a multi-core architecture (such as XMOS XU316), only one core is used to perform difference calculations in the low-energy state, and the other cores remain dormant; in the high-energy state, two cores are enabled to calculate differences and shards in parallel, increasing the processing speed by more than 3 times.

[0220] (4) The switching logic between complete firmware and differential sharding is as follows:

[0221]

[0222] Reference Figure 2 In one embodiment, step S200 specifically includes the following steps:

[0223] S210, presetting a weight coefficient for each energy state parameter, wherein the weight coefficient is set according to the degree of influence of the parameter on the energy state;

[0224] S220, normalizing the battery voltage value, remaining power percentage, and energy consumption rate collected in real time to obtain standardized values ​​of each parameter;

[0225] S230, calculating a comprehensive value of the energy state parameter by weighted summation based on the weight coefficient and the normalized value;

[0226] The low energy threshold, medium energy threshold and high energy threshold are preset to form the energy state threshold range:

[0227] If the comprehensive value is ≤ the low energy threshold, it is determined to be in a low energy state;

[0228] If the low energy threshold < comprehensive value ≤ medium energy threshold, it is determined to be a medium energy state;

[0229] If the comprehensive value is greater than the medium energy threshold, it is determined to be a high energy state.

[0230] In this embodiment:

[0231] As described in step S210 above, a quantitative evaluation system for multi-dimensional parameters is constructed by presetting weight coefficients for each energy status parameter. Specifically, weight coefficients of 0.3, 0.5, and 0.2 are assigned, respectively, based on the degree of influence of the battery voltage, remaining charge percentage, and energy consumption rate on the energy status. The remaining charge percentage, as the core indicator, directly reflects the absolute level of available battery capacity and holds the largest weight. The battery voltage serves as an auxiliary criterion, identifying voltage drops caused by battery aging or abnormal loads to avoid misjudgments based on a single charge percentage. The energy consumption rate, as a dynamic adjustment factor, reflects the device's current energy consumption rate and is used to predict power consumption trends. These weight coefficients are determined by fitting extensive experimental data (e.g., initial weights are determined through battery charge and discharge tests at the factory) and can be dynamically adjusted through OTA updates to adapt to different hardware platforms and application scenarios (e.g., solar-powered devices can increase the voltage parameter weight to 0.4).

[0232] As described in step S220 above, the real-time collected battery voltage, remaining charge percentage, and energy consumption rate are normalized to eliminate the impact of different dimensional parameters on the comprehensive calculation. Specifically, the remaining charge percentage is directly mapped to a standardized value in the 0-1 range (e.g., SOC = 50% corresponds to 0.5); based on the preset full-charge voltage and low-charge cutoff voltage of the battery type, the battery voltage value is linearly mapped to the 0-1 range (e.g., a 3.7V lithium battery voltage of 3.5V corresponds to a standardized value of 0.5); and for the energy consumption rate, which is negatively correlated with the energy state, an inverse mapping method is used (e.g., CR = 4mA / h corresponds to a standardized value of 0.2). Furthermore, boundary processing is performed on abnormal parameter values ​​(e.g., SOC > 100% or voltage > full-charge voltage) to ensure the validity and reliability of the standardized values.

[0233] As described in step S230 above, based on the preset weight coefficient and the normalized parameter value, the comprehensive value of the energy state parameter is calculated by weighted summation and compared with the preset threshold range to determine the specific energy state. The specific calculation process is: comprehensive value = 0.5×SOC normalized value + 0.3×voltage normalized value + 0.2×energy consumption rate normalized value. The preset low energy threshold is 0.3 and the medium energy threshold is 0.7, forming a three-level energy state determination interval. If the comprehensive value ≤ 0.3, it is determined to be a low energy state; if 0.3 < comprehensive value ≤ 0.7, it is determined to be a medium energy state; if the comprehensive value > 0.7, it is determined to be a high energy state. This determination mechanism also includes a dynamic threshold correction function, which is ±0.05 according to the environmental conditions, such as lowering the low energy threshold to 0.25 in a low temperature environment, and adjusting the weight distribution and threshold range for external power supply equipment to ensure that the true energy state of the equipment can be accurately reflected under different working conditions.

[0234] Reference Figure 3 In one embodiment, in step S300, dynamically adjusting the upgrade policy parameters of the current firmware specifically includes the following steps:

[0235] S310, real-time monitoring of the duration of the current energy state level;

[0236] S320: When the energy state level changes, determine whether the duration of the change exceeds a preset stability threshold:

[0237] If so, switch to the corresponding adjustment strategy according to the new energy state level;

[0238] If not, maintain the current adjustment strategy;

[0239] S330: During the upgrade process, if the duration of the current energy status level exceeds the preset policy validity period, the energy status is re-evaluated and the upgrade policy parameters are adjusted.

[0240] In this embodiment:

[0241] As described in step S310 above, by real-time monitoring of the duration of the current energy state level, a dynamic time dimension criterion is provided for policy adjustment. In specific implementation, a state timer (such as a 16-bit hardware timer or software counter) is maintained inside the MCU. When the energy state level (low / medium / high) is determined, the timing is started. Each time the state changes, the timer is reset and the duration of the historical state is recorded. For example, when switching from a low energy state to a medium energy state, the low energy timer is stopped immediately, and the medium energy timer is started. The duration of each state is accurately recorded to provide a data basis for subsequent stability judgment and policy effectiveness cycle evaluation. This monitoring mechanism supports millisecond-level precision timing to meet the real-time response requirements for scenarios with rapid changes in energy states.

[0242] As described in step S320 above, by determining whether the duration of the energy state level change exceeds a preset stability threshold, frequent strategy switching due to instantaneous fluctuations is avoided. Specifically, a stability threshold is preset (such as 5 minutes). When the energy state level changes (such as from low energy to medium energy), a stability timer is started. If the duration of the new state is ≥ the stability threshold, the state change is determined to be a valid switch, triggering the corresponding adjustment strategy (such as switching from low-energy small data block transmission to the default block size of medium energy); if the duration is < the stability threshold (such as dropping back to low energy after 2 minutes), it is determined to be an unstable fluctuation, and the current strategy is maintained (continue to use the low-energy strategy). For example, in a vehicle environment, the battery voltage may fluctuate for a short time due to engine startup. By filtering with a stability threshold, it can be prevented from being misjudged as a high-energy state due to a transient voltage increase, resulting in unnecessary high-speed transmission strategy switching, thereby avoiding the additional energy consumption and control complexity caused by frequent adjustments.

[0243] As described in step S330 above, this step re-evaluates the policy for scenarios that remain in the same energy state for extended periods of time, based on a preset policy validity period (e.g., 30 minutes), to ensure that the upgraded policy is compatible with the sustained energy state. Specifically, when a given energy state level persists for longer than the validity period (e.g., a low energy state persists for 40 minutes), a mandatory energy state re-evaluation is triggered: the battery voltage, remaining charge, and energy consumption rate are re-collected, a comprehensive value is calculated, and the current state is determined (to prevent misjudgment of the state due to accumulated fuel gauge errors). If the state remains unchanged, the policy parameters are further optimized based on the extended duration (e.g., in a low energy state, the sub-data block size is reduced from 128 bytes to 64 bytes to further reduce transmission power consumption). If the state has changed, the policy is switched according to the logic in step S320. This mechanism is particularly suitable for scenarios with long-term stable energy states (e.g., IoT sensors in low-battery standby mode). This periodic policy re-evaluation avoids inefficient upgrades or excessive power consumption caused by a mismatch between initial policy parameters and long-term energy consumption, thereby ensuring the long-term effectiveness and reliability of dynamic adjustments.

[0244] In one embodiment, step S320 specifically includes the following steps:

[0245] S321. When a change in the energy state level is detected, start a timer to record the duration of the change;

[0246] S322. Obtain a stability threshold value related to the change direction of the current energy state level:

[0247] If the energy state level changes from low to high, obtain the first stable threshold ;

[0248] If the energy state level changes from medium to high, obtain the second stable threshold ;

[0249] If the energy state level changes from medium to low, obtain the third stable threshold ;

[0250] If the energy state level changes from high to low, obtain the fourth stable threshold ;

[0251] in, ;

[0252] S323: Compare the change duration recorded by the timer with the corresponding stability threshold to determine whether it exceeds the threshold.

[0253] In this embodiment:

[0254] As described in step S321 above, a hardware timer or software timing module immediately initiates the timing function upon detecting a change in energy state level, accurately recording the duration of the state change. Specifically, when the MCU determines a state change (e.g., switching from medium energy to high energy) through an energy state assessment algorithm (e.g., the aforementioned weighted summation), it immediately triggers a timer reset and begins accumulating the timing value (e.g., a millisecond-level counter based on the SysTick interrupt) until the state changes again or the stability threshold condition is met. This timer uses a non-blocking design, and during the timing process, it does not affect the main program's execution of core functions such as data transmission and verification, ensuring the continuity of the upgrade process.

[0255] As described in step S322 above, for different energy state change directions, differentiated stability threshold parameters are preset to form The threshold gradient system. When it is implemented specifically: ① When the state changes from low to high (such as battery recovery), the minimum first stable threshold is obtained (e.g. 1 minute) to quickly respond to energy improvements and enable high-speed transmission strategies in a timely manner; ② When the state changes from medium to high, obtain the second stable threshold (e.g. 3 minutes), balancing strategy switching speed and stability; ③ When the state changes from medium to low, obtain the third stable threshold (e.g. 5 minutes) to avoid false triggering of low power consumption strategy due to short-term power consumption fluctuations; ④ When the state changes from high to low (e.g. power drops suddenly), obtain the maximum fourth stable threshold The system maintains an effective upgrade strategy before actually entering a low-energy state. These threshold parameters are stored in non-volatile memory and can be dynamically adjusted via OTA updates to suit different application scenarios.

[0256] As described in step S323 above, the duration of the change recorded by the timer is compared with the stability threshold of the corresponding direction in real time, and whether to execute the policy switch is determined based on the comparison result. The specific logic is: when the timer value ≥ the corresponding threshold (e.g., the change from high to low lasts for 12 minutes ≥ = 10 minutes, the state change is determined to be stable and effective, triggering the switch of the upgrade policy parameters (such as reducing the transmission from high-energy 4096-byte blocks to low-energy 128-byte blocks); if the timer value is less than the threshold (such as the change from medium to high lasts only 2 minutes < =3 minutes), it is considered a temporary fluctuation and the current policy will continue to be used. This comparison process is performed every millisecond to ensure a rapid response to state changes. At the same time, the threshold filtering mechanism avoids the system overhead caused by frequent policy switching, achieving a dynamic balance between upgrade efficiency and energy consumption.

[0257] In one embodiment, step S330 specifically includes the following steps:

[0258] S331. When the duration of the current energy state level exceeds the preset policy validity period, the energy state reassessment process is triggered;

[0259] S332, obtaining the real-time value of the current energy state parameter and recalculating the energy state comprehensive value;

[0260] S333: Compare the recalculated comprehensive value with the preset energy state threshold range to determine whether the energy state level needs to be adjusted;

[0261] S333a. If the energy state level needs to be adjusted, the upgrade strategy parameters are adjusted according to the differentiated adjustment strategy corresponding to the current energy state level;

[0262] S333b. If the energy state level does not need to be adjusted, but the change rate of the current energy state parameter exceeds the preset change rate threshold, the upgrade strategy parameters are adjusted according to the following rules:

[0263] If the energy consumption rate change rate is greater than the first change rate threshold, shorten the policy validity period;

[0264] If the remaining power percentage change rate is less than the second change rate threshold, the transmission baud rate is reduced.

[0265] In this embodiment:

[0266] As described in step S331 above, by monitoring the duration of the energy state level in real time, when it exceeds the preset policy validity period (such as the low energy state lasting 30 minutes), the energy state re-evaluation process is actively triggered. In specific implementation, a periodic timer (such as a minute-level timer based on RTC) is maintained inside the MCU. When the duration of a certain energy state level reaches the preset period, the current upgrade task is immediately suspended (such as pausing data transmission) and the state re-evaluation process is started to ensure that the policy parameters continue to match the current actual energy state of the device. This mechanism avoids the problem of unreasonable energy consumption caused by the long-term use of fixed strategies (such as using medium baud rate transmission for a long time in a low energy state), and is particularly suitable for IoT devices with limited battery capacity.

[0267] As described in step S332 above, after the re-evaluation process is triggered, the real-time values ​​of the battery voltage, remaining power percentage, and energy consumption rate are re-collected, and the energy status comprehensive value is calculated through the weighted summation mentioned above. In specific implementation, the battery voltage is obtained through ADC sampling (such as 12-bit ADC converted to 0-3.3V actual value), the remaining power is read through the fuel gauge chip (such as the percentage value output by MAX17043), and the energy consumption rate is calculated based on the difference between the power values ​​of two consecutive samples (such as These three parameters are then substituted into the comprehensive value formula: comprehensive value = 0.5 × SOC normalized value + 0.3 × voltage normalized value + 0.2 × energy consumption rate normalized value to obtain the updated energy state quantitative index, which provides a data basis for subsequent threshold comparison.

[0268] As described in step S333 above, the recalculated comprehensive value is compared with the previously defined threshold range (low energy ≤ 0.3, 0.3 < medium energy ≤ 0.7, high energy > 0.7) to determine whether the energy state level needs to be adjusted. For example, if the original state was medium energy (comprehensive value 0.5), and the reassessed comprehensive value drops to 0.28, then a low energy state is determined to be necessary. This comparison process utilizes double-precision floating-point arithmetic to ensure a minimum of 6 decimal places, thus avoiding misjudgments due to computational errors. If a state level adjustment is required, the logic in step S333a is executed to adjust the upgrade parameters based on the differentiation strategy corresponding to the new state (such as the aforementioned baud rate adjustment and sharding strategy). If a state level adjustment is not required, the process proceeds to the rate of change determination logic in step S333b.

[0269] As described in step S333b above, when the state level remains unchanged but the parameter change rate exceeds the threshold, a refined strategy adjustment is implemented. The specific rules are: ① If the energy consumption rate change rate is greater than the first change rate threshold (such as 0.5mA / , indicating that the hourly energy consumption growth rate exceeds 0.5mA), indicating that the device is entering a high-load state and power consumption is accelerating. In this case, shorten the policy implementation period (for example, from 30 minutes to 15 minutes) and increase the state reassessment frequency to promptly respond to energy changes. ② If the remaining power percentage change rate is less than the second change rate threshold (for example, -2% / h, indicating that the power drops by more than 2% per hour), it indicates that the battery is discharging too quickly. In this case, reduce the transmission baud rate (for example, from 115200bps to 57600bps) to reduce energy consumption per unit time. These change rate thresholds are determined through load testing before the device leaves the factory and stored in the firmware configuration area. They can be dynamically adjusted through OTA updates.

[0270] Through the above implementation, a closed-loop policy adaptation mechanism has been established: periodic reassessment ensures the accuracy of state judgment, and rate-of-change monitoring enables dynamic parameter fine-tuning. This avoids the energy consumption drawbacks of long-term fixed policy use while also preventing policy oscillation caused by frequent state fluctuations, ultimately achieving an optimal balance between upgrade efficiency and energy consumption. In practical applications, this mechanism can reduce the energy consumption of firmware upgrades for battery-powered devices, significantly extending the device's usable life on a single charge.

[0271] Reference Figure 4 In one embodiment, step S400 specifically includes the following steps:

[0272] S410: Detecting in real time the currently available communication protocol type through a protocol identification module, where the communication protocol type includes at least one or more of Wi-Fi, CAN bus, Ethernet, and UART;

[0273] S420: collecting network status parameters in real time, and dynamically updating a preset energy state-protocol adaptation mapping table based on the real-time collected network status parameters, wherein the mapping table includes unit data transmission energy consumption, transmission rate, and stability parameters of each communication protocol at different energy state levels;

[0274] S430: Based on the current energy state level, determine the priority of each communication protocol from the dynamically updated preset energy state-protocol adaptation mapping table, select the optimal communication protocol according to the determined priority, and dynamically configure bandwidth parameters based on the current energy state level:

[0275] When in a high energy state, select the protocol with the highest transmission rate and configure the bandwidth parameter to the highest supported value;

[0276] When in a low energy state, the protocol with the lowest unit energy consumption is selected and the bandwidth parameter is limited to the basic necessary value;

[0277] When in the medium energy state, select a protocol that balances energy consumption and efficiency and keep the bandwidth parameter at the default intermediate value;

[0278] S440: Based on the selected communication protocol, the optimized bandwidth parameters, and the dynamically adjusted upgrade policy parameters, the target firmware data is transmitted to the MCU device through the communication link, and a firmware upgrade operation is performed until the upgrade is completed.

[0279] In this embodiment:

[0280] As described in step S410 above, the protocol identification module detects the currently available communication protocol types in real time to build a foundation for multi-protocol adaptive selection. In specific implementation, a protocol detection engine is integrated into the MCU device to identify the currently available communication protocols (such as Wi-Fi, CAN bus, Ethernet, UART) by actively sending detection frames (such as ARP requests, UDP heartbeat packets) or monitoring broadcast signals in the network environment (such as Wi-Fi Beacon frames). For example, in an industrial environment, the system can simultaneously detect the CAN bus (for inter-device communication) and Ethernet (for remote management); in a smart home scenario, it can detect Wi-Fi (high-speed transmission) and UART (low-power configuration). This module supports multi-protocol parallel detection and updates the list of available protocols every 500ms through hardware interrupts or software polling to ensure real-time response to changes in the network environment.

[0281] As described in step S420 above, by collecting network status parameters (such as signal strength, packet loss rate, delay, etc.) in real time, the preset energy state-protocol adaptation mapping table is dynamically updated. In specific implementation, for each communication protocol, the energy consumption per unit data transmission (such as Wi-Fi consumes 0.5mJ to transmit 1KB of data in a high energy state), the transmission rate (such as Ethernet stable rate of 100Mbps) and the stability parameters (such as CAN bus bit error rate < For example, if the Wi-Fi signal strength drops from -60dBm to -80dBm, the stability parameters of the Wi-Fi protocol in the mapping table are dynamically updated (for example, the packet loss rate increases from 1% to 5%), and its specific energy consumption is adjusted (due to the increase in energy consumption caused by the increase in retransmissions). This mapping table is stored in non-volatile memory and supports continuous parameter optimization based on historical data using machine learning algorithms (such as reinforcement learning), achieving adaptive learning in response to changes in the network environment.

[0282] Among them, the "preset energy state-protocol adaptation mapping table" is the core data structure for realizing multi-protocol adaptive selection. It uses a three-dimensional matrix to store the mapping relationship between energy state (low / medium / high), communication protocol (Wi-Fi / CAN / Ethernet / UART) and performance parameters (energy consumption, rate, reliability, delay); through real-time collection of network parameters (signal strength, packet loss rate, etc.), dynamic parameters are updated every 5 seconds, energy consumption data is updated every 30 seconds, and a sliding window average + outlier filtering algorithm is used to ensure data accuracy; the protocol priority is calculated based on a comprehensive scoring model (0.3×rate factor + 0.4×energy consumption factor + 0.2×reliability factor + 0.1×delay factor), and the lower the score, the higher the priority; it supports multi-device collaborative optimization, environmental adaptive configuration switching and machine learning dynamic weighting, providing a quantitative basis for intelligent protocol selection.

[0283] As described in step S430 above, based on the current energy state level, the priority of each communication protocol is determined from a dynamically updated mapping table, and bandwidth parameters are dynamically configured. The specific rules are as follows: ① In a high energy state (comprehensive value > 0.7), the protocol with the highest transmission rate (e.g., Ethernet 100Mbps) is selected, and the bandwidth parameter is configured to the maximum value supported by the device (e.g., Wi-Fi HT40 mode) to complete the upgrade as quickly as possible. ② In a low energy state (comprehensive value ≤ 0.3), the protocol with the lowest unit energy consumption (e.g., UART 9600bps) is selected, and the bandwidth is limited to the minimum value required to maintain basic transmission (e.g., CAN bus 50Kbps) to ensure the lowest energy consumption during the upgrade process. ③ In a medium energy state (0.3 < comprehensive value ≤ 0.7), the protocol that balances energy consumption and efficiency (e.g., Wi-Fi 24Mbps) is selected, and the bandwidth is maintained at the default intermediate value (e.g., Ethernet 10Mbps), balancing upgrade speed and energy consumption. For example, in a vehicle environment, when the battery is sufficient, high-speed Ethernet is used to transmit firmware first; when the battery is as low as 20%, it automatically switches to the CAN bus for low-power transmission.

[0284] As described in step S440 above, the firmware upgrade operation is performed based on the selected communication protocol, optimized bandwidth parameters and dynamically adjusted upgrade strategy parameters (such as the aforementioned baud rate and fragmentation strategy). In specific implementation, the target firmware data is transmitted through a communication link (such as a selected Wi-Fi channel) according to the optimized parameters (such as small data blocks and low baud rate in a low energy state), and the aforementioned state monitoring and policy dynamic adjustment mechanism is enabled at the same time to ensure that the transmission parameters are continuously optimized according to the real-time energy state during the upgrade process. For example, if the energy state is detected to change from high to low during the upgrade process, it will immediately switch to a low-energy protocol (such as from Ethernet to UART) and adjust the data block size (such as from 4096 bytes to 128 bytes). During the upgrade process, a CRC check is performed every time 1KB of data is transmitted to ensure data integrity until the entire firmware transmission is completed and successfully burned to the MCU.

[0285] The above implementation method has established a complete energy-adaptive multi-protocol upgrade system. Through real-time protocol identification, dynamic mapping table updates, intelligent protocol priority sorting, and adaptive bandwidth parameter configuration, it achieves optimal utilization of communication resources under varying energy states. In practical applications, this system can reduce the average energy consumption of firmware upgrades while ensuring acceptable upgrade times, significantly improving the energy efficiency and reliability of firmware upgrades for battery-powered devices.

[0286] In one embodiment, step S430 further includes the following steps:

[0287] S431. Predicting the network load fluctuation trend within a preset time period in the future based on the real-time collected network status parameter sequence and the current energy status level using a preset neural network prediction model;

[0288] S432. Dynamically adjust the sub-data block size of the target firmware data based on the predicted network load fluctuation trend and the current energy state level:

[0289] If the predicted network load will increase within a preset time and the current energy state is high, the sub-data block size is reduced to reduce the retransmission energy consumption;

[0290] If the predicted network load remains stable or decreases within the preset time and the current energy state is medium / low, increase the sub-data block size to reduce the number of transmission interactions;

[0291] If the predicted network load fluctuates significantly within the preset time, the sub-block size is kept at the default value to balance stability and energy consumption.

[0292] In this embodiment:

[0293] As described in step S431 above, a preset neural network prediction model predicts network load fluctuation trends within a preset time period (e.g., 5 minutes) based on a real-time sequence of collected network status parameters (e.g., signal strength, packet loss rate, and latency over the past 10 minutes) and the current energy state level. Specifically, a lightweight neural network (e.g., an LSTM or TinyML model) is deployed within the MCU. The input layer receives a normalized sequence of network parameters (e.g., signal strength [-100dBm, -30dBm] is mapped to [0, 1]) and a comprehensive energy state value. The hidden layer uses a pre-trained weight matrix to extract features (e.g., identifying Wi-Fi channel contention periods), and the output layer generates a predicted value for future load fluctuations (e.g., "high load probability 70%"). The model updates its predictions every 10 seconds, continuously learning network dynamics through a sliding window mechanism. The pre-trained weights can be dynamically optimized through over-the-air (OTA) updates to adapt to different application scenarios (e.g., the differences in network characteristics between industrial sites and smart home environments).

[0294] As described in step S432 above, this step dynamically adjusts the sub-data block size of the target firmware data based on the network load prediction results and the current energy state level. The specific rules are as follows: ① If the network load is predicted to increase in the future (e.g., the probability of high load is greater than 60%) and the current energy state is high, the sub-data block size is reduced from the default 1024 bytes to 512 bytes. This reduces the retransmission probability by reducing the amount of data transmitted per transmission (e.g., the packet loss rate is reduced from 3% to 1%). Although the number of transmissions increases, the overall energy consumption is reduced due to the reduction in retransmissions. ② If the load is predicted to be stable or decreasing and the current energy state is medium or low, the sub-data block size is increased to 2048 bytes. This reduces the number of transmission interactions (e.g., the total number of transmissions is reduced from 1000 to 500) and reduces the energy consumption of protocol overhead (e.g., the proportion of handshake packets is reduced from 10% to 5%). ③ If the load is predicted to fluctuate significantly (e.g., the load change rate is greater than 0.5 / second), the sub-data block size is maintained at the default value (e.g., 1024 bytes). Medium-sized blocks are used to balance transmission stability (avoiding frequent retransmissions of large blocks) and efficiency (avoiding excessive protocol overhead for small blocks). For example, in an industrial Ethernet environment, if a production line change is predicted to cause a surge in network traffic, the system automatically reduces the block size; during low-load periods at night, the block size is increased to improve upgrade efficiency.

[0295] Through the above implementation, a network-prediction-based intelligent sharding mechanism has been established. This mechanism uses a neural network to predict future load trends and dynamically adjusts the sub-data block size based on real-time energy status, enabling proactive response to network fluctuations. In actual testing, this mechanism has reduced firmware upgrade retransmissions, particularly in environments with high load fluctuations (such as areas with dense Wi-Fi hotspots). This reduces upgrade energy consumption compared to a fixed block size strategy while maintaining a relatively constant upgrade time. This significantly improves the energy efficiency and reliability of upgrades in complex network environments.

[0296] In one embodiment, the preset neural network prediction model is a lightweight long short-term memory network (LSTM), and the training steps of the model include:

[0297] S4311. Collect historical network load data, energy state levels and transmission success rates for corresponding time periods to construct a training data set;

[0298] S4312, normalizing the training data set and dividing it into sequence samples according to time windows;

[0299] S4313. Using the sequence samples to train an LSTM model, with minimizing the mean square error between the predicted network load fluctuation trend and the actual fluctuation as the optimization goal, to obtain a neural network prediction model;

[0300] S4314. Deploy the trained neural network prediction model to the memory of the MCU device for real-time reception of the currently collected network status parameter sequence (including but not limited to signal strength, packet loss rate, network delay) and the current energy status level, so as to predict and output the network load fluctuation trend within a preset time period in the future.

[0301] In this embodiment:

[0302] As described in step S4311 above, a basic dataset for training the LSTM model is constructed by collecting historical network load data, energy state levels for corresponding time periods, and transmission success rates. Specifically, the following data is continuously recorded during device operation: ① Network load data (including signal strength, packet loss rate, network latency, and throughput, for example, Wi-Fi signal strength of -70dBm and Ethernet packet loss rate of 0.5%); ② Energy state level (determined in real time through the aforementioned weighted summation, such as low / medium / high status labels); and ③ Transmission success rate (e.g., the percentage of successfully transmitted firmware sub-data blocks is counted every 10 minutes). The data collection period covers different application scenarios (e.g., high-load industrial environments and low-load smart homes), ultimately forming a training dataset containing several samples to ensure the adequacy and generalizability of model training.

[0303] As described in step S4312 above, the training dataset is normalized and divided into sequence samples according to the time window to adapt to the time series input requirements of the LSTM model. The specific implementation is as follows: ① Normalization: Using the Min-Max scaling algorithm, the signal strength (-100dBm~-30dBm) is mapped to the [0,1] interval, the packet loss rate (0~10%) is mapped to [0,0.1], and the energy state level (low / medium / high) is converted to a one-hot encoding ([1,0,0] / [0,1,0] / [0,0,1]); ② Time window division: Set the time window length to 10 minutes and the sliding step size to 1 minute. The continuously collected parameter sequence (e.g., once every 30 seconds, for a total of 20 time points) is used as the input sample, and the corresponding network load fluctuation trend in the next 5 minutes (e.g., the probability of load increase / stable / decrease) is used as the label to form an "input sequence-label" pair (e.g., X=[ ],Y=[ ]), where each Contains normalized network parameters and energy state encoding.

[0304] As described in step S4313 above, the LSTM model is trained using the partitioned sequence samples, with the optimization objective of minimizing the mean squared error (MSE) between the predicted and actual values. The specific training process is as follows: ① Model architecture: 2 LSTM layers (128 neurons per layer) + 1 fully connected layer. The input dimension is the number of network parameters + the length of the energy state encoding (e.g., 8-dimensional network parameters + 3-dimensional one-hot encoding = 11 dimensions), and the output dimension is a continuous prediction of future load fluctuations (e.g., 0 to 1 indicates the probability of a load increase). ② Optimization algorithm: The Adam optimizer is used with a learning rate of 0.001, a batch size of 32, and 50 training epochs. The MSE is evaluated every 5 epochs on the validation set (20% of the dataset). ③ Regularization: A dropout layer (ratio 0.2) is added to prevent overfitting, and early stopping is employed (training is terminated if the validation set MSE does not decrease after 10 consecutive epochs). After training, the model achieves an MSE ≤ 0.05 on the test set and a prediction accuracy ≥ 85%, meeting the accuracy requirements for real-time prediction.

[0305] As described in step S4314 above, this step deploys the trained LSTM model to the MCU's memory, enabling real-time prediction of network load fluctuation trends. The specific deployment methods are: ① Model compression: Through weight quantization (converting 32-bit floating-point numbers to 16-bit fixed-point numbers) and structural pruning (removing redundant connections), the model size is compressed to less than 100KB (compatible with the on-chip flash memory of the STM32H7 series MCU). ② Memory allocation: A dedicated area is allocated in the MCU's RAM to store model weights and intermediate variables, using static memory allocation to avoid dynamic allocation overhead. ③ Real-time prediction: The model receives a currently collected sequence of network status parameters (e.g., signal strength sequence over the past 10 minutes) and energy state level encoding, and uses forward propagation to calculate and output load fluctuation trends for the next 5 minutes (e.g., "high load probability 65%," "stable probability 25%," "decreasing probability 10%") with a prediction latency of ≤10ms, meeting the timeliness requirements of real-time decision-making during firmware upgrades.

[0306] Through the above implementation, a complete LSTM training process, from data collection to model deployment, was established, ensuring the efficient operation of the prediction model on MCU devices. This model leverages LSTM's ability to model the long-term dependencies of time series data, accurately capturing the dynamic correlation between network load and energy status. This provides a reliable prediction basis for the aforementioned dynamic adjustment of sub-data block sizes. In actual testing, this improved the accuracy of upgrade strategies in complex network environments, effectively reducing retransmission energy consumption and the risk of upgrade failures caused by network fluctuations.

[0307] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0308] In one embodiment, a low-power MCU firmware upgrade system based on energy adaptation is provided, and the low-power MCU firmware upgrade system based on energy adaptation corresponds to the low-power MCU firmware upgrade method based on energy adaptation in the above embodiment. The low-power MCU firmware upgrade system based on energy adaptation includes:

[0309] The data acquisition module is used to establish a communication link between the upgrade initiator and the MCU device, and collect energy status parameters in real time through the energy monitoring terminal built into the MCU device;

[0310] A state classification module, configured to classify the comprehensive value of the energy state parameter into a low energy state, a medium energy state, and a high energy state according to a preset energy state threshold interval;

[0311] A policy adjustment module, configured to dynamically adjust the upgrade policy parameters of the current firmware based on the current energy state level and according to preset adjustment rules, wherein the upgrade policy parameters include transmission parameters, verification parameters, and retransmission policy parameters of the target firmware data;

[0312] The data transmission module is used to transmit the target firmware data to the MCU device through the communication link based on the dynamically adjusted upgrade policy parameters, and perform the firmware upgrade operation until the upgrade is completed.

[0313] Regarding the specific definition of an MCU low-power firmware upgrade system based on energy adaptation, please refer to the definition of an MCU low-power firmware upgrade method based on energy adaptation above, which will not be repeated here. Each module in the above-mentioned MCU low-power firmware upgrade system based on energy adaptation can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0314] Those skilled in the art will clearly understand that for the sake of convenience and brevity in description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

[0315] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A low-power MCU firmware upgrade method based on energy adaptation, characterized in that: Including steps: Establish a communication link between the upgrade initiator and the MCU device, and collect energy status parameters in real time through the energy monitoring terminal built into the MCU device. The energy status parameters include at least one or more combinations of battery voltage value, remaining power percentage, and energy consumption rate; According to a preset energy state threshold interval, the comprehensive value of the energy state parameter is divided into a low energy state, a medium energy state and a high energy state; Based on the current energy state level, dynamically adjust the upgrade policy parameters of the current firmware according to preset adjustment rules, the upgrade policy parameters including the transmission parameters, verification parameters and retransmission policy parameters of the target firmware data; Based on the dynamically adjusted upgrade policy parameters, the target firmware data is transmitted to the MCU device through the communication link, and the firmware upgrade operation is performed until the upgrade is completed; The adjustment rules include differentiated adjustment strategies for different energy states, including: When in a low-energy state, reduce data transmission power consumption, extend the check interval period, configure a non-instant retransmission mechanism, and optimize the multi-core collaboration mode according to the hardware resource status; When in a high-energy state, data transmission efficiency is improved, the verification interval is shortened, an instant retransmission mechanism is configured, and the multi-core collaborative mode is activated according to the hardware resource status.

2. The method for upgrading MCU firmware based on energy adaptation according to claim 1, wherein: When in a low energy state, specifically: Dividing the target firmware data into sub-data blocks no larger than a preset minimum data transmission unit, thereby reducing the transmission baud rate of the communication link; Extend the time interval between two adjacent verification operations to the preset maximum verification period; Configure the retransmission policy to trigger batch retransmission when the cumulative number of errors reaches N, where N ≥ 2. If the communication link includes multi-core hardware resources, configuring the multi-core hardware resources to enter a single-core working mode, and the non-main core units to enter a dormant state; When in a high energy state, specifically: Dividing the target firmware data into sub-data blocks no smaller than a preset maximum data transmission unit, thereby increasing the transmission baud rate of the communication link; Shorten the time interval between two adjacent verification operations to the preset minimum verification period; Configure the retransmission policy to immediate single-packet retransmission; If the communication link includes multi-core hardware resources, waking up the multi-core hardware resources to process data transmission and verification operations in parallel; When in the medium energy state, the preset default transmission unit, default baud rate, default check period and default retransmission strategy are used.

3. The method for upgrading MCU firmware based on energy adaptation according to claim 2, wherein: The transmission parameters of the target firmware data include the complete target firmware or a fragmentation strategy based on the difference data between the target firmware and the current firmware, wherein the difference data includes one or more combinations of incremental data, modified data, and non-overlapping data segments calculated by a differential algorithm; The sub-data blocks are generated based on the difference data, and the sharding strategy is used to determine the size and number of the sub-data blocks; Among them, the sharding strategy based on the difference data between the target firmware and the current firmware is preferentially adopted in the low energy state to reduce transmission power consumption.

4. The method for upgrading MCU firmware based on energy adaptation according to claim 1, wherein: The step of dividing the comprehensive value of the energy state parameter into a low energy state, a medium energy state, and a high energy state according to a preset energy state threshold interval specifically includes the following steps: Preset the weight coefficient of each energy state parameter, and the weight coefficient is set according to the degree of influence of the parameter on the energy state; Normalize the real-time collected battery voltage, remaining power percentage, and energy consumption rate to obtain standardized values ​​of each parameter; Calculating a comprehensive value of the energy state parameter by weighted summation based on the weight coefficient and the normalized value; The low energy threshold, medium energy threshold and high energy threshold are preset to form the energy state threshold range: If the comprehensive value is ≤ the low energy threshold, it is determined to be in a low energy state; If the low energy threshold < comprehensive value ≤ medium energy threshold, it is determined to be a medium energy state; If the comprehensive value is greater than the medium energy threshold, it is determined to be a high energy state.

5. The method for upgrading MCU firmware based on energy adaptation according to claim 1, wherein: In the step of dynamically adjusting the upgrade policy parameters of the current firmware according to preset adjustment rules based on the current energy state level, the step of dynamically adjusting the upgrade policy parameters of the current firmware specifically includes the following steps: Real-time monitoring of the duration of the current energy status level; When the energy status level changes, determine whether the duration of the change exceeds the preset stability threshold: If so, switch to the corresponding adjustment strategy according to the new energy state level; If not, maintain the current adjustment strategy; During the upgrade process, if the duration of the current energy status level exceeds the preset policy validity period, the energy status is re-evaluated and the upgrade policy parameters are adjusted.

6. The energy-adaptive MCU low-power firmware upgrade method according to claim 5, wherein: When the energy state level changes, the step of determining whether the duration of the change exceeds a preset stability threshold specifically includes the following steps: When a change in the energy state level is detected, a timer is started to record the duration of the change; Get the stability threshold related to the direction of change of the current energy state level: If the energy state level changes from low to high, obtain the first stable threshold ; If the energy state level changes from medium to high, obtain the second stable threshold ; If the energy state level changes from medium to low, obtain the third stable threshold ; If the energy state level changes from high to low, obtain the fourth stable threshold ; in, ; Compare the duration of the change recorded by the timer with the corresponding stability threshold to determine whether it is exceeded.

7. The method for upgrading MCU firmware based on energy adaptation according to claim 5, wherein: During the upgrade process, if the duration of the current energy status level exceeds the preset policy validity period, the step of re-evaluating the energy status and adjusting the upgrade policy parameters specifically includes the following steps: When the duration of the current energy status level exceeds the preset policy validity period, the energy status re-evaluation process is triggered; Obtain the real-time value of the current energy state parameter and recalculate the comprehensive value of the energy state; Compare the recalculated comprehensive value with the preset energy status threshold range to determine whether the energy status level needs to be adjusted; If the energy status level needs to be adjusted, the upgrade strategy parameters are adjusted according to the differentiated adjustment strategy corresponding to the current energy status level; If the energy status level does not need to be adjusted, but the change rate of the current energy status parameter exceeds the preset change rate threshold, the upgrade strategy parameters are adjusted according to the following rules: If the energy consumption rate change rate is greater than the first change rate threshold, shorten the policy validity period; If the remaining power percentage change rate is less than the second change rate threshold, the transmission baud rate is reduced.

8. The method for upgrading MCU firmware based on energy adaptation according to claim 1, wherein: The step of transmitting target firmware data to the MCU device through a communication link based on the dynamically adjusted upgrade policy parameters and performing a firmware upgrade operation until the upgrade is completed specifically includes the following steps: The protocol identification module detects the currently available communication protocol type in real time, wherein the communication protocol type includes at least one or more of Wi-Fi, CAN bus, Ethernet, and UART; Real-time collection of network status parameters, and dynamic updating of a preset energy state-protocol adaptation mapping table based on the real-time collected network status parameters, wherein the mapping table includes unit data transmission energy consumption, transmission rate, and stability parameters of each communication protocol at different energy state levels; Based on the current energy state level, the priority of each communication protocol is determined from the dynamically updated preset energy state-protocol adaptation mapping table. The optimal communication protocol is selected based on the determined priority, and the bandwidth parameters are dynamically configured based on the current energy state level: When in a high energy state, select the protocol with the highest transmission rate and configure the bandwidth parameter to the highest supported value; When in a low energy state, the protocol with the lowest unit energy consumption is selected and the bandwidth parameter is limited to the basic necessary value; When in the medium energy state, select a protocol that balances energy consumption and efficiency and keep the bandwidth parameter at the default intermediate value; Based on the selected communication protocol, optimized bandwidth parameters and dynamically adjusted upgrade strategy parameters, the target firmware data is transmitted to the MCU device through the communication link, and a firmware upgrade operation is performed until the upgrade is completed.

9. The method for upgrading MCU firmware based on energy adaptation according to claim 8, wherein: The steps of determining the priority of each communication protocol from a dynamically updated preset energy state-protocol adaptation mapping table based on the current energy state level, selecting the optimal communication protocol according to the determined priority, and dynamically configuring bandwidth parameters based on the current energy state level further include the following steps: Through the preset neural network prediction model, based on the real-time collected network status parameter sequence and current energy status level, the network load fluctuation trend within the future preset time period is predicted; Dynamically adjust the sub-data block size of the target firmware data based on the predicted network load fluctuation trend and the current energy status level: If the predicted network load will increase within a preset time and the current energy state is high, the sub-data block size is reduced to reduce the retransmission energy consumption; If the predicted network load remains stable or decreases within the preset time and the current energy state is medium / low, increase the sub-data block size to reduce the number of transmission interactions; If the predicted network load fluctuates significantly within the preset time, the sub-block size is kept at the default value to balance stability and energy consumption.

10. An energy-adaptive MCU low-power firmware upgrade system, used to implement the steps of an energy-adaptive MCU low-power firmware upgrade method according to any one of claims 1 to 9, characterized in that: include: The data acquisition module is used to establish a communication link between the upgrade initiator and the MCU device, and collect energy status parameters in real time through the energy monitoring terminal built into the MCU device; A state classification module, configured to classify the comprehensive value of the energy state parameter into a low energy state, a medium energy state, and a high energy state according to a preset energy state threshold interval; A policy adjustment module, configured to dynamically adjust the upgrade policy parameters of the current firmware based on the current energy state level and according to preset adjustment rules, wherein the upgrade policy parameters include transmission parameters, verification parameters, and retransmission policy parameters of the target firmware data; The data transmission module is used to transmit the target firmware data to the MCU device through the communication link based on the dynamically adjusted upgrade policy parameters, and perform the firmware upgrade operation until the upgrade is completed.

Images