Firmware upgrading method and device and computer readable storage medium

Abstract

The invention discloses a firmware upgrading method and device and a computer readable storage medium, and relates to the technical field of firmware upgrading, the method is applied to the firmware upgrading device, the firmware upgrading device comprises a target communication pin, the communication mode of the target communication pin is initialized into a receiving mode, and the method comprises the following steps: responding to a firmware upgrading instruction, receiving an upgrade data packet for the target communication pin in the receiving mode based on the communication mode; receiving feedback information aiming at the upgrading data packet is acquired, and the communication mode of the target communication pin is switched into a sending mode; sending receiving feedback information to the target communication pin in the sending mode based on the communication mode; and after the receiving feedback information is sent, switching the communication mode of the target communication pin into a receiving mode so as to continue to receive the next upgrading data packet. According to the method and the device, the communication pin resource demand of firmware upgrading is reduced from two to one, and the occupation demand on the communication pin resource is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of firmware upgrade, in particular to a firmware upgrade method, device and computer readable storage medium. BACKGROUND

[0002] Firmware upgrade is a key link of electronic device life cycle management, and is widely used in various intelligent hardware, consumer electronics and industrial devices. Through firmware upgrade, device manufacturers can remotely repair vulnerabilities, optimize performance and add new functions, thereby significantly prolonging product service life and improving user experience. For embedded devices, reliable and efficient remote firmware upgrade capability is particularly important, which is the basic guarantee to ensure the continuous safe and stable operation of the device.

[0003] At present, for firmware upgrade of embedded devices, a scheme based on the mcumgr (Microcontroller Unit Manager) protocol stack is generally adopted. The mcumgr protocol stack is originally designed and relies on a full-duplex communication interface to realize firmware upgrade, that is, the mcumgr protocol stack requires the underlying physical interface to provide at least two independent data channels, and a typical implementation is the RX (Receive) signal line and TX (Transmit) signal line of UART (Universal Asynchronous Receiver / Transmitter).

[0004] However, this full-duplex communication mode must be carried by a dedicated physical signal line for each independent data transmission direction (transmission and reception), and accordingly occupies an independent communication pin on the device. Therefore, the minimum requirement for realizing full-duplex interaction is to occupy two communication pin resources. This rigid requirement for resource occupation at the hardware level poses a serious challenge to many resource-constrained embedded target devices (such as miniature sensor nodes and ultra-compact wearable devices). Such devices are subject to strict physical size limitations, cost control objectives or intensive functional integration requirements, and their physical pin resources that can be allocated to external communication functions are extremely scarce, which may not meet the rigid requirement of full-duplex communication mode for double communication pins, thereby causing the firmware upgrade mode relying on full-duplex communication mode to be unsuitable for such devices, and seriously restricting the application of firmware upgrade function in resource-constrained embedded devices. SUMMARY

[0005] The main purpose of the present application is to provide a firmware upgrade method, device and computer readable storage medium, which aims to solve the technical problem that the current firmware upgrade relies on full-duplex communication mode, which has high resource requirements for communication pins, resulting in firmware upgrade that may not be suitable for devices with scarce pin resources.

[0006] To achieve the above object, the application provides a firmware upgrade method applied to a firmware upgrade device, the firmware upgrade device comprising a target communication pin, the communication mode of the target communication pin being initialized as a receiving mode, the firmware upgrade method comprising the following steps:

[0007] In response to a firmware upgrade instruction, receiving an upgrade data packet based on the target communication pin in the receiving mode;

[0008] Obtaining receiving feedback information for the upgrade data packet, and switching the communication mode of the target communication pin to a sending mode;

[0009] Sending the receiving feedback information based on the target communication pin in the sending mode;

[0010] After the sending of the receiving feedback information is completed, switching the communication mode of the target communication pin to the receiving mode to continue receiving a next upgrade data packet, and performing firmware upgrade after all the upgrade data packets are received.

[0011] In an embodiment, after the step of switching the communication mode of the target communication pin to the sending mode, the method further comprises:

[0012] Obtaining the sending mode duration of the target communication pin;

[0013] If the sending mode duration is greater than or equal to a preset upper limit of the duration, performing the step of switching the communication mode of the target communication pin to the receiving mode.

[0014] In an embodiment, the data transmission mode of the firmware upgrade device is an asynchronous mode, and after the step of sending the receiving feedback information based on the target communication pin in the sending mode, the method further comprises:

[0015] After starting to send the receiving feedback information, listening to a data sending completion interrupt event for the receiving feedback information;

[0016] If the data sending completion interrupt event for the receiving feedback information is listened to, it is determined that the sending of the receiving feedback information is completed.

[0017] In an embodiment, the data transmission mode of the firmware upgrade device is a blocking mode, and after the step of sending the receiving feedback information based on the target communication pin in the sending mode, the method further comprises:

[0018] After starting to send the receiving feedback information, waiting for a target duration, and determining that the sending of the receiving feedback information is completed after waiting for the target duration; and / or,

[0019] after starting to send the receiving feedback information, polling a preset sending state flag bit, and if the preset sending state flag bit indicates that data sending is ended, determining that the sending of the receiving feedback information is completed.

[0020] In an embodiment, before the step of waiting for a target time length after starting to send the receiving feedback information, the method further comprises:

[0021] If the upgraded data packet is a first frame data packet, determining that a preset reference waiting time length is the target time length.

[0022] If the upgraded data packet is a non-first frame data packet, obtaining an adjacent data packet receiving interval time length, and determining the target time length based on the adjacent data packet receiving interval time length, wherein the adjacent data packet receiving interval time length is an interval time length between receiving times of two adjacent frames of upgraded data packets.

[0023] The target time length and the adjacent data packet receiving interval time length have a positive correlation trend.

[0024] In an embodiment, the step of determining the target time length based on the adjacent data packet receiving interval time length comprises:

[0025] obtaining a waiting time length corresponding to the adjacent data packet receiving interval time length based on a preset mapping relationship, and determining that the waiting time length is the target time length, wherein the preset mapping relationship is a mapping relationship between different adjacent data packet receiving interval time lengths and waiting time lengths; or

[0026] obtaining a current target time length, and adjusting the current target time length based on a trend of interval time variation of the adjacent data packet receiving interval time length to obtain the target time length; or

[0027] adjusting a preset reference waiting time length based on the adjacent data packet receiving interval time length to obtain the target time length.

[0028] In an embodiment, after the step of obtaining the adjacent data packet receiving interval time length, the method further comprises:

[0029] detecting whether the adjacent data packet receiving interval time length is greater than a preset upper limit receiving interval time length for a preset number of consecutive times;

[0030] If yes, determining that a preset reference waiting time length is the target time length.

[0031] If no, performing the step of determining the target time length based on the adjacent data packet receiving interval time length.

[0032] In an embodiment, the firmware upgrade device upgrades firmware based on a mcumgr protocol stack, and the step of obtaining the receiving feedback information for the upgrade data packet comprises:

[0033] performing legality verification on the upgrade data packet based on the mcumgr protocol stack to obtain a verification result;

[0034] if the verification result is a verification pass, determining that an ACK response is the receiving feedback information for the upgrade data packet;

[0035] if the verification result is a verification fail, determining that a NACK response is the receiving feedback information for the upgrade data packet.

[0036] In addition, to achieve the above object, the present application further provides a firmware upgrade device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the firmware upgrade method as described above.

[0037] In addition, to achieve the above object, the present application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the firmware upgrade method as described above.

[0038] The present application further provides a computer program product, comprising a computer program, and the computer program is executed by a processor to implement the steps of the firmware upgrade method as described above.

[0039] The one or more technical solutions provided by the present application have at least the following technical effects:

[0040] The application initializes the communication mode of a target communication pin in a firmware upgrade device to a sending mode, and after receiving a firmware upgrade instruction, receives an upgrade data packet based on the target communication pin in the receiving mode. The application obtains receiving feedback information for the upgrade data packet, and switches the communication mode of the target communication pin to the sending mode. The application sends the receiving feedback information based on the target communication pin in the sending mode. After the sending of the receiving feedback information is completed, the application switches the communication mode of the target communication pin to the receiving mode to continue receiving the next upgrade data packet, and performs firmware upgrade after all the upgrade data packets are received. BRIEF DESCRIPTION OF DRAWINGS

[0041] The accompanying drawings, which are incorporated herein and constitute part of the specification, illustrate embodiments consistent with the application and, together with the description, serve to explain the principles of the application.

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without any creative effort.

[0043] Figure 1 Flowchart of the first embodiment of the firmware upgrade method of the application;

[0044] Figure 2 Flowchart of the firmware upgrade process related to an embodiment of the firmware upgrade method of the application;

[0045] Figure 3 State switching process diagram of the mcumgr protocol stack in the firmware upgrade process related to an embodiment of the firmware upgrade method of the application;

[0046] Figure 4 System structure diagram of the firmware upgrade device of the application;

[0047] Figure 5 A device structure schematic diagram of a hardware running environment involved in a firmware upgrade method and device in embodiments of the present application.

[0048] The object implementation, functional features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0049] In order to make the above object, features and advantages of the present application more apparent and easy to understand, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings of the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.

[0050] In a resource-limited embedded system, the firmware upgrade based on the mcumgr protocol stack is a widely used solution due to its standardized architecture. However, the core running mechanism of this protocol strictly depends on the full-duplex communication mode, which requires real-time and concurrent bidirectional data stream transmission between the device and the host (e.g., the downlink instruction and the uplink state feedback occur at the same time). This communication mode explicitly requires two independent physical signal channels dedicated to unidirectional data transmission at the hardware level. For example, the UART interface must be configured with an independent receive signal line (RX) and a transmit signal line (TX), and each signal line must be bound and exclusively occupy a physical input / output communication pin of the device.

[0051] However, this firmware upgrade scheme relying on full-duplex communication has at least the following technical bottlenecks:

[0052] ① Hardware resource limitation: Traditional mcumgr firmware upgrade relies on a full-duplex communication interface, which requires at least two data lines. However, due to the scarcity of pins, some embedded devices (such as wearable devices and micro sensors) can only provide a single communication line.

[0053] ② Protocol adaptation difficulty: mcumgr natively supports full-duplex communication, and its protocol stack is designed based on bidirectional real-time data interaction. In a single-wire half-duplex scenario (only unidirectional transmission at the same time), it cannot directly implement request-response communication, leading to interrupted upgrade process or data loss.

[0054] ③ High development cost: If the existing solution is to be adapted to single-line communication, the underlying logic of the mcumgr protocol stack (such as packet splitting mechanism and response protocol) needs to be modified, increasing the development complexity and verification cost.

[0055] Based on this, the main solution of the present application is to provide a firmware upgrade method applied to a firmware upgrade device, the firmware upgrade device comprising a target communication pin, the communication mode of the target communication pin being initialized as a receiving mode; in response to a firmware upgrade instruction, receiving an upgrade data packet based on the target communication pin with the communication mode as the receiving mode; obtaining receiving feedback information for the upgrade data packet, and switching the communication mode of the target communication pin to a sending mode; sending the receiving feedback information based on the target communication pin with the communication mode as the sending mode; after the sending of the receiving feedback information is completed, switching the communication mode of the target communication pin to the receiving mode to continue receiving a next upgrade data packet, and performing firmware upgrade after all the upgrade data packets are received.

[0056] The present application dynamically switches the communication mode (alternately switching between the receiving mode and the sending mode) of the same target communication pin, substantially realizes single-line half-duplex communication, uses the time-division multiplexing mechanism of the two modes, uses the same target communication pin to realize the receiving of the upgrade data packet and the sending of the receiving feedback information, so that only one communication signal line (corresponding to a single target communication pin) is required at the physical level, avoiding the rigid requirement of two independent physical channels for simultaneous bidirectional operation in full-duplex communication, thereby reducing the communication pin resource requirement of firmware upgrade from two to one, reducing the occupation requirement of communication pin resources, and further enabling the firmware upgrade function to be applied to embedded devices with scarce pin resources (such as single-pin communication sensor nodes).

[0057] It should be noted that the execution subject of each embodiment of the firmware upgrade method of the present application can be a firmware upgrade device capable of realizing the above functions, such as wearable devices, smart home appliances, smart sensors, industrial controllers, etc., and the present application does not make specific limitations on this, and for example, the following describes and explains each embodiment of the present application with wearable devices as the execution subject.

[0058] Based on this, the present application proposes a firmware upgrade method of the first embodiment, which is applied to a firmware upgrade device, the firmware upgrade device comprising a target communication pin, the communication mode of the target communication pin being initialized as a receiving mode, please refer to Figure 1 The firmware upgrade method comprises the following steps S10-S40:

[0059] Step S10, in response to a firmware upgrade instruction, receiving an upgrade data packet based on the target communication pin with the communication mode as the receiving mode;

[0060] It should be noted that the target communication pin can be any one of all the pins of the wearable device, and the communication pin refers to a physical interface or pin in the wearable device for realizing data transmission and communication function. Further, the communication pin is usually connected with a control unit (such as MCU) for transmitting data signals, control signals and the like within the device or between the device and other external devices.

[0061] It should be noted that if each pin in the wearable device can be multiplexed as any peripheral function, any pin in the wearable device can be selected as the target communication pin.

[0062] The target communication pin is initialized as a receiving mode, that is, the target communication pin is initialized as an RX channel (also referred to as RX mode). Further, if the wearable device uses the mcumgr protocol stack for firmware upgrade, the target communication pin is initialized as the RX mode, and at this time, the RX_IDLE state of the mcumgr protocol stack is entered to achieve the multiplexing purpose of the mcumgr protocol stack and reduce the development threshold.

[0063] In the RX mode, the target communication pin enables the receiving function and enters a listening state to listen to and respond to the firmware upgrade instruction. The firmware upgrade instruction can be specifically an instruction issued by the master device to the wearable device for triggering the firmware upgrade process, which can be specifically expressed as an img_mgmt upload instruction.

[0064] After receiving the firmware upgrade instruction, the wearable device can perform initialization preparation work before firmware upgrade, such as initializing the protocol stack, allocating a receiving buffer, setting an upgrade state flag, and the like. At the same time, the target communication pin still maintains the RX mode to wait for and receive the upgrade data packet issued by the master device. The upgrade data packet refers to a data unit transmitted by the master device. For example, the master device frames the firmware data into SMP (Simple Management Protocol Data Packet) data packets and transmits the SMP data packets in frames, and the upgrade data packet is specifically expressed as one frame of SMP data packet.

[0065] In addition, it can be understood that in the communication process, there can be a situation that other non-upgrade data packets interfere with the data transmission to the target communication pin and are received. Therefore, after the target communication pin receives the data, the target communication pin can perform data verification on the data received by the target communication pin to verify whether the received data is an upgrade data packet. If it is an upgrade data packet, the subsequent steps are continued to be executed, and if it is not an upgrade data packet, the received data can be discarded, and the RX mode of the target communication pin is maintained.

[0066] Step S20, obtaining receiving feedback information for the upgrade data packet, and switching the communication mode of the target communication pin to a sending mode;

[0067] After receiving the upgrade data packet, obtaining receiving feedback information for the upgrade data packet, and switching the communication mode of the target communication pin to a sending mode. Specifically, the target communication pin can be switched to a sending mode after the upgrade data packet is received (e.g., the end flag bit of the upgrade data packet is received), that is, the target communication pin is switched to a TX channel (also referred to as a TX mode).

[0068] In the TX mode, the target communication pin enables a sending function to send the receiving feedback information to the host device.

[0069] The receiving feedback information refers to feedback information on the receiving state of the upgrade data packet, and is used to reflect whether the upgrade data packet is successfully received, which can be specifically an ACK (Acknowledgment) response or a NACK (Negative Acknowledgment) response.

[0070] Step S30, sending the receiving feedback information based on the target communication pin in the sending mode;

[0071] After obtaining the receiving feedback information for the received upgrade data packet, the receiving feedback information is sent through the communication pin in the TX mode to send the receiving feedback information to the host device. After receiving the receiving feedback information sent by the wearable device, the host device determines a subsequent transmission strategy based on the receiving feedback information: if the receiving feedback information is an ACK response, the next upgrade data packet is sent; if the receiving feedback information is a NACK response, the previous upgrade data packet is retransmitted or the upgrade process is interrupted.

[0072] Step S40, after the receiving feedback information is sent, the communication mode of the target communication pin is switched to a receiving mode to continue receiving the next upgrade data packet, and after all the upgrade data packets are received, the firmware is upgraded.

[0073] After the receiving feedback information is sent, the communication mode of the target communication pin is switched back to the RX mode to again enable the receiving function to enter a listening state, and wait for and receive the next upgrade data packet issued by the host device. It should be noted that the next upgrade data packet here refers to the next upgrade data packet in time, and is not necessarily the next logical frame of upgrade data packet in the framing order of the firmware image itself, for example, when the host device retransmits the upgrade data packet, the two received upgrade data packets can be understood as the same frame of upgrade data packet, but there is a receiving time sequence.

[0074] If all the upgrade data packets are received, the firmware upgrade can be performed based on the received upgrade data. Specifically, a mature firmware upgrade scheme can be used to perform the firmware upgrade, which will not be described in detail in this embodiment.

[0075] In this embodiment, the communication mode of the same target communication pin is dynamically switched (the receiving mode and the sending mode are alternately switched), and single-wire half-duplex communication is essentially realized. The two modes are time-division multiplexed, the same target communication pin is used to receive the upgrade data packet and send the receiving feedback information, so that only one communication signal line (corresponding to a single target communication pin) is required at the physical level, the rigid requirement of two independent physical channels for simultaneous bidirectional operation in full-duplex communication is avoided, the communication pin resource requirement of the firmware upgrade is reduced from two to one, the occupation requirement of the communication pin resource is reduced, and the firmware upgrade function is applicable to embedded devices with scarce pin resources (such as single-pin communication sensor nodes).

[0076] Based on the first embodiment of the present application, the same or similar contents as the above-mentioned first embodiment can be referred to the above description, and will not be described in detail. On this basis, after the step of switching the communication mode of the target communication pin to the sending mode, the method further comprises:

[0077] Step A10, obtaining the sending mode duration of the target communication pin;

[0078] The sending mode duration refers to the effective maintenance time of the target communication pin in the TX mode, which can be the interval time between the time when the target communication pin is switched to the TX mode and the current time. Further, considering that the target communication pin may not send the receiving feedback information immediately after being switched to the TX mode, in order to more accurately measure the time when the target communication pin actually occupies the communication link for sending operation, the sending mode duration can be the interval time between the time when the target communication pin starts to send the receiving feedback information and the current time.

[0079] Further, in the TX mode, the sending mode duration of the target communication pin can be polled until the target communication pin is switched to the RX mode.

[0080] Step A20, if the sending mode duration is greater than or equal to the preset upper limit of the duration, the step of switching the communication mode of the target communication pin to the receiving mode is performed.

[0081] When the duration of the TX mode is greater than or equal to the preset upper limit of the duration, the target communication pin is switched to the RX mode. In this case, the target communication pin can be forcibly switched back to the RX mode. The preset upper limit of the duration can be a maximum allowed time representing the TX mode occupying the communication link resource, such as 1 s.

[0082] Further, when the duration of the TX mode is greater than or equal to the preset upper limit of the duration, a timeout retransmission for the received upgrade data packet can be triggered.

[0083] In this embodiment, when the duration of the TX mode of the target communication pin is greater than the preset upper limit of the duration, the target communication pin is switched back to the RX mode to avoid wasting of the communication resource or communication conflict caused by long-time occupation of the TX mode, and to ensure that the device can respond to a subsequent communication request in time and prevent the communication link from being blocked for a long time due to an abnormality.

[0084] In a possible implementation, the data transmission mode of the firmware upgrade device is an asynchronous mode. After the target communication pin in the communication mode of the TX mode sends the received feedback information, the method further includes the following steps:

[0085] Step B10: After starting to send the received feedback information, a data transmission completion interrupt event for the received feedback information is listened to.

[0086] Step B20: If the data transmission completion interrupt event for the received feedback information is listened to, it is determined that the sending of the received feedback information is completed.

[0087] The asynchronous mode refers to a data transmission mode in which, after a data transmission operation is started, the initiator can release the computing resource without blocking and waiting for the operation to be completed, and then perform other tasks or enter a standby state. In the asynchronous mode, the actual completion event of the data transmission operation is actively notified to the initiator through an event-driven mechanism (such as an interrupt).

[0088] Based on this, after the received feedback information is started to be sent, a data transmission completion interrupt event for the received feedback information can be listened to to listen to whether the sending of the received feedback information is completed. Further, the interrupt event can be listened to through an interrupt service program or a state register polling.

[0089] When the data transmission completion interrupt event is listened to, it is determined that the sending of the received feedback information is physically completed. The interrupt event is a direct sign of the end of the physical layer transmission.

[0090] The embodiment combines the non-blocking resource release mechanism in the asynchronous mode with the event notification driven by the hardware interrupt, and realizes the reliable determination of the transmission end state by means of the data transmission completion interrupt event triggered accurately by the physical layer, thereby guaranteeing the determinacy of the communication timing and improving the system resource utilization, and achieving the accurate identification of the physical layer transmission completion without the polling overhead.

[0091] In a possible implementation, the data transmission mode of the firmware upgrade device is a blocking mode, and after the step of sending the receiving feedback information based on the target communication pin in the communication mode of sending, the method further comprises:

[0092] Step C10, waiting for a target duration after starting to send the receiving feedback information, and determining that the sending of the receiving feedback information is completed after waiting for the target duration; and / or,

[0093] Step C20, polling a preset sending state flag bit after starting to send the receiving feedback information, and if the preset sending state flag bit indicates that the data sending is completed, determining that the sending of the receiving feedback information is completed.

[0094] The blocking mode (also referred to as the synchronous mode) refers to a mode in which the initiator continuously occupies the computing resource until the physical layer transmission is completed after starting the data transmission operation. In the synchronous mode, the data sending completion state is confirmed through the active waiting mechanism.

[0095] The target duration can be a fixed duration (hereinafter referred to as a preset reference waiting duration) set in advance, such as 200 microseconds, or a duration dynamically adjusted according to the actual transmission situation. It can be understood that the receiving feedback information is usually a data frame with a fixed length, and therefore, the preset reference waiting duration can be set based on the data frame size of the receiving feedback information and the transmission rate (which can be the average data transmission rate between the wearable device and the host device set by the relevant personnel), such as setting the preset reference waiting duration as the value obtained by multiplying the data frame size by the transmission rate and adding a certain margin, so as to guarantee that the receiving feedback information can be completely sent out within the duration under the normal data transmission situation.

[0096] The preset sending state flag bit is a flag bit indicating whether the hardware buffer storing the receiving feedback information is empty, such as the TXDRDY flag bit of the UART. When the preset sending state flag bit indicates that the hardware buffer storing the receiving feedback information is empty, it is determined that the preset sending state flag bit indicates that the data sending is completed; otherwise, when the preset sending state flag bit indicates that the hardware buffer storing the receiving feedback information is not empty, it is determined that the preset sending state flag bit indicates that the data sending is not completed.

[0097] In a preferred embodiment, in order to reduce the polling overhead, a target time duration is waited after starting to send the receiving feedback information, and it is determined that the sending of the receiving feedback information is completed after the target time duration.

[0098] In this embodiment, by using the timing system to guarantee simplicity, or by using the polling system to guarantee high reliability and timeliness of the sending completion determination, or by combining the double verification, the invalid waiting time is minimized in the blocking mode, while the high reliability of the sending completion determination is ensured, and the resource utilization and the response real-time performance are optimized.

[0099] Based on the first embodiment and / or the second embodiment of the present application, in the third embodiment of the present application, the same or similar contents as the above-mentioned first embodiment and second embodiment can be referred to the above description, and will not be repeated hereinafter. On this basis, the firmware upgrade device upgrades firmware based on the mcumgr protocol stack, and the step of obtaining the receiving feedback information for the upgrade data packet comprises:

[0100] Step D10, performing legality verification on the upgrade data packet based on the mcumgr protocol stack to obtain a verification result;

[0101] The legality verification includes but is not limited to data integrity verification and data validity verification, for example, using an AES (Advanced Encryption Standard) decryption algorithm to verify the validity of the upgrade data packet, and using a CRC (Cyclic Redundancy Check) algorithm to verify the integrity of the upgrade data packet.

[0102] Step D20, if the verification result is a verification pass, determining that the ACK response is the receiving feedback information for the upgrade data packet;

[0103] Step D30, if the verification result is a verification fail, determining that the NACK response is the receiving feedback information for the upgrade data packet.

[0104] It should be noted that the NACK response can be accompanied by a corresponding error code.

[0105] In this embodiment, the legality verification of the upgrade data packet based on the mcumgr protocol stack, on the one hand, guarantees the reliability of data transmission and is equivalent to the full-duplex communication mode; on the other hand, the mcumgr protocol stack is directly reused for legality verification, so that transparent adaptation of single-wire half-duplex communication is realized without modifying the mcumgr protocol stack, which significantly reduces the hardware cost and development threshold.

[0106] Exemplarily, in order to help understand the technical concept or technical principle of the firmware upgrading method combined with the first embodiment, a specific embodiment is listed, in which, referring to Figure 2 As shown in the figure, the firmware upgrading flow includes:

[0107] (1) Initialization configuration:

[0108] ① The target communication pin is initialized as RX mode, and the receiving function is enabled;

[0109] ② Enter the monitoring state, and wait for the firmware upgrading instruction (such as img_mgmt upload).

[0110] (2) Data receiving and response:

[0111] ① After receiving the SMP data packet (i.e. the upgrading data packet) sent by the host computer, the legality verification (CRC32, AES decryption) is performed;

[0112] ② Verification passed: switch to TX mode to send ACK response, and record the sending time T1;

[0113] ③ Verification failed: switch to TX mode to send NACK response (with error code), and record the sending time T1.

[0114] (3) Timing control and state switching:

[0115] Blocking mode: after the sending function is called, delay for 200 μs (i.e. wait for the target duration), and switch back to RX mode;

[0116] Asynchronous mode: after the data sending completion interrupt event is monitored, switch back to RX mode to avoid blocking the protocol stack thread.

[0117] (4) State care mechanism:

[0118] Poll the current state every 10 ms to obtain the current time T2, if the TX mode duration T2-T1>1s, force to switch to RX mode, and trigger retransmission.

[0119] Based on this, referring to Figure 3 As shown in the figure, the firmware upgrading flow based on the mcumgr protocol stack includes:

[0120] ① UART configuration: the single-wire pin is initialized as RX mode, and the mcumgr protocol stack enters RX_IDLE state (receiving waiting state);

[0121] ② Data receiving: receive the Nth packet of upgrading data (or retransmission failure packet) sent by the host computer, and the mcumgr protocol stack enters TX_ACK state (sending response state);

[0122] 3. Check: the protocol stack checks the data packet, if passed, generates an ACK response, otherwise generates a NACK response;

[0123] 4. Mode switching: switch to TX mode, call uart_send(ACK_PACKET) to send the response, record the sending time T1;

[0124] 5. Delay and switching (as shown in the blocking mode case): delay for 200us and switch back to RX mode in the blocking mode, switch back by sending a completion interrupt in the asynchronous mode, and the mcumgr protocol stack enters the RX_WAIT state (next packet receiving state); Figure 3

[0125] 6. Loop execution: repeat steps 2-5 until all data packets are transmitted (i.e. no new response is needed), and the mcumgr protocol stack reenters the RX_IDLE state (response sending state).

[0126] It should be noted that the above examples are only used to assist in understanding the embodiment and do not constitute a limitation on the firmware upgrade process of the embodiment. More forms of simple transformation based on this technical concept are within the protection scope of the present application.

[0127] Based on the first, second and / or third embodiments of the present application, in the fourth embodiment of the present application, the same or similar contents as the above-mentioned first embodiment, second embodiment and third embodiment can be referred to the above introduction, and will not be repeated hereinafter. On this basis, before the step of waiting for a target duration after starting to send the received feedback information, the method further comprises:

[0128] Step E10, if the upgrade data packet is the first frame data packet, determining that the preset reference waiting duration is the target duration;

[0129] The preset reference waiting duration can be the same as the preset reference waiting duration in the above-mentioned embodiments.

[0130] Step E20, if the upgrade data packet is not the first frame data packet, obtaining an adjacent data packet receiving interval duration, and determining the target duration based on the adjacent data packet receiving interval duration, wherein the adjacent data packet receiving interval duration is an interval duration between the receiving times of two adjacent frames of upgrade data packets; and wherein the target duration and the adjacent data packet receiving interval duration have a positive correlation trend.

[0131] ​The wearable device can record the receiving time of the current upgrade data packet each time after receiving the upgrade data packet, and calculate the time difference between the receiving time of the current upgrade data packet and the receiving time of the last upgrade data packet, that is, the adjacent data packet receiving interval length. For example, if the receiving time of the current upgrade data packet is t2, and the receiving time of the last upgrade data packet is t1, then the adjacent data packet receiving interval length Δt is Δt = t2 - t1.

[0132] Due to the differences in network conditions and device processing capabilities, the transmission time of data packets may vary. Based on this, the embodiment sets a positive correlation trend between the target length and the adjacent data packet receiving interval length. Specifically, if the adjacent data packet receiving interval length is longer, it means that the network delay or device processing time is longer, so a longer target length is waited for to ensure that the received feedback information can be sent within a reasonable time; on the contrary, if the adjacent data packet receiving interval length is shorter, a shorter target length can be waited for to improve the system response speed and transmission efficiency.

[0133] In this embodiment, the first frame data packet uses a preset reference waiting time to ensure the initial communication reliability, and the target length of the non-first frame data packet is dynamically generated based on the adjacent data packet receiving interval length Δt, and the positive correlation trend between the target length and the interval length is used to realize adaptive adjustment: when the network delay or device processing time is prolonged to cause Δt to increase, the target length is automatically prolonged to ensure that the received feedback information is completely sent; when Δt is shortened, the target length is shortened to improve the response speed. This mechanism synchronously optimizes the transmission reliability (avoids switching conflicts) and system efficiency (reduces resource waste) under the premise of compatibility of network volatility and device processing differences, and achieves a dynamic balance between communication stability and response real-time.

[0134] Specifically, as one of the implementation manners, the step of determining the target length based on the adjacent data packet receiving interval length comprises:

[0135] Step F10, based on a preset mapping relationship, obtaining a waiting time corresponding to the adjacent data packet receiving interval length, and determining the waiting time as the target length, wherein the preset mapping relationship is a mapping relationship between different adjacent data packet receiving interval lengths and waiting times.

[0136] The mapping relationship between different adjacent data packet receiving interval lengths and waiting times can be pre-configured and stored, and based on the mapping relationship, the waiting time corresponding to the time interval length to which the currently obtained adjacent data packet receiving interval length belongs is found. The mapping relationship can define the association rules between different ranges of adjacent data packet receiving interval length intervals and their respective unique waiting times. Further, the overall trend of the association rules of the mapping relationship can be positively correlated.

[0137] The adjacent data packet receiving interval duration is directly converted into the target waiting duration through a pre-stored mapping relationship, a mapping mechanism is used to realize fast decision with low calculation overhead, and processing delay is reduced. The positive correlation trend of the mapping rule as a whole ensures that a longer waiting gear is automatically matched when the interval duration increases, preventing communication conflicts in a high delay environment. When the interval duration is shortened, a shorter waiting gear is matched, reducing resource waste. This static mapping mechanism significantly reduces the processing burden of resource-constrained devices while ensuring network state adaptability, and is particularly suitable for embedded scenarios such as wearable devices, achieving simultaneous optimization of communication reliability and system efficiency.

[0138] As a second implementation, the step of determining the target duration based on the adjacent data packet receiving interval duration includes:

[0139] Step F20, obtaining a current target duration, adjusting the current target duration based on the interval time variation trend of the adjacent data packet receiving interval duration to obtain the target duration.

[0140] The system first obtains the current target duration Tcurrent, which is a preset reference waiting duration for the first frame, and is the target duration used last time for non-first frames.

[0141] After obtaining the adjacent data packet receiving interval duration this time, the variation trend of the adjacent data packet receiving interval duration Δt is analyzed. According to the interval time variation trend, the current target duration Tcurrent is adjusted. Specifically, if the variation trend is that Δt gradually increases, Tcurrent is increased; if the variation trend is that Δt gradually decreases, Tcurrent is decreased, and the adjusted target duration Tnew is used as the new target duration.

[0142] Further, the specific adjustment method can be a fixed increment or decrement, or a dynamic adjustment based on the Δt variation rate, and the adjustment amount is positively correlated with the Δt variation rate.

[0143] The target duration is dynamically iteratively adjusted by tracking the variation trend of the adjacent data packet receiving interval duration Δt in real time: when it is detected that Δt presents a gradually increasing trend, the current target duration is increased to actively adapt to the network delay deterioration situation and prevent communication conflicts; when it is detected that Δt presents a gradually decreasing trend, the target duration is decreased to quickly respond to the network state improvement; thereby the historical transmission rate variation trend is converted into an adaptive adjustment amount of the target duration, and the waiting duration and the network dynamics are continuously and synchronously optimized through incremental iteration (non-first frame inherits the previous target duration) to achieve balanced control of conflict avoidance and response delay in a fluctuating network environment.

[0144] As a third implementation, the step of determining the target time length based on the adjacent data packet receiving interval time length comprises:

[0145] Step F30, adjusting the preset reference waiting time length based on the adjacent data packet receiving interval time length to obtain the target time length.

[0146] The preset reference waiting time length is adjusted according to the adjacent data packet receiving interval time length Δt. The adjustment can be a linear relationship, for example, T=Tbase+k×Δt, where Tbase is the preset reference waiting time length, and k is a preset adjustment coefficient.

[0147] By setting the target time length as a linear combination of the preset reference waiting time length and the adjacent data packet receiving interval time length, the adaptive adjustment of dynamically following the network delay change is realized. The real-time measured adjacent data packet interval Δt is used as a variable, so that the timeout waiting time length can respond to the fluctuation of the actual transmission delay in real time. At the same time, by retaining the reference time length as a basic value, the influence of network instantaneous jitter is compatible, and the target time length always has a predictable lower limit, so as to avoid premature timeout caused by accidental delay while dynamically expanding the reasonable waiting window in the high delay scenario.

[0148] Further, in a possible implementation, after the step of obtaining the adjacent data packet receiving interval time length, the method further comprises:

[0149] Step G10, detecting whether the adjacent data packet receiving interval time length is greater than a preset upper limit receiving interval time length for a preset number of consecutive times;

[0150] The preset upper limit receiving interval time length is a pre-set threshold for judging whether the adjacent data packet receiving interval time length is abnormal.

[0151] Detect whether the adjacent data packet receiving interval time length reaches the preset upper limit receiving interval time length for a preset number of consecutive times. The preset number can be set according to actual needs, for example, 3 times, 5 times, etc. By detecting whether the adjacent data packet receiving interval time length is greater than the preset upper limit receiving interval time length for a preset number of consecutive times, it is determined whether the network or device is continuously in a high delay state.

[0152] After receiving each upgrade data packet, record the receiving time of the current upgrade data packet, and calculate the adjacent data packet receiving interval time length Δt. Compare Δt with the preset upper limit receiving interval time length, and record the number of consecutive times that Δt is greater than the preset upper limit receiving interval time length. For example, if the preset upper limit receiving interval time length is 5 seconds, the number of consecutive times that Δt>5 seconds will be recorded.

[0153] Step G20, if yes, determining that the preset reference waiting time length is the target time length;

[0154] If the adjacent data packet receiving interval duration is greater than the preset upper limit receiving interval duration for a preset number of times in succession, it indicates that the network or the device is in a high delay state continuously. In this case, the preset reference waiting duration is determined as the target duration.

[0155] In step G30, if no, the target duration is determined based on the adjacent data packet receiving interval duration.

[0156] If the adjacent data packet receiving interval duration is not greater than the preset upper limit receiving interval duration for a preset number of times in succession, it indicates that the delay of the network or the device is within a normal range. In this case, the target duration is adjusted dynamically according to the adjacent data packet receiving interval duration.

[0157] The embodiment detects whether the adjacent data packet receiving interval duration exceeds the preset upper limit receiving interval duration for a preset number of times in succession, to realize continuous abnormality judgment of the delay state of the network or the device. When the duration exceeds the upper limit continuously, it indicates that the network has entered a continuous high delay state, and in this case, the preset reference waiting duration is directly determined as the target duration, to avoid frequent triggering of the waiting duration adjustment mechanism due to the continuous high delay. Otherwise, the target duration is adjusted dynamically according to the real-time interval. In this way, the continuous number threshold is introduced to effectively filter incidental delay fluctuations, to prevent incidental delay from interfering with the normal waiting strategy, and to automatically switch to a more suitable reference waiting strategy when a continuous high delay is identified, thereby improving the stability of the timeout judgment and the adaptability to the real network state.

[0158] In addition, the embodiment of the application further provides a firmware upgrading device, which is deployed in a firmware upgrading device. The firmware upgrading device includes a target communication pin, and a communication mode of the target communication pin is initialized as a receiving mode. Referring to Figure 4 As shown in the figure, the firmware upgrading device includes:

[0159] The receiving module 10 is configured to receive an upgrading data packet based on the target communication pin in the receiving mode in response to a firmware upgrading instruction.

[0160] The switching module 20 is configured to acquire receiving feedback information for the upgrading data packet, and switch the communication mode of the target communication pin to a sending mode.

[0161] The sending module 30 is configured to send the receiving feedback information based on the target communication pin in the sending mode.

[0162] The switching module 20 is further configured to switch the communication mode of the target communication pin to the receiving mode after the sending of the receiving feedback information is completed, to continue receiving a next upgrading data packet, and perform firmware upgrading after all the upgrading data packets are received.

[0163] In an embodiment, the switching module 20 is further configured to:

[0164] acquire a transmission mode duration of the target communication pin;

[0165] if the transmission mode duration is greater than or equal to a preset upper limit of duration, switch the communication mode of the target communication pin to a receiving mode.

[0166] In an embodiment, the data transmission mode of the firmware upgrade device is an asynchronous mode, and the sending module 30 is further configured to:

[0167] after starting to send the receiving feedback information, listen to a data sending completion interrupt event for the receiving feedback information;

[0168] if the data sending completion interrupt event for the receiving feedback information is listened to, determine that the receiving feedback information is sent completely.

[0169] In an embodiment, the data transmission mode of the firmware upgrade device is a blocking mode, and the sending module 30 is further configured to:

[0170] after starting to send the receiving feedback information, wait for a target duration, and after waiting for the target duration, determine that the receiving feedback information is sent completely; and / or,

[0171] after starting to send the receiving feedback information, poll a preset sending state flag bit, and if the preset sending state flag bit indicates that data sending is ended, determine that the receiving feedback information is sent completely.

[0172] In an embodiment, the sending module 30 is further configured to:

[0173] if the upgrade data packet is a first frame data packet, determine that a preset reference waiting duration is the target duration;

[0174] if the upgrade data packet is a non-first frame data packet, acquire an adjacent data packet receiving interval duration, and determine the target duration based on the adjacent data packet receiving interval duration, wherein the adjacent data packet receiving interval duration is an interval duration between receiving times of adjacent two frames of upgrade data packets.

[0175] wherein the target duration and the adjacent data packet receiving interval duration are positively correlated.

[0176] In an embodiment, the sending module 30 is further configured to:

[0177] obtaining a waiting duration corresponding to the adjacent data packet receiving interval duration based on a preset mapping relationship, and determining the waiting duration as the target duration, wherein the preset mapping relationship is a mapping relationship between different adjacent data packet receiving interval durations and waiting durations; or

[0178] obtaining a current target duration, adjusting the current target duration based on a variation trend of the interval time of the adjacent data packet receiving interval duration to obtain the target duration; or

[0179] adjusting a preset reference waiting duration based on the adjacent data packet receiving interval duration to obtain the target duration.

[0180] In an embodiment, the sending module 30 is further configured to:

[0181] detecting whether the adjacent data packet receiving interval duration is greater than a preset upper limit receiving interval duration for a preset number of times in succession;

[0182] if yes, determining that a preset reference waiting duration is the target duration;

[0183] if no, performing the determining the target duration based on the adjacent data packet receiving interval duration.

[0184] In an embodiment, the firmware upgrading device upgrades firmware based on an mcumgr protocol stack, and the firmware upgrading apparatus further comprises a verifying module configured to:

[0185] performing legality verification on the upgrade data packet based on the mcumgr protocol stack to obtain a verification result;

[0186] if the verification result is a verification pass, determining that an ACK response is reception feedback information for the upgrade data packet;

[0187] if the verification result is a verification fail, determining that a NACK response is reception feedback information for the upgrade data packet.

[0188] In addition, an embodiment of the present application further provides a firmware upgrading device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the firmware upgrading method.

[0189] Reference Figure 5 which shows a structural schematic diagram of a firmware upgrading device suitable for being used to implement an embodiment of the present application. The firmware upgrading device in the embodiment of the present application can also include, but is not limited to, mobile terminals such as wearable devices, smart home appliances, smart sensors, industrial controllers, and the like, and fixed terminals such as digital TVs, desktop computers, and the like. Figure 5The illustrated firmware upgrade device is merely one example and should not be taken as limiting the functionality or use of embodiments of the application.

[0190] As shown in Figure 5 The firmware upgrade device can include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to programs stored in a read only memory (ROM) 1002 or loaded from a storage device 1003 into a random access memory (RAM) 1004. Various programs and data required for operation of the firmware upgrade device are also stored in the RAM 1004. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; the storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the firmware upgrade device to communicate wirelessly or wired with other devices to exchange data. Although the firmware upgrade device is shown with various systems, it should be understood that not all of the illustrated systems are required to be implemented or present. More or fewer systems can alternatively be implemented or present.

[0191] In particular, the processes described above with reference to the flowcharts can be implemented as a computer software program according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program carrying computer program code for performing the methods illustrated by the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of embodiments of the present disclosure are performed.

[0192] The firmware upgrading device provided by the embodiments of the present application adopts the firmware upgrading method in the above embodiments, and can solve the technical problem that the current firmware upgrading relies on full duplex communication mode, has high resource demand for communication pins, and leads to the possibility that the firmware upgrading cannot be applied to devices with scarce pin resources. Compared with the prior art, the firmware upgrading device provided by the present application has the same beneficial effects as the firmware upgrading method provided by the above embodiments, and other technical features in the firmware upgrading device are the same as the features disclosed in the previous embodiment method, which will not be described here.

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

[0194] The above describes only specific embodiments of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed by the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0195] In addition, to achieve the above-mentioned purpose, the embodiments of the present application also provide a readable storage medium having computer readable program instructions (i.e. computer programs) stored thereon, and the computer readable program instructions are used to execute the firmware upgrading method in the above embodiments.

[0196] The computer readable storage medium provided by the embodiments of the present application may, for example, be a U disk, but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination of the above. More specific examples of the computer readable storage medium may include, but are not limited to, an electrical connection having one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read only memory (ROM), an erasable programmable read only memory (EPROM or flash memory), an optical fiber, a portable compact disk read only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the embodiments, the computer readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electrical wire, an optical cable, an RF (Radio Frequency), and the like, or any suitable combination of the above.

[0197] The above computer readable storage medium may be contained in the firmware upgrade device, or may exist separately without being assembled into the firmware upgrade device.

[0198] The above computer readable storage medium carries one or more programs, when the one or more programs are executed by the firmware upgrade device, the firmware upgrade device is caused to: in response to a firmware upgrade instruction, receive an upgrade data packet based on a target communication pin in a receiving mode; obtain receiving feedback information for the upgrade data packet, and switch the communication mode of the target communication pin to a sending mode; send the receiving feedback information based on the target communication pin in the sending mode; after the receiving feedback information is sent, switch the communication mode of the target communication pin to the receiving mode to continue receiving the next upgrade data packet, and perform firmware upgrade after all the upgrade data packets are received.

[0199] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0200] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may

[0201] The modules involved in the embodiments of the present application can be implemented in the form of software or in the form of hardware. In some cases, the name of the module does not constitute a limitation on the module itself.

[0202] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e. computer programs) for executing the above-mentioned firmware upgrading method, and can solve the technical problem that the current firmware upgrading depends on a full duplex communication mode, has a high demand for resources of communication pins, and may not be applicable to firmware upgrading of devices with scarce pin resources. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the firmware upgrading method provided by the above-mentioned embodiments, and will not be described here.

[0203] In addition, the embodiment of the present application further provides a computer program product comprising a computer program, which, when executed by a processor, implements the steps of the firmware upgrading method as described above.

[0204] The computer program product embodiment of the present application is basically the same as the above-mentioned firmware upgrading method embodiments, and thus will not be described here again.

[0205] It should be noted that, in this document, the terms "comprising", "containing" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or further includes elements inherent to such a process, method, article or system. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of other identical elements in the process, method, article or system including the element.

[0206] The above-mentioned serial numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0207] Through the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be realized by means of software and necessary general hardware platforms, of course, they can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application or the part that contributes to the prior art can be embodied in the form of a software sensor, which is stored in a storage medium (such as ROM / RAM, magnetic disc, optical disc) as described above, and includes a number of instructions for making a terminal device (which can be a mobile phone, computer, server or network device, etc.) execute the methods described in various embodiments of the present application.

[0208] The above is only the preferred embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent structure or equivalent process transformation, or direct or indirect application in other related technical fields based on the content of the present application specification and drawings, are also included in the patent protection scope of the present application.

Claims

1. A firmware upgrade method characterized by comprising: The firmware upgrading method is applied to a firmware upgrading device, the firmware upgrading device comprises a target communication pin, a communication mode of the target communication pin is initialized as a receiving mode, and the firmware upgrading method comprises the following steps: receiving an upgrading data packet based on the target communication pin in the receiving mode in response to a firmware upgrading instruction; obtaining receiving feedback information for the upgrading data packet, and switching the communication mode of the target communication pin to a sending mode; sending the receiving feedback information based on the target communication pin in the sending mode; after the sending of the receiving feedback information is completed, switching the communication mode of the target communication pin to the receiving mode to continue receiving a next upgrading data packet, and performing firmware upgrading after all the upgrading data packets are received.

2. The firmware upgrade method of claim 1, wherein, After the step of switching the communication mode of the target communication pin to the sending mode, the method further comprises: obtaining a sending mode duration of the target communication pin; if the sending mode duration is greater than or equal to a preset upper limit of the duration, performing the step of switching the communication mode of the target communication pin to the receiving mode.

3. The firmware upgrade method of claim 1, wherein, The data transmission mode of the firmware upgrading device is an asynchronous mode, and after the step of sending the receiving feedback information based on the target communication pin in the sending mode, the method further comprises: after starting to send the receiving feedback information, listening to a data sending completion interrupt event for the receiving feedback information; if the data sending completion interrupt event for the receiving feedback information is listened to, determining that the sending of the receiving feedback information is completed.

4. The firmware upgrade method of claim 1, wherein, The data transmission mode of the firmware upgrading device is a blocking mode, and after the step of sending the receiving feedback information based on the target communication pin in the sending mode, the method further comprises: after starting to send the receiving feedback information, waiting for a target duration, and after the target duration, determining that the sending of the receiving feedback information is completed; and / or after starting to send the receiving feedback information, polling a preset sending state flag bit, and if the preset sending state flag bit indicates that data sending is completed, determining that the sending of the receiving feedback information is completed.

5. The firmware upgrade method of claim 4, wherein, Before the step of waiting for the target duration after starting to send the receiving feedback information, the method further comprises: if the upgrading data packet is a first data packet, determining that a preset reference waiting duration is the target duration; if the upgrading data packet is a non-first data packet, obtaining an adjacent data packet receiving interval duration, determining the target duration based on the adjacent data packet receiving interval duration, wherein the adjacent data packet receiving interval duration is an interval duration between receiving times of adjacent two upgrading data packets; wherein the target duration and the adjacent data packet receiving interval duration have a positive correlation trend.

6. The firmware upgrade method of claim 5, wherein, The step of determining the target duration based on the adjacent data packet receiving interval duration comprises: obtaining the waiting duration corresponding to the adjacent data packet receiving interval duration based on a preset mapping relationship, and determining the waiting duration as the target duration, wherein the preset mapping relationship is a mapping relationship between different adjacent data packet receiving interval durations and waiting durations; or obtaining a current target duration, adjusting the current target duration based on a variation trend of the interval time of the adjacent data packet receiving interval duration to obtain the target duration; or adjusting a preset reference waiting duration based on the adjacent data packet receiving interval duration to obtain the target duration.

7. The firmware upgrade method of claim 5, wherein, After the step of obtaining the adjacent data packet receiving interval duration, the method further comprises: detecting whether the adjacent data packet receiving interval duration is greater than a preset upper limit receiving interval duration for a preset number of times in succession; if yes, determining that the preset reference waiting duration is the target duration; if no, performing the step of determining the target duration based on the adjacent data packet receiving interval duration.

8. The firmware upgrade method according to any one of claims 1 to 7, wherein, The firmware upgrade device performs firmware upgrade based on an mcumgr protocol stack, and the step of obtaining the receiving feedback information for the upgrade data packet comprises: performing legality verification on the upgrade data packet based on the mcumgr protocol stack to obtain a verification result; if the verification result is verification passed, determining that an ACK response is the receiving feedback information for the upgrade data packet; if the verification result is verification failed, determining that a NACK response is the receiving feedback information for the upgrade data packet.

9. A firmware upgrade device, characterized by, comprises: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is executed by the processor to implement the firmware upgrade method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a firmware upgrade program, and the firmware upgrade program is executed by the processor to implement the steps of the firmware upgrade method according to any one of claims 1 to 8.

Images