Online upgrading method, device, equipment and storage medium

Abstract

This application discloses an online upgrade method, apparatus, device, and storage medium, relating to the field of display technology and applied to a slave device. The method includes: receiving a fusion upgrade package forwarded by a master device, wherein the fusion upgrade package includes a firmware data segment and an additional data segment, the additional data segment containing verification information of the firmware data segment; parsing the verification information from the fusion upgrade package, and performing a first verification on the firmware data segment in the fusion upgrade package based on a preset length of the firmware data segment included in the verification information and a first verification value; if the first verification passes, performing a second verification on the firmware matching identifier included in the verification information; if the second verification passes, performing an upgrade operation on the firmware data to be upgraded on the slave device according to the fusion upgrade package. This application improves the reliability and security of online upgrades.

Description

Technical Field

[0001] This application relates to the field of display technology, and in particular to online upgrade methods, online upgrade devices, slave devices, and storage media. Background Technology

[0002] Existing online upgrade methods (OTA, Over-the-Air Technology) typically involve a master device, such as a SoC, obtaining an upgrade package via a network or USB flash drive. The upgrade package is then forwarded to a slave device, such as an MCU, through complex protocol interactions. During this complex protocol interaction, the master and slave devices need to communicate via handshakes multiple times to transmit the length of the upgrade package, the checksum, and the firmware data. Furthermore, the master device is responsible for verifying the integrity and version matching of the upgrade package. The slave device passively responds to the master device's instructions and directly performs the firmware update after receiving the data.

[0003] In this online upgrade method that relies on the master device for verification and the slave device for receiving and upgrading, when the communication link between the master device and the slave device is abnormal, the complex interaction process itself is very likely to cause data packet loss or errors. Alternatively, the master device may push an incorrect firmware version during the complex version management process. Since the slave device only has the ability to receive and relies entirely on the verification result of the master device, it will still write the received upgrade package as a legitimate program into the storage area, thereby writing incorrect or corrupted firmware code. This causes the slave device to fail to start normally or run abnormally after reset, resulting in the problem of slave device failure after upgrade failure. Summary of the Invention

[0004] The main objective of this application is to provide an online upgrade method, an online upgrade device, a slave device, and a storage medium, aiming to solve the technical problem that data packet loss or errors are prone to occur during online upgrades, leading to upgrade failure.

[0005] To achieve the above objectives, this application proposes an online upgrade method applied to a slave device, the online upgrade method comprising: The system receives a fusion upgrade package forwarded by the main control device, wherein the fusion upgrade package includes a firmware data segment and an additional data segment, and the additional data segment contains verification information of the firmware data segment; The verification information is parsed from the fusion upgrade package, and the firmware data segment in the fusion upgrade package is subjected to a first verification based on the preset length of the firmware data segment included in the verification information and the first verification value. If the first verification passes, a second verification is performed on the firmware matching identifier included in the verification information; If the second verification passes, the firmware data to be upgraded on the slave device is upgraded according to the fusion upgrade package.

[0006] In one embodiment, the step of performing a first verification on the firmware data segment in the fusion upgrade package based on the preset length of the firmware data segment included in the verification information and a first verification value includes: Obtain the actual length of the received firmware data segment, and determine the second check value based on the actual length; Compare the preset length with the actual length, and the first check value with the second check value.

[0007] In one embodiment, after the step of comparing the preset length with the actual length, and the first check value with the second check value, the method includes: If the preset length is consistent with the actual length, and the first verification value is consistent with the second verification value, then the first verification is determined to be successful. If the preset length is inconsistent with the actual length, or the first verification value is inconsistent with the second verification value, then the first verification is determined to have failed.

[0008] In one embodiment, the step of performing a second verification on the firmware matching identifier included in the verification information if the first verification passes includes: Read the firmware matching identifier already stored in the preset storage area of ​​the slave device; Compare the firmware matching identifier in the preset storage area with the firmware matching identifier included in the verification information to see if they are consistent.

[0009] In one embodiment, the step of performing an upgrade operation on the firmware data to be upgraded of the slave device according to the fusion upgrade package when the second verification passes includes: Erase the firmware data to be upgraded stored in the preset storage area of ​​the slave device; The firmware data segment in the fusion upgrade package is written as new firmware data into the preset storage area.

[0010] In one embodiment, the slave device is used to control backlight LEDs, and the method further includes: Before triggering the upgrade, the current backlight control status parameters are reported to the main control device; After the master control device takes over the backlight control according to the backlight control status parameters, it triggers the slave device to perform an upgrade operation. After the upgrade is completed, the backlight control status parameters sent by the main control device are received, and the backlight control rights are restored through the backlight control status parameters.

[0011] In one embodiment, after the step of receiving the converged upgrade package forwarded by the master control device, the method further includes: Store the fusion upgrade package in a preset storage area; The length of the received data is recorded during the reception of the fusion upgrade package; When the reception of the fusion upgrade package is confirmed to be complete based on the data length, the first verification is triggered, wherein the recorded data length is used as the actual length of the firmware data segment.

[0012] Furthermore, to achieve the above objectives, this application also proposes an online upgrade device for use in a slave device, the online upgrade device comprising: A receiving module is used to receive a fusion upgrade package forwarded by the master control device, wherein the fusion upgrade package includes a firmware data segment and an additional data segment, and the additional data segment contains the verification information of the firmware data segment; The first verification module is used to parse the verification information from the fusion upgrade package, and perform a first verification on the firmware data segment in the fusion upgrade package according to the preset length of the firmware data segment included in the verification information and the first verification value. The second verification module is used to perform a second verification on the firmware matching identifier included in the verification information if the first verification passes. The upgrade module is used to perform an upgrade operation on the firmware data to be upgraded of the slave device according to the fusion upgrade package if the second verification passes.

[0013] In addition, to achieve the above objectives, this application also proposes a slave device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the online upgrade method as described above.

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

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the online upgrade method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: By receiving the fusion upgrade package forwarded by the master control device, which includes a firmware data segment and an additional data segment, and the additional data segment contains verification information of the firmware data segment, the slave device can directly parse the verification information from the fusion upgrade package without relying on the master control device to transmit the verification information item by item through complex protocol interaction. The slave device can then perform a first verification on the firmware data segment based on the preset length and first verification value of the firmware data segment included in the verification information. Thus, the slave device can autonomously complete the integrity verification of the firmware data segment before the fusion upgrade package is written to the preset storage area. This avoids the problem of data packet loss or incorrect packets being mistakenly written as legitimate programs due to communication link abnormalities during the complex protocol interaction between the master control device and the slave device.

[0017] If the first verification passes, a second verification is performed on the firmware matching identifier included in the verification information. This means that the slave device independently verifies whether the version or model indicated by the verification information matches the current slave device, avoiding firmware mismatch issues caused by the master device pushing incorrect firmware versions during complex version management. Only when both the first and second verifications pass will the upgrade operation be performed on the firmware data to be upgraded on the slave device. This ensures that the firmware code written to the storage area is a complete, correct program that has been independently and double-verified by the slave device and matches the current device. This effectively solves the problem of slave device failure after upgrade failure due to reliance on the master device for verification and the slave device only having receiving capabilities in the prior art. Attached Figure Description

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

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

[0020] Figure 1 A flowchart illustrating an embodiment of the online upgrade method of this application. Figure 1 ; Figure 2 A schematic diagram of a preset storage area provided in an embodiment of the online upgrade method of this application; Figure 3 A flowchart illustrating an embodiment of the online upgrade method of this application. Figure 2 ; Figure 4 A flowchart illustrating an embodiment of the online upgrade method of this application. Figure 3 ; Figure 5 This is a schematic diagram of the module structure of the online upgrade device of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the online upgrade method of this application.

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

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] This application relates to an online upgrade method applicable to backlight constant current software upgrades in Mini-LED (Mini Light Emitting Diode) televisions. Specifically, this method is suitable for electronic systems consisting of a master control device (such as a host computer or front-end system-on-a-chip, SOC) and a slave device (such as a backlight microcontroller unit, MCU), where the slave device is responsible for executing key functions such as backlight constant current control. This method allows for remote firmware upgrades of the slave device via serial port, USB flash drive, or network online push without disassembling the television casing. This method is not only applicable to backlight constant current software upgrades in LED (Light Emitting Diode) or Mini-LED televisions, but can also be extended to software upgrades of other television components and other electronic products requiring online firmware upgrades.

[0025] With the continuous advancement of display technology, ordinary LED TVs can no longer meet the demands for higher picture quality. Local dimming technology combined with High Dynamic Range (HDR) technology has become an important means to improve picture quality. Mini-LED technology uses tens of thousands of miniature light-emitting diodes as backlights, combined with local dimming technology, to achieve backlight control of tens of thousands of backlight zones. The more backlight zones, the better the display effect. However, as the number of backlight zones increases, the difficulty of backlight control increases significantly, especially when the number of backlight zones exceeds 2,000, where response latency becomes a prominent issue. To solve this problem, multiple microcontroller units are usually used for coordinated control. Currently, the microcontroller units in multi-backlight zone constant current boards communicate with the motherboard using a serial peripheral interface protocol, and software upgrades for the microcontroller units rely on traditional debugging interfaces for programming. This method is only suitable for engineering prototype development. In mass production and after-sales scenarios, updating and iterating the constant current software of the entire machine is extremely inconvenient and prone to failure due to software version inconsistencies or communication anomalies, causing the microcontroller units to malfunction, i.e., becoming "bricked". Therefore, the online upgrade function of the microcontroller unit is particularly important in the Mini-LED backlight control system.

[0026] To address the aforementioned problems, this invention proposes an online upgrade method applied to slave devices (such as backlight microcontroller units). This method, based on traditional online upgrades, involves a master control device forwarding a fusion upgrade package. The fusion upgrade package includes a firmware data segment and an additional data segment, with the additional data segment containing verification information for the firmware data segment. Upon receiving the fusion upgrade package, the slave device first parses the verification information from the package and performs a first verification on the firmware data segment based on this information (e.g., length verification and checksum comparison). If the first verification passes, a second verification is performed on the verification information (e.g., firmware matching identifier comparison). Only after both verifications pass does the upgrade operation on the firmware data to be upgraded on the slave device execute according to the fusion upgrade package. This method modifies existing upgrade packages to obtain fusion upgrade packages and implements a dual verification mechanism on the received fusion upgrade packages. This enables the slave device to autonomously identify the integrity and legitimacy of the fusion upgrade package without requiring the master control device to participate in complex verification logic, thereby effectively avoiding upgrade failures caused by communication packet loss, firmware mismatch, and other issues. In this method, the master control device only needs to have forwarding function, thus having good platform versatility. There is no need to adjust the communication protocol due to changes in the master control device platform, which significantly improves the reliability and success rate of the upgrade and ensures the security and stability of the device in remote upgrade scenarios.

[0027] It should be noted that the execution entity in this embodiment can be a slave device, such as a backlight MCU, or a computing device with data processing, communication interface, and program execution functions, such as a microcontroller, embedded processor, or an electronic device capable of performing the above functions. The following description uses a slave device as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, the embodiments of this application provide an online upgrade method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the online upgrade method of this application.

[0029] In this embodiment, applied to a slave device, the online upgrade method includes steps S1 to S4: Step S1: Receive the fusion upgrade package forwarded by the master control device, wherein the fusion upgrade package includes a firmware data segment and an additional data segment, and the additional data segment contains the verification information of the firmware data segment; It should be noted that the slave device is the target device to be upgraded. Optionally, the slave device can be a backlight microcontroller unit, which is responsible for controlling the constant current drive and local dimming function of the Mini-LED backlight.

[0030] The master control device is a host device that communicates with the slave devices. Optionally, the master control device can be a front-end system-on-a-chip of the TV, which is responsible for running the operating system, connecting to the network, reading external storage devices, and coordinating the work of various hardware modules.

[0031] A merge upgrade package is an upgrade file pre-generated in the development environment. Optionally, the merge upgrade package is created by developers using scripts to merge the original firmware (corresponding to the firmware data segment) with verification information.

[0032] The merge upgrade package includes a firmware data segment and an additional data segment. The firmware data segment is the original program code to be written to the slave device to update the control functions of the slave device. The additional data segment is an extra data block appended to the end of the firmware data segment, containing the verification information of the firmware data segment.

[0033] Verification information is metadata used to verify the integrity and legality of firmware data segments. Optionally, verification information includes the length of the firmware data segment, the cyclic redundancy check value of the firmware data segment, and the chip program identification number (i.e., firmware matching identifier). The length is in bytes, the cyclic redundancy check value can be calculated using the CRC (Cyclic Redundancy Check) algorithm, and the firmware matching identifier is an identifier that is written into the firmware in advance during compilation to identify the slave device model or version to which the firmware is applicable.

[0034] After receiving the fusion upgrade package, the master control device does not parse or verify the contents of the fusion upgrade package, but forwards the fusion upgrade package to the slave device without modification through the communication interface. Optionally, the communication interface can be a serial peripheral interface, an internal integrated circuit bus, or a universal asynchronous transceiver.

[0035] By receiving the fusion upgrade package forwarded by the master control device, the slave device can obtain the fusion upgrade package containing complete verification information, enabling the slave device to perform verification independently. At the same time, since the master control device does not need to participate in the verification logic, the software implementation of the master control device is simplified, and the versatility and portability of the entire online upgrade method are improved.

[0036] In one feasible implementation, after receiving the converged upgrade package forwarded by the master control device in step S1, the method further includes: Step S11: Store the fusion upgrade package in a preset storage area; It should be noted that the preset storage area is a fixed storage space specifically allocated from the non-volatile memory of the slave device, used to temporarily store firmware data to be upgraded. Optionally, the preset storage area can be a backup storage space in flash memory, which is independent of the main storage space that stores the currently running program.

[0037] During the process of receiving the converged upgrade package forwarded by the master control device, the slave device writes the received data byte by byte to a designated address in the backup storage space, completely preserving the original content of the converged upgrade package, including the firmware data segment and the additional data segment.

[0038] By storing the fusion upgrade package in a separate preset storage area, the slave device can completely save the firmware data to be upgraded without affecting the program currently running in the main storage space. It can perform reliable verification and upgrade operations. At the same time, since the backup storage space is isolated from the main storage space, even if an anomaly occurs during the upgrade process, it will not damage the program running in the main storage space, thus ensuring the basic operating capabilities of the slave device.

[0039] Step S12: Record the length of the received data during the reception of the fusion upgrade package; It should be noted that the slave device continuously obtains the converged upgrade package data from the master device through the communication interface. Optionally, the communication interface can be a serial peripheral interface, an internal integrated circuit bus, or a universal asynchronous transceiver.

[0040] The received data length refers to the total number of bytes of converged upgrade packet data received by the slave device from the start of reception to the current moment. During the reception process, the slave device maintains a counter variable. Each time a data packet is received, the length of that data packet is added to the counter, and the received data length is updated in real time.

[0041] By dynamically recording the length of the received data during the receiving process, the slave device can grasp the total amount of received data in real time. This is used to determine whether the fusion upgrade package has been received and to count the actual length of the firmware data segment, avoiding the extra overhead of re-counting the data after the reception is completed.

[0042] Step S13: When the reception of the fusion upgrade package is confirmed to be completed according to the data length, the first verification is triggered, wherein the recorded data length is used as the actual length of the firmware data segment.

[0043] It should be noted that the slave device compares the length of the currently received data with the total length of the fusion upgrade package. When the length of the received data is equal to the total length of the fusion upgrade package, it is determined that all data has been successfully received. The total length of the fusion upgrade package can be known in advance during the reception process. Optionally, the total length of the fusion upgrade package can be included in the header information of the communication protocol or obtained by parsing from the additional data segment.

[0044] Triggering the first verification means that after the confirmation of receipt is completed, the slave device automatically starts the first verification process to verify the integrity of the stored firmware data segments.

[0045] In the subsequent first verification, the recorded length of received data is directly used as the actual length of the firmware data segment, which is then compared with the preset length in the additional data segment.

[0046] By automatically triggering the first verification upon confirmation of reception completion and directly using the data length recorded during reception as the actual length, the slave device achieves seamless connection between reception and verification, avoiding duplicate statistics or additional processing, improving verification efficiency. At the same time, since the actual length comes from the real-time cumulative recording during reception, it can truly reflect the amount of data received and accurately determine the integrity of firmware data segments.

[0047] Step S2: Parse the verification information from the fusion upgrade package, and perform a first verification on the firmware data segment in the fusion upgrade package according to the preset length of the firmware data segment and the first verification value included in the verification information; It should be noted that after receiving the convergence upgrade package, the slave device will temporarily store the convergence upgrade package in the preset backup storage space.

[0048] Then, the slave device extracts the verification information from the additional data segment in the fusion upgrade package according to the agreed data format. Optionally, the additional data segment is located at the end of the fusion upgrade package. The slave device calculates the total length of the fusion upgrade package minus the fixed length of the additional data segment to locate the starting position of the additional data segment, and then reads the preset length of the firmware data segment and the first verification value such as the cyclic redundancy check value in the verification information.

[0049] The first verification is a process to verify whether the firmware data segment is complete and has not been tampered with during transmission. Optionally, the first verification includes length verification and cyclic redundancy check. Length verification refers to the slave device calculating the actual amount of firmware data segment received and comparing it with the firmware data segment length in the verification information to confirm whether the received data is complete. Cyclic redundancy check refers to the slave device recalculating the CRC value of the received firmware data segment and comparing it with the cyclic redundancy check value in the verification information to confirm whether the data content is correct.

[0050] Since the slave device performs length verification and cyclic redundancy verification independently after parsing the verification information from the end of the fusion upgrade package, it can independently determine whether there is packet loss, packet error or data corruption in the firmware data segment during transmission without relying on the master control device. This avoids writing incomplete programs to the slave device due to communication abnormalities and effectively prevents the slave device from becoming bricked due to program writing errors.

[0051] Step S3: If the first verification passes, perform a second verification on the firmware matching identifier included in the verification information; It should be noted that passing the first verification means that both the length verification and the cyclic redundancy check are consistent, at which point the firmware data segment is confirmed to be complete and correct.

[0052] The second verification is a verification process to check whether the firmware data segment matches the hardware of the slave device. Optionally, the second verification compares the firmware matching identifier in the verification information with the preset identification number in the currently running program of the slave device (i.e., the firmware matching identifier that has been stored in the preset storage area of ​​the slave device) to confirm whether the fusion upgrade package is applicable to the current slave device.

[0053] The firmware matching identifier is a unique identifier written when compiling firmware, used to distinguish between different models of slave devices or different versions of firmware.

[0054] Since the slave device performs a second verification on the firmware matching identifier after completing the first verification, it can avoid firmware mismatch caused by the master device pushing an incorrect upgrade package. Only the fusion upgrade package with matching firmware matching identifier can enter the subsequent upgrade process. Otherwise, the slave device will refuse to upgrade and continue to run the original program, thereby preventing the slave device from failing to work properly due to writing mismatched firmware.

[0055] Step S4: If the second verification passes, perform an upgrade operation on the firmware data to be upgraded of the slave device according to the fusion upgrade package.

[0056] It should be noted that passing the second verification means that the firmware matching identifier matches, which confirms that the fusion upgrade package matches the hardware of the slave device.

[0057] Then, the firmware data segment is written to the designated storage area of ​​the slave device to complete the program update. Optionally, refer to... Figure 2 The upgrade operation includes: writing the upgrade flag of the slave device into the flag storage area 300 (i.e., the FLAG area). Optionally, the upgrade flag is a preset specific value used to identify the existence of firmware to be upgraded; then resetting the slave device to restart it; during the startup process, after the bootloader 400 (i.e., the boot program) detects the upgrade flag, it reads the firmware matching identifier stored in the flag storage area and compares it again with the preset firmware matching identifier in the firmware data segment. After confirming that they match, it erases the main storage space 100 (i.e., the APP main area), writes the firmware data segment temporarily stored in the backup storage space 200 (i.e., the APP backup area) into the main storage space 100 (i.e., the APP main area), and finally clears the upgrade flag and jumps to the main storage space 100 (i.e., the APP main area) to run the new program.

[0058] By performing the upgrade operation only after both the first and second verifications pass, the slave device has completed dual verification of data integrity and hardware compatibility before writing the new program. Furthermore, firmware matching identification is compared again during the boot process, forming a multi-layered protection mechanism to ensure that only complete, correct, and matching firmware is written to the main storage space. This minimizes the risk of the slave device becoming unusable due to upgrade failure, thereby improving the reliability and security of online upgrades.

[0059] This embodiment provides an online upgrade method. By receiving a fusion upgrade package forwarded by the master control device, the fusion upgrade package includes a firmware data segment and an additional data segment. The additional data segment contains verification information of the firmware data segment. This allows the slave device to directly parse the verification information from the fusion upgrade package without relying on the master control device to transmit the verification information item by item through complex protocol interactions. The slave device then performs a first verification on the firmware data segment based on the preset length and first verification value of the firmware data segment included in the verification information. Thus, the slave device autonomously performs integrity verification on the firmware data segment before the fusion upgrade package is written to the preset storage area. This avoids the problem of data packet loss or incorrect packets being mistakenly written as legitimate programs due to communication link anomalies during complex protocol interactions between the master control device and the slave device. If the first verification passes, a second verification is performed on the firmware matching identifier included in the verification information. This means that the slave device independently verifies whether the version or model indicated by the verification information matches the current slave device, avoiding firmware mismatch issues caused by the master device pushing incorrect firmware versions during complex version management. Only when both the first and second verifications pass will the upgrade operation be performed on the firmware data to be upgraded on the slave device. This ensures that the firmware code written to the storage area is a complete, correct program that has been independently and double-verified by the slave device and matches the current device. This effectively solves the problem of slave device failure after upgrade failure due to reliance on the master device for verification and the slave device only having receiving capabilities in the prior art.

[0060] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, step S2, the step of performing a first verification on the firmware data segment in the fusion upgrade package according to the preset length of the firmware data segment included in the verification information and the first verification value, includes: Step S21: Obtain the actual length of the received firmware data segment, and determine the second check value based on the actual length; It should be noted that the preset length is the amount of original firmware data stored in the additional data segment. Optionally, the preset length is in bytes. When generating the fusion upgrade package, the amount of original firmware data is calculated by a script and written into the additional data segment.

[0061] The first check value is the original check result of the firmware data segment pre-stored in the additional data segment. Optionally, the first check value is calculated by using the CRC algorithm on the original firmware and is a 32-bit unsigned integer.

[0062] The actual length of the received firmware data segment refers to the total number of bytes actually transmitted by the slave device during the process of receiving the fusion upgrade package by counting the amount of firmware data received from the master device. Optionally, the slave device may accumulate the number of bytes received for each data packet until all firmware data segments have been received.

[0063] Then, the slave device re-executes the verification calculation on the received firmware data segment to generate a new verification result as the second verification value. Optionally, the second verification value is calculated using the same CRC algorithm as the first verification value to ensure the comparability of the verification results.

[0064] By obtaining the actual length and calculating the second check value, the slave device can obtain basic data to compare with the preset length and the first check value for integrity verification. At the same time, since the verification calculation is completed autonomously by the slave device, it does not need to rely on the master control device to provide the verification results, thus ensuring the independence and reliability of the verification process.

[0065] Step S22: Compare the preset length with the actual length, and the first check value with the second check value.

[0066] It should be noted that the two sets of data are compared separately, including the comparison between the preset length and the actual length, and the comparison between the first check value and the second check value.

[0067] The comparison between the preset length and the actual length is used to verify whether data loss has occurred during the transmission of firmware data segments. If the actual length is equal to the preset length, it means that the data is complete; otherwise, it means that there is packet loss or data omission.

[0068] The comparison between the first check value and the second check value is used to verify whether the data content of the firmware data segment has been erroneous or damaged during transmission. If the first check value is equal to the second check value, it means that the data content is correct; otherwise, it means that there is a bit error or data tampering.

[0069] When the preset length is equal to the actual length and the first check value is equal to the second check value, the first check is deemed to pass, indicating that the firmware data segment remains intact and correct during transmission.

[0070] By simultaneously comparing length and checksums, the slave device can verify the integrity of firmware data segments from two dimensions: data volume and data content. This avoids the blind spots that may exist when relying on a single verification method. For example, verifying only the length may not detect data content errors, and verifying only the content may not detect incomplete data volume. Dual comparison can effectively identify various abnormal situations during transmission, thereby maximizing the accuracy of firmware data segments used for upgrades and preventing incomplete or erroneous programs caused by transmission anomalies from being written to the slave device, thus preventing the slave device from becoming bricked due to upgrade failure.

[0071] In one possible implementation, after step S22, the following is included: Step S23: If the preset length is consistent with the actual length and the first verification value is consistent with the second verification value, then the first verification is determined to be successful. It should be noted that the preset length being consistent with the actual length means that when the slave device compares the data, it finds that the original data volume of the firmware data segment stored in the additional data segment is equal to the data volume of the firmware data portion actually received, indicating that no data loss or omission occurred during transmission.

[0072] If the first check value and the second check value are consistent, it means that when the slave device compares the data, it finds that the original check result stored in the additional data segment is equal to the check result recalculated on the received firmware data segment, indicating that no bit errors or tampering have occurred in the data content during transmission.

[0073] Once the first verification is passed, the slave device determines that the firmware data segment is complete and correct during transmission based on the consistency of the above two comparison results.

[0074] When the preset length matches the actual length and both the first and second check values ​​are satisfied, the first check is considered successful, thus proceeding to the subsequent second check process. By setting a condition that two comparison results must be met simultaneously, the slave device can accurately identify various anomalies that may occur during transmission, ensuring that only complete and error-free firmware data segments can enter the subsequent upgrade process, and reliably perform subsequent model matching verification and program writing.

[0075] Step S24: If the preset length is inconsistent with the actual length, or the first verification value is inconsistent with the second verification value, then it is determined that the first verification has failed.

[0076] It should be noted that the inconsistency between the preset length and the actual length means that when the slave device compares the data, it finds that the original data volume of the firmware data segment stored in the additional data segment is not equal to the actual data volume of the received firmware data segment. This indicates that there is data loss or missing data packets during the transmission process.

[0077] The inconsistency between the first and second check values ​​means that when the slave device compares the data, it finds that the original check result stored in the additional data segment is not equal to the check result recalculated from the received firmware data segment. This indicates that there are bit errors, data corruption, or tampering during transmission.

[0078] If the first verification fails, the slave device determines that the firmware data segment is abnormal during transmission and cannot be used for upgrades because either of the above two comparison results is inconsistent.

[0079] If the preset length is inconsistent with the actual length, or if the first check value is inconsistent with the second check value, the first check is deemed to have failed. In this case, the slave device terminates the upgrade process, does not write any destructive data, does not clear or modify the original upgrade flag, and directly jumps back to the original program to continue running.

[0080] By immediately determining that the first verification has failed and stopping the upgrade when any verification fails, the slave device can effectively prevent incomplete or erroneous firmware data segments caused by transmission anomalies from being written to the storage area, thereby avoiding the slave device from becoming bricked due to writing incorrect programs and ensuring the stable operation of the slave device.

[0081] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, step S3, the step of performing a second verification on the firmware matching identifier included in the verification information if the first verification passes, includes: Step S31: Read the firmware matching identifier already stored in the preset storage area of ​​the slave device; It should be noted that the firmware matching identifier is an identifier used to uniquely identify the model or version of the slave device. Optionally, the firmware matching identifier can be a chip program identification number, which is pre-written into the program when compiling the firmware to distinguish firmware from different hardware platforms or different engineering projects.

[0082] The preset storage area is a fixed storage space allocated from the non-volatile memory of the end device. Optionally, the preset storage area can be a flag area in flash memory, used to store information related to the device identity.

[0083] The stored firmware matching identifier refers to the identifier that is originally stored in the preset storage area and represents the current slave device hardware identity or the current running program identity. Optionally, the identifier is written into the preset storage area when the device leaves the factory or when the program is run for the first time.

[0084] The slave device retrieves the value of the stored firmware matching identifier from a specified address in a preset storage area via a memory access command.

[0085] Since the firmware matching identifier stored in the preset storage area represents the actual version of the slave device, by reading the firmware matching identifier, the slave device can obtain a benchmark value for comparison with the firmware matching identifier in the converged upgrade package, and can reliably perform subsequent model matching verification.

[0086] Step S32: Compare the firmware matching identifier in the preset storage area with the firmware matching identifier included in the verification information to see if they are consistent.

[0087] It should be noted that the firmware matching identifier in the preset storage area is an identifier that is read and represents the current identity of the slave device.

[0088] The firmware matching identifier included in the verification information is an identifier representing the slave device model or version to which the upgrade package is applicable, which is parsed from the additional data segment of the integrated upgrade package. Optionally, the firmware matching identifier is extracted from the original firmware and written into the additional data segment by a script when the integrated upgrade package is generated.

[0089] Then, the firmware matching identifier in the preset storage area is compared with the firmware matching identifier included in the verification information to determine if they are equal. If the firmware matching identifier in the preset storage area matches the firmware matching identifier included in the verification information, it means that the fusion upgrade package matches the current slave device hardware, and the second verification passes; if they do not match, it means that the fusion upgrade package is prepared for other models or versions of slave devices and does not match the current device, and the second verification fails.

[0090] By comparing the firmware matching identifier in the preset storage area with the firmware matching identifier included in the verification information, the slave device can independently determine whether the received fusion upgrade package is suitable for its own hardware. This avoids firmware mismatch problems caused by the master device pushing the wrong upgrade package or the user mistakenly selecting the wrong upgrade package, thereby preventing the writing of mismatched firmware to the slave device and causing the device to malfunction, and further ensuring the security and reliability of the upgrade process.

[0091] In one feasible implementation, step S4, which involves performing an upgrade operation on the firmware data to be upgraded of the slave device according to the fusion upgrade package if the second verification passes, includes: Step S41: Erase the firmware data to be upgraded stored in the preset storage area of ​​the slave device; It should be noted that the preset storage area is a fixed storage space allocated from the non-volatile memory of the slave device, used to store the main program code required for the normal operation of the slave device. Optionally, the preset storage area can be the main storage space in flash memory.

[0092] The firmware data to be upgraded refers to the original program code currently stored in the preset storage area that is about to be replaced. This program code is the version of the program currently running on the slave device.

[0093] Erasing refers to the clearing operation performed on a specified area in non-volatile memory before writing. Optionally, the erasing operation is performed on the smallest erase unit of the flash memory, restoring all bits in the area to their initial state for writing new data.

[0094] Since the non-volatile memory of the slave device needs to erase the target area to its initial state before writing new data, otherwise the new data cannot be written correctly, erasing the firmware data to be upgraded stored in the preset storage area can provide available storage space for writing new firmware data later, ensuring that the new firmware data can be written correctly without conflicting with the original data.

[0095] Step S42: Write the firmware data segment in the fusion upgrade package as new firmware data into the preset storage area.

[0096] It should be noted that the firmware data segment in the merged upgrade package is the original program code extracted from the merged upgrade package. This part does not include the verification information in the additional data segment, and only contains the executable program instructions and data required for the slave device to run.

[0097] New firmware data refers to the upgraded version used to replace the original program code; that is, the updated program content represented by the firmware data segment.

[0098] Then, the new firmware data is programmed byte by byte into a designated address in the non-volatile memory. Optionally, the write operation copies the new firmware data from the temporary storage area to the corresponding location in the preset storage area. Writing the firmware data segment from the fusion upgrade package as new firmware data into the preset storage area means replacing the original program code with a complete and matching new program code that has undergone dual verification by the first and second checks, thus completing the software upgrade of the slave device.

[0099] In this embodiment, since the first and second verifications have been completed before erasing and writing, the integrity of the firmware data segment and its compatibility with the slave device are ensured. Therefore, the new firmware data written to the preset storage area is safe and reliable. This can prevent the slave device from failing to start normally due to incomplete or incorrectly matched programs, thereby effectively preventing the upgrade from failing and bricking the device, and ensuring the success rate of the upgrade process and the stability of device operation.

[0100] Based on the above embodiments of this application, in another embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. In addition, the slave device is used to control backlight LEDs, and the method further includes: Step D1: Before triggering the upgrade, report the current backlight control status parameters to the main control device; It should be noted that the slave device is used to control the backlight LED beads. Optionally, the slave device can be a backlight microcontroller unit, which is responsible for driving and managing the brightness, local dimming and constant current control of the Mini-LED backlight LED beads.

[0101] Triggered upgrade refers to the moment when the end device receives the converged upgrade package and completes the reception preparation, and is about to enter the upgrade process.

[0102] The slave device sends the backlight control status parameters to the master device through the communication interface. Optionally, the communication interface can be a serial peripheral interface, an internal integrated circuit bus, or a universal asynchronous transceiver.

[0103] The backlight control status parameters are various configuration information of the current backlight working status. Optionally, the backlight control status parameters may include the current backlight brightness value, zone dimming mode, brightness data of each zone, constant current drive current setting value, backlight switch status, etc. The backlight control status parameters determine the current display effect of the backlight LEDs.

[0104] By reporting the current backlight control status parameters to the master control device, the slave device can inform the master control device of its own operating status before the upgrade, so that the master control device can take over the backlight control in the future. This ensures that the backlight control can be smoothly transitioned during the upgrade of the slave device and avoids the backlight suddenly turning off or displaying abnormalities due to the upgrade of the slave device.

[0105] Step D2: After the master control device takes over the backlight control according to the backlight control status parameters, it triggers the slave device to perform an upgrade operation. It should be noted that taking over backlight control means that after receiving the backlight control status parameters reported by the slave device, the master device takes the initiative to assume the responsibility of controlling the backlight LEDs based on these backlight control status parameters, temporarily replacing the slave device to drive and manage the backlight LEDs' brightness, local dimming, and constant current control functions.

[0106] The master control device takes over control based on the backlight control status parameters, meaning that the master control device can seamlessly continue to maintain the current backlight display effect according to the backlight settings before the slave device was upgraded, so that users cannot perceive the change in backlight during the slave device upgrade.

[0107] After the master control device confirms that it has successfully taken over the backlight control, the master control device sends an upgrade start command to the slave device. The slave device then begins to execute the upgrade process described in steps S1 to S4, including performing first verification, second verification, and firmware data writing on the fusion upgrade package.

[0108] By taking over backlight control from the master device before triggering the upgrade operation, the slave device can hand over backlight control responsibilities to the master device during the upgrade process. This avoids backlight control interruption caused by the slave device resetting itself or updating the program, thus ensuring that the backlight always maintains a normal display state during the upgrade process, maintaining the current backlight display effect, and achieving a seamless upgrade.

[0109] Step D3: After the upgrade is completed, receive the backlight control status parameters sent by the main control device, and restore backlight control through the backlight control status parameters.

[0110] It should be noted that upgrade completion refers to the moment when the slave device completes the writing of firmware data segments, the new program has been successfully stored in the preset storage area, and it can run normally.

[0111] The slave device obtains the backlight control status parameters sent by the master device through the communication interface. The backlight control status parameters sent by the master device refer to the actual operating parameters of the master device for continuous backlight management after taking over backlight control during the upgrade of the slave device. Optionally, these parameters may include the latest backlight brightness value and zone brightness data adjusted by the master device according to environmental changes or user operations during the upgrade. They may not be exactly the same as the parameters reported by the slave device before the upgrade, or they may be exactly the same as the parameters reported by the slave device before the upgrade.

[0112] Recovering backlight control through backlight control status parameters means that the slave device reconfigures its own backlight driver module according to the backlight control status parameters issued by the master device, and hands over the backlight control responsibility from the master device back to the slave device, so that the backlight control is restored to the slave device and continues to operate according to the latest or maintain the previous backlight control status parameters.

[0113] In this embodiment, by receiving the backlight control status parameters sent by the master control device after the upgrade is completed and restoring the backlight control, the slave device can achieve a seamless handover of backlight control, ensuring that the backlight display status before and after the upgrade is continuous and consistent. At the same time, since the parameters sent by the master control device reflect the latest backlight settings during the upgrade, backlight status regression or sudden changes caused by the upgrade process are avoided, further improving the smoothness of backlight control and the user's seamless experience.

[0114] In another embodiment, multiple slave devices are connected to a master control device, and the method includes: Receive data blocks sent by the main control device, wherein the data blocks are obtained by the main control device from the division of the fusion upgrade package; After confirming that the data block has been received completely, a fusion upgrade package is obtained by merging all data blocks, and the checksum of the fusion upgrade package is calculated. Perform consistency checks on the individual check values ​​of each slave device; After the consistency verification is passed, the system receives the synchronization upgrade instruction sent by the main control device and executes the upgrade operation synchronously.

[0115] It should be noted that multiple slave devices connected to the master control device refers to the existence of two or more slave devices connected to the same master control device through a communication bus. Optionally, in the Mini-LED backlight control scenario, due to the large number of partitions, multiple backlight microcontrollers are required to work together. These backlight microcontrollers are all connected to the front-end system-on-a-chip through communication interfaces such as serial peripheral interfaces or internal integrated circuit buses.

[0116] The data blocks sent by the master control device refer to the data blocks that the master control device divides into several small data blocks according to a certain data length after obtaining the complete fusion upgrade package, in order to adapt to the transmission limitations of the communication interface, and sends them to each slave device one by one.

[0117] The merged upgrade package includes a firmware data segment and an additional data segment. The additional data segment contains verification information for the firmware data segment. Optionally, the verification information includes the preset length of the firmware data segment, a first checksum, and a firmware matching identifier. By receiving data blocks sent by the master device, each slave device can acquire the data content required for the upgrade in parallel, providing a foundation for subsequent multi-device synchronous upgrades.

[0118] Additionally, it should be noted that during the receiving process, each slave device accumulates the length of the received data blocks and compares it with the total length of the fusion upgrade package pre-notified by the master control device. When the length of the received data is equal to the total length of the fusion upgrade package, it is determined that all data blocks have been successfully received.

[0119] Calculating the checksum based on the received data blocks means that after confirming that the data has been received completely, each slave device will assemble all the received data blocks into a complete fusion upgrade package in the order of receipt, extract the firmware data segment from it, and perform a checksum algorithm on the firmware data segment to generate a checksum result. Optionally, the checksum algorithm can be the CRC algorithm, and the generated checksum can be a 32-bit unsigned integer.

[0120] Each slave device independently calculates its own check value, enabling each slave device to obtain a reference value for verifying data consistency, which can then be used to perform consistency checks on multiple slave devices.

[0121] Additionally, it should be noted that, using the check value of one slave device as a baseline, the check values ​​of the other slave devices are compared one by one to see if they are the same as the baseline check value. It is also possible to compare check values ​​between two slave devices.

[0122] Optionally, the consistency check can be initiated by the master device, with each slave device reporting its calculated check value to the master device for comparison; alternatively, one slave device can act as a coordinator, collecting check values ​​from other slave devices for comparison. If all slave devices' check values ​​are consistent, it indicates that the firmware data segments received by each slave device are identical, and the consistency check passes. If any slave device's check value is inconsistent with other slave devices, it indicates that an error occurred during data transmission, and the consistency check fails.

[0123] By performing consistency checks on the check values ​​of each slave device, it can be ensured that the firmware data segments received by all slave devices are completely consistent, avoiding the problem of inconsistent program versions of each slave device after the upgrade due to transmission abnormalities of individual slave devices. This ensures the coordination and consistency of backlight control when multiple slave devices work together.

[0124] Additionally, it should be noted that the synchronous upgrade command is an upgrade start command broadcast simultaneously or sent separately to all slave devices by the master control device after confirming that the consistency verification of all slave devices has passed. Optionally, the command may include a unified trigger time point for upgrade execution or an identifier for immediate execution.

[0125] Then, after receiving the synchronous upgrade command, each slave device simultaneously starts the upgrade process at the same time or within a certain time window. This includes erasing the firmware data to be upgraded in its own preset storage area, writing the received firmware data segment as new firmware data into the preset storage area, and resetting and running the new program after the upgrade is completed.

[0126] In this embodiment, by receiving the synchronous upgrade command sent by the master device after the consistency verification is passed and executing the upgrade operation synchronously, all slave devices can complete the firmware update at the same time. This avoids the backlight control disorder caused by some slave devices completing the upgrade first and some slave devices still running the old program due to asynchronous upgrade timing. It ensures that multiple slave devices can work together with a unified program version and consistent startup time after the upgrade, thereby ensuring a smooth transition of backlight zone control and consistency of overall display effect.

[0127] For example, to help understand the implementation process of the online upgrade method obtained by combining this embodiment with the above embodiments, please refer to... Figure 3 , Figure 3 A flowchart illustrating an online upgrade method is provided, specifically demonstrating the process of a software upgrade performed by a slave device. First, the slave device executes the Bootloader program, jumps to the APP main area to run the current program, and writes the firmware matching identifier FLAG1 corresponding to the current program or current hardware to a specific FLAG area.

[0128] Then, it checks whether the main control device (such as the host computer) has sent a fusion upgrade package. If not, it continues running the current program in the APP main area. If yes, it receives the fusion upgrade package and writes it to the APP backup area. Then, it obtains the verification information at the end of the fusion upgrade package (including length information, i.e., the preset length, verification value, i.e., the first verification value, and firmware matching identifier FLAG2). Then, it checks whether the actual length is consistent with the preset length and whether the first verification value is consistent with the second verification value. If not, it exits the upgrade and continues running the current program in the APP main area. If yes, it writes the actual length and firmware matching identifier FLAG2 into the FLAG area and writes the upgrade flag. Then, it resets, re-executes the Bootloader program, and retrieves the stored FLAG1 from the FLAG area. It checks whether the firmware matching identifier FLAG1 is consistent with the firmware matching identifier FLAG2 in the fusion upgrade package. If not, it jumps to the APP main area and runs the current program in the APP main area. If so, the APP main area will be erased, the firmware data segment in the APP backup area fusion upgrade package will be written into the APP main area as the new firmware data, i.e., the new program, and the APP main area will be switched to run the new program.

[0129] For example, to help understand the implementation process of the online upgrade method obtained by combining this embodiment with the above embodiments, please refer to... Figure 4 , Figure 4A flowchart illustrating an online upgrade method is provided, specifically demonstrating the process of generating a merged upgrade package. First, the corresponding Python file operation module is imported to obtain the original upgrade package compiled by the program. Then, it is checked whether the original upgrade package exists; if not, the process ends. If it exists, the original upgrade package is parsed, its length is obtained, and a checksum is calculated; simultaneously, the firmware matching identifier FLAG1 is obtained. The length, checksum, and firmware matching identifier FLAG1 are then stored as verification information at the end of the original upgrade package. Finally, the merged upgrade package is generated based on this.

[0130] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the online upgrade method of this application. Any simple modifications based on this technical concept, such as the interaction and combination of various embodiments, are all within the protection scope of this application.

[0131] This application also provides an online upgrade device, please refer to... Figure 5 The online upgrade device, applied to slave devices, includes: The receiving module 10 is used to receive the fusion upgrade package forwarded by the master control device, wherein the fusion upgrade package includes a firmware data segment and an additional data segment, and the additional data segment contains the verification information of the firmware data segment; The first verification module 20 is used to parse the verification information from the fusion upgrade package, and perform a first verification on the firmware data segment in the fusion upgrade package according to the preset length of the firmware data segment included in the verification information and the first verification value. The second verification module 30 is used to perform a second verification on the firmware matching identifier included in the verification information if the first verification passes. The upgrade module 40 is used to perform an upgrade operation on the firmware data to be upgraded of the slave device according to the fusion upgrade package if the second verification passes.

[0132] The online upgrade device provided in this application, employing the online upgrade method described in the above embodiments, can solve the technical problem of data packet loss or error during online upgrades, leading to upgrade failure. Compared with the prior art, the beneficial effects of the online upgrade device provided in this application are the same as those of the online upgrade method provided in the above embodiments, and other technical features in the online upgrade device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0133] This application provides a slave device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the online upgrade method in the first embodiment described above.

[0134] The following is for reference. Figure 6 The diagram illustrates a suitable structural schematic for implementing a slave device in the embodiments of this application. The slave device in the embodiments of this application may include, but is not limited to, a microcontroller, an embedded processor, or electronic devices. Figure 6 The slave device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0135] like Figure 6 As shown, the slave device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the slave device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the slave device to communicate wirelessly or wiredly with other devices to exchange data. While various systems are shown in the figure, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0136] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0137] The slave device provided in this application, employing the online upgrade method described in the above embodiments, can solve the technical problem of data packet loss or error during online upgrades, leading to upgrade failure. Compared with the prior art, the beneficial effects of the slave device provided in this application are the same as those of the online upgrade method provided in the above embodiments, and other technical features of the slave device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

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

[0140] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the online upgrade method in the above embodiments.

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

[0142] The aforementioned computer-readable storage medium may be included in the slave device or may exist independently and not assembled into the slave device.

[0143] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0144] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

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

[0146] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described online upgrade method. This solves the technical problem of data packet loss or corruption during online upgrades, leading to upgrade failure. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the online upgrade method provided in the above embodiments, and will not be repeated here.

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

[0148] The computer program product provided in this application can solve the technical problem of data packet loss or error during online upgrades, leading to upgrade failure. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the online upgrade method provided in the above embodiments, and will not be repeated here.

[0149] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. An online upgrading method, characterized by, Applied to slave devices, the online upgrade method includes: The system receives a fusion upgrade package forwarded by the main control device, wherein the fusion upgrade package includes a firmware data segment and an additional data segment, and the additional data segment contains verification information of the firmware data segment; The verification information is parsed from the fusion upgrade package, and the firmware data segment in the fusion upgrade package is subjected to a first verification based on the preset length of the firmware data segment included in the verification information and the first verification value. If the first verification passes, a second verification is performed on the firmware matching identifier included in the verification information; If the second verification passes, the firmware data to be upgraded on the slave device is upgraded according to the fusion upgrade package.

2. The method of claim 1, wherein, The step of performing a first verification on the firmware data segment in the fusion upgrade package based on the preset length of the firmware data segment included in the verification information and the first verification value includes: Obtain the actual length of the received firmware data segment, and determine the second check value based on the actual length; Compare the preset length with the actual length, and the first check value with the second check value.

3. The method as described in claim 2, characterized in that, After the step of comparing the preset length with the actual length, and the first check value with the second check value, the following is included: If the preset length is consistent with the actual length, and the first verification value is consistent with the second verification value, then the first verification is determined to be successful. If the preset length is inconsistent with the actual length, or the first verification value is inconsistent with the second verification value, then the first verification is determined to have failed.

4. The method as described in claim 1, characterized in that, The step of performing a second verification on the firmware matching identifier included in the verification information if the first verification passes includes: Read the firmware matching identifier already stored in the preset storage area of ​​the slave device; Compare the firmware matching identifier in the preset storage area with the firmware matching identifier included in the verification information to see if they are consistent.

5. The method of claim 4, wherein, The step of performing an upgrade operation on the firmware data to be upgraded of the slave device according to the fusion upgrade package when the second verification passes includes: Erase the firmware data to be upgraded stored in the preset storage area of ​​the slave device; The firmware data segment in the fusion upgrade package is written as new firmware data into the preset storage area.

6. The method of claim 1, wherein, The slave device is used to control the backlight LED chips, and the method further includes: Before triggering the upgrade, the current backlight control status parameters are reported to the main control device; After the master control device takes over the backlight control according to the backlight control status parameters, it triggers the slave device to perform an upgrade operation. After the upgrade is completed, the backlight control status parameters sent by the main control device are received, and the backlight control rights are restored through the backlight control status parameters.

7. The method as described in claim 1, characterized in that, Following the step of receiving the converged upgrade package forwarded by the master control device, the following is also included: Store the fusion upgrade package in a preset storage area; The length of the received data is recorded during the reception of the fusion upgrade package; When the reception of the fusion upgrade package is confirmed to be complete based on the data length, the first verification is triggered, wherein the recorded data length is used as the actual length of the firmware data segment.

8. An online upgrade device, characterized in that, Applied to slave devices, the online upgrade device includes: A receiving module is used to receive a fusion upgrade package forwarded by the master control device, wherein the fusion upgrade package includes a firmware data segment and an additional data segment, and the additional data segment contains the verification information of the firmware data segment; The first verification module is used to parse the verification information from the fusion upgrade package, and perform a first verification on the firmware data segment in the fusion upgrade package according to the preset length of the firmware data segment included in the verification information and the first verification value. The second verification module is used to perform a second verification on the firmware matching identifier included in the verification information if the first verification passes. The upgrade module is used to perform an upgrade operation on the firmware data to be upgraded of the slave device according to the fusion upgrade package if the second verification passes.

9. A terminal device, comprising: The slave device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the online upgrade method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the online upgrade method as described in any one of claims 1 to 7.

Images