Firmware updating method and system and terminal equipment

Abstract

The invention relates to the technical field of firmware updating, and discloses a firmware updating method and system and terminal equipment. The method comprises the steps of obtaining target firmware data; obtaining firmware capacity and first firmware version information according to the target firmware data; obtaining second firmware version information of the microcontroller; judging whether the first firmware version information is matched with the second firmware version information or not according to the second firmware version information and the first firmware version information; when the first firmware version information is not matched with the second firmware version information, it is determined that a firmware updating process of the microcontroller is executed, and the firmware updating process comprises the steps that whether the firmware capacity is larger than a preset capacity threshold value or not is judged; when the firmware capacity is greater than a preset capacity threshold value, processing the target firmware data in batches, and executing a first upgrading process; and when the firmware capacity is not greater than a preset capacity threshold value, storing the target firmware data to a specified area of the embedded controller and then executing a second upgrading process. On the basis, an efficient, flexible and convenient firmware updating process is realized.

Description

Technical Field

[0001] The present application relates to the field of firmware upgrade technology, and in particular to a firmware update method, system and terminal device. Background Art

[0002] In the existing computer production and delivery process, many terminal devices (for example, desktops or laptops) are connected to external MCUs (microcontroller units) to implement specific functions, such as USB keyboard signal reporting, PC one-key startup, etc. These functions rely on the firmware support of the external MCU, but the current firmware update method mainly relies on the fixture, and the MCU firmware is updated by directly connecting the hardware burning pins. Specifically, the burning pins of the MCU are led out through the line, and the firmware can only be updated after the fixture is connected. However, this method has major problems in the production process. First, this fixture-dependent method makes the firmware update process complicated and difficult to expand, which greatly limits the efficiency of computer mass production. Secondly, in the later stage of production, if the MCU firmware is mismatched or needs to be updated, due to the high dependence on the fixture, it is impossible to achieve a simple and fast remote firmware update. More seriously, this method cannot meet the efficiency requirements in mass production, nor can it meet the convenient needs of firmware updates after shipment. Summary of the invention

[0003] The embodiments of the present application mainly solve the technical problem that the prior art cannot conveniently and flexibly update the firmware of a microcontroller.

[0004] To solve the above technical problems, a technical solution adopted in the implementation mode of the present application is: providing a firmware update method, the method comprising: obtaining target firmware data; obtaining firmware capacity and first firmware version information according to the target firmware data; obtaining second firmware version information of a microcontroller; judging whether the first firmware version information matches the second firmware version information according to the second firmware version information and the first firmware version information; when the first firmware version information does not match the second firmware version information, determining to execute the firmware update process of the microcontroller, the firmware update process comprising: judging whether the firmware capacity is greater than the preset capacity threshold according to the firmware capacity and the preset capacity threshold; when the firmware capacity is greater than the preset capacity threshold, processing the target firmware data in batches and executing the first upgrade process; when the firmware capacity is not greater than the preset capacity threshold, storing the target firmware data in a designated area of ​​the embedded controller and then executing the second upgrade process.

[0005] In some embodiments, the obtaining the second firmware version information of the microcontroller includes: sending a version information obtaining instruction to the embedded controller, so that the embedded controller obtains the second firmware version information from the microcontroller according to the version information obtaining instruction.

[0006] In some embodiments, before determining to execute the firmware update process of the microcontroller when the first firmware version information does not match the second firmware version information, the method also includes: sending a firmware preparation instruction to the embedded controller, so that the embedded controller sends an initialization instruction to the microcontroller according to the firmware preparation instruction, so that the microcontroller executes the initialization process according to the initialization instruction, and returns a feedback result to the embedded controller.

[0007] In some embodiments, the microcontroller executes an initialization process according to the initialization instruction and returns a feedback result to the embedded controller, including: receiving the feedback result forwarded by the embedded controller, and obtaining a response time according to the feedback result; judging whether the response time meets the preset time range according to the response time and the preset time range; if the response time meets the preset time range, determining to execute the firmware update process; if the response time does not meet the preset time range, determining not to execute the firmware update process.

[0008] In some embodiments, when the firmware capacity is greater than the preset capacity threshold, the target firmware data is processed in batches and a first upgrade process is executed, including: according to a preset segmentation rule, the target firmware data is segmented to obtain a preset number of firmware sub-data; and the first upgrade process is executed on the firmware sub-data.

[0009] In some embodiments, executing the first upgrade process on the firmware sub-data includes: sending the firmware sub-data and the firmware verification code to the embedded controller so that the embedded controller calculates the firmware sub-data to obtain the current firmware verification code; judging whether the current firmware verification code matches the firmware verification code based on the firmware verification code and the current firmware verification code; if the current firmware verification code matches the firmware verification code, determining to execute the status detection process; if the current firmware verification code does not match the firmware verification code, ending the first upgrade process.

[0010] In some embodiments, if the current firmware verification code matches the firmware verification code, determining to execute a status detection process includes: obtaining current system status information of the microcontroller; detecting the current system status information to obtain a status detection result; if the status detection result satisfies that the current system status information is in an idle state, sending the firmware sub-data to a designated area of ​​the microcontroller so that the microcontroller performs a firmware upgrade according to the firmware sub-data; if the status detection result satisfies that the current system status information is in a non-idle state, ending the first upgrade process.

[0011] In some embodiments, when the firmware capacity is not greater than the preset capacity threshold, the target firmware data is stored in a designated area of ​​the embedded controller and then a second upgrade process is executed, including: sending the target firmware data to the designated area of ​​the embedded controller so that the embedded controller pushes the target firmware data to the microcontroller so that the microcontroller performs a firmware upgrade according to the target firmware data.

[0012] To solve the above technical problems, another technical solution adopted in the embodiment of the present application is: to provide a firmware update system, the firmware update system includes: a firmware management tool, an embedded controller and a microcontroller, the embedded controller is respectively connected to the firmware management tool and the microcontroller in communication; the firmware management tool is used to: obtain target firmware data; obtain firmware capacity and first firmware version information according to the target firmware data; obtain second firmware version information of the microcontroller; determine whether the first firmware version information matches the second firmware version information according to the second firmware version information and the first firmware version information; when the first firmware version information does not match the second firmware version information, determine to execute the firmware update process of the microcontroller, the firmware update process includes: according to the firmware capacity and a preset capacity threshold, determine whether the firmware capacity is greater than the preset capacity threshold; when the firmware capacity is greater than the preset capacity threshold, process the target firmware data in batches and execute the first upgrade process; when the firmware capacity is not greater than the preset capacity threshold, store the target firmware data in a designated area of ​​the embedded controller and then execute the second upgrade process.

[0013] In order to solve the above technical problems, another technical solution adopted in the implementation manner of the present application is: providing a terminal device, wherein the terminal device includes the above-mentioned firmware update system.

[0014] Different from the related art, the present application provides a firmware update method, system and terminal device. By acquiring target firmware data; obtaining firmware capacity and first firmware version information according to the target firmware data; acquiring second firmware version information of a microcontroller; judging whether the first firmware version information matches the second firmware version information according to the second firmware version information and the first firmware version information; when the first firmware version information does not match the second firmware version information, determining to execute the firmware update process of the microcontroller, the firmware update process includes: judging whether the firmware capacity is greater than the preset capacity threshold according to the firmware capacity and the preset capacity threshold; when the firmware capacity is greater than the preset capacity threshold, processing the target firmware data in batches and executing the first upgrade process; when the firmware capacity is not greater than the preset capacity threshold, storing the target firmware data in a designated area of ​​an embedded controller and executing the second upgrade process. Based on this, the present application can flexibly judge whether a firmware update is required according to the firmware capacity and version information, and select the most appropriate upgrade process according to the size of the firmware. For large-capacity firmware, batch processing is adopted to avoid the risk of failure caused by transmitting too much data and ensure the smooth progress of the upgrade process. For small-capacity firmware, it is directly stored in the designated area of ​​the embedded controller for push, which simplifies the operation process of firmware upgrade. This intelligent and flexible firmware update method can significantly improve production efficiency and post-shipment maintenance convenience, while reducing the risks caused by firmware update failures and ensuring system reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] One or more embodiments are exemplarily described by corresponding drawings, which do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and the figures in the drawings do not constitute proportional limitations unless otherwise stated.

[0016] Figure 1 It is a schematic block diagram of the structure of a firmware update system provided by an embodiment of the present application;

[0017] Figure 2 It is a flowchart of a firmware update method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0019] It should be noted that, if there is no conflict, the various features in the embodiments of the present application can be combined with each other, all within the scope of protection of the present application. Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as those generally understood by those skilled in the art of the present application. The terms used in the specification of the present application are only for the purpose of describing specific embodiments and are not used to limit the present application. The term "and / or" used in this specification includes any and all combinations of one or more related listed items.

[0020] See also Figure 1 , Figure 1 1 is a schematic block diagram of a firmware update system provided by an embodiment of the present application. Figure 1 As shown, the firmware update system 100 includes: a firmware management tool 10, an embedded controller 20 and a microcontroller 30, and the embedded controller 20 is communicatively connected with the firmware management tool 10 and the microcontroller 30 respectively.

[0021] The firmware management tool 10 is the initiator in the firmware upgrade system 100. Its main function is to start the entire firmware upgrade process and control the distribution and upgrade process of the firmware. In this embodiment, the firmware management tool 10 is the Tool end, which is a PC-side application or a software tool on an embedded system that can receive and manage firmware files and decompose them into suitable formats or data packets, ready for use in upgrades. The Tool end communicates with the embedded controller 20 through the IO port of the LPC or eSPI bus, and is responsible for directing each link in the firmware upgrade process, such as firmware transmission, verification, and segmentation. Its functions include: firmware file management, upgrade progress tracking, and error handling. The Tool end is the core control component in the system, which is responsible for comprehensive management of the firmware and ensuring the correct update of the MCU-side firmware.

[0022] The embedded controller 20 is the transfer end in the firmware upgrade system 100. It is located between the firmware management tool 10 (Tool end) and the microcontroller 30 (MCU end), and is responsible for coordinating the firmware transmission and upgrade process between the two. In this embodiment, the embedded controller 20 is an EC controller (EC end), which communicates with the Tool end through the LPC or eSPI bus, and communicates with the MCU end through I2C or SMBus. The EC end can receive firmware data from the Tool end and forward it to the MCU end. It is also responsible for firmware verification to ensure that the firmware data received by the MCU end is complete and valid. The working principle of the EC end is to act as a bridge and data transfer station, passing the data sent by the Tool end to the MCU end, and ensuring smooth and error-free data transmission.

[0023] The microcontroller 30 is the execution end in the firmware upgrade system 100, responsible for the actual firmware update operation. In the present embodiment, the microcontroller 30 is an MCU, and the MCU end is a microcontroller that implements specific functions in an embedded device or computer, and it is the final target end in the firmware upgrade process. During the firmware upgrade, the MCU end receives firmware data through the I2C or SMBus interface communication with the EC end. The main task of the MCU end is to execute the firmware upgrade operation, that is, to write the received firmware data into its internal memory (such as Flash or EEPROM). The MCU end ensures the effective update of the firmware by verifying the correctness of the firmware, and after the update is completed, it will start the execution of the new firmware.

[0024] Among them, the firmware management tool 10 is used to: obtain target firmware data; obtain firmware capacity and first firmware version information based on the target firmware data; obtain second firmware version information of the microcontroller; determine whether the first firmware version information matches the second firmware version information based on the second firmware version information and the first firmware version information; when the first firmware version information does not match the second firmware version information, determine to execute the firmware update process of the microcontroller, the firmware update process includes: based on the firmware capacity and the preset capacity threshold, determine whether the firmware capacity is greater than the preset capacity threshold; when the firmware capacity is greater than the preset capacity threshold, process the target firmware data in batches and execute the first upgrade process; when the firmware capacity is not greater than the preset capacity threshold, store the target firmware data in the designated area of ​​the embedded controller and then execute the second upgrade process.

[0025] Specifically, before executing the firmware update process, it is necessary to obtain the firmware capacity and the first firmware version information of the target firmware data. It is understandable that for the process of obtaining the target firmware data, first, the firmware management tool (TOOL end) needs to load the firmware file to be updated from the storage medium. The firmware file can be a firmware package downloaded from the network, a firmware file provided by the device manufacturer, or a firmware image on other storage media. The firmware management tool will extract the data therein by parsing the format of the firmware file, such as ZIP, BIN, HEX, or a specific firmware container format. Secondly, the firmware file generally consists of multiple components, including the firmware body, version information, configuration files, signature data, checksums, etc. The firmware file is decomposed and the firmware body content is extracted, which is usually the actual program code and necessary data blocks used to burn to the target MCU. Again, in the process of obtaining the target firmware data, the firmware management tool also needs to perform a preliminary check on the firmware file to ensure the integrity of the file. This is usually verified by calculating the checksum or hash value (such as MD5, SHA256) of the file to verify whether the file is damaged during transmission or storage. Finally, the firmware management tool may also need to pre-process the firmware data and convert it into a format suitable for the target hardware (such as MCU or EC) for the subsequent push process.

[0026] After obtaining the target firmware data, it is necessary to extract the version number and firmware capacity information of the target firmware. It is understandable that, first, the firmware management tool needs to read the capacity (size) of the firmware from the target firmware data. The firmware capacity is usually stored in the metadata of the firmware file, or directly reflected in the size of the firmware data. By parsing the firmware file header information, the tool can obtain the total number of bytes of the firmware and then determine the storage requirements of the firmware. This information is crucial for subsequent firmware transmission and storage management, and can help the tool end evaluate whether the storage space of the device is sufficient and the data transmission load during the firmware upgrade process. Secondly, the firmware version information (first firmware version information) is key data in the firmware upgrade process, which helps the system check whether a firmware update is required. The firmware version information is usually stored in a specific location of the firmware file, such as the file header, configuration file, or embedded in a part of the firmware. The firmware management tool extracts this information by parsing the version field in the firmware. The version information usually includes the major version number, the minor version number, and the revision number (for example: v1.0.2). The firmware management tool also needs to ensure that it can handle different version formats. In addition, the firmware management tool may also identify the firmware version for subsequent recording and management. For example, the firmware version number can be used as the basis for the update log to ensure that after the firmware is upgraded, the version information is consistent with the record in the log. Some firmware systems may also include a firmware checksum or signature to further verify the consistency of the version.

[0027] In some embodiments, obtaining the second firmware version information of the microcontroller includes: sending a version information obtaining instruction to the embedded controller, so that the embedded controller obtains the second firmware version information from the microcontroller according to the version information obtaining instruction.

[0028] It can be understood that, first, the TOOL side (firmware management tool) starts the process of obtaining the firmware version information by sending a version information acquisition instruction to the EC side (embedded controller). This instruction is transmitted through communication protocols such as LPC, eSPI, and I2C. The specific transmission method depends on the hardware design of the system. The function of the instruction is to notify the EC side to prepare to communicate with the MCU side (microcontroller) to obtain the firmware version information currently running on the MCU side. Secondly, after receiving the instruction from the TOOL side, the EC side will generate a data frame, which includes the information to be sent to the MCU. The format of the data frame includes: packet sequence number (SEQ), command number (TAG), data length (LEN), sent data (DATA), and data frame check code (LRC). In this step, the EC side will generate a suitable data frame according to the protocol format, including a request to "obtain the MCU firmware version", and send it to the MCU. Thirdly, when the MCU receives the data frame from the EC, it will parse the command number (TAG) in the data frame and recognize that the request is a command to "obtain the firmware version". The MCU processes the request according to the command number and extracts the firmware version information currently running. Specifically, the MCU reads the firmware version number stored in its internal storage (such as Flash memory). The MCU parses the TAG field according to the data frame structure to determine how to respond to the DATA part in the data frame. Then, after parsing the data frame and obtaining the firmware version information, the MCU constructs a response data frame containing relevant information about the current firmware version number. The response data frame includes SEQ (packet sequence number), TAG (command number), LEN (data length), DATA (firmware version information), and LRC (check code). This response data frame is then sent back to the EC end. Finally, after the EC end receives the firmware version response data frame returned by the MCU, it parses the firmware version information in the data frame. The EC end extracts the version number according to the structure of the data frame and feeds back the version information to the TOOL end through an appropriate protocol. After receiving the firmware version information (second firmware version information), the TOOL end will perform further version comparison and inspection to determine whether the firmware needs to be updated.

[0029] This embodiment ensures accurate acquisition of firmware version information through efficient communication and data transmission between the TOOL end, EC end and MCU end. Through the structured transmission and verification mechanism of data frames, the system can reliably obtain the firmware version information currently running on the MCU, thereby providing an accurate basis for subsequent version checks and firmware upgrade decisions. This process effectively avoids version conflicts and errors in firmware updates, improves the accuracy and reliability of firmware upgrades, and provides a convenient solution for system maintenance and updates.

[0030] In some embodiments, based on the second firmware version information and the first firmware version information, it is determined whether the first firmware version information matches the second firmware version information; when the first firmware version information matches the second firmware version information, it is determined not to execute the firmware update process of the microcontroller; when the first firmware version information does not match the second firmware version information, it is determined to execute the firmware update process of the microcontroller.

[0031] It can be understood that the first firmware version information is the version information of the firmware to be updated obtained through the firmware management tool (TOOL end) in the above description, and the version information generally includes the major version number, minor version number, and revision number of the firmware. For example, the first firmware version information may be 1.0.3. The second firmware version information is the version information of the current firmware obtained from the MCU through the communication between the EC end and the MCU end in the above description, and is generally composed of the major version number, minor version number, and revision number. For example, the firmware version currently running on the MCU may be 1.0.2.

[0032] When comparing the two versions, they are generally compared one by one in the order of major version number, minor version number, and revision number. The criteria for determining whether the versions match can be as follows: If the first firmware version information is exactly the same as the second firmware version information (i.e., the major version number, minor version number, and revision number are all the same), the two are considered to match. If the version number of the first firmware version information is greater than the second firmware version information, the two are considered to not match. If the version number of the first firmware version information is less than or equal to the second firmware version information (i.e., the current MCU firmware version has been updated to or higher than the version to be updated), the two are considered to match.

[0033] When the first firmware version information does not match the second firmware version information (for example, the version of the firmware to be updated is newer and the current firmware version of the MCU is older), it means that the MCU needs to perform a firmware upgrade. Therefore, the system will execute the firmware update process. It is understandable that if a firmware version mismatch is detected, the firmware management tool (TOOL side) will start the firmware upgrade process, including firmware data transmission, writing to the MCU memory, verification and other steps to ensure the firmware update.

[0034] If the first firmware version information matches the second firmware version information (for example, the firmware version to be updated is the same as or lower than the current MCU firmware version), it means that the MCU firmware is already the latest version and the firmware update process will not be performed. It is understandable that if a firmware version match is detected, the tool will skip the firmware update process and will not perform any firmware write operations, thereby saving resources and avoiding unnecessary operations.

[0035] This embodiment can effectively determine whether a firmware update needs to be performed by comparing the version information of the firmware to be updated (first firmware version information) with the version information of the firmware currently running on the MCU (second firmware version information). This comparison operation ensures that the system is updated only when the firmware versions do not match, avoiding redundant firmware update operations and improving the efficiency of firmware upgrades.

[0036] In some embodiments, when the first firmware version information does not match the second firmware version information, before determining to execute the firmware update process of the microcontroller, it also includes: sending a firmware preparation instruction to the embedded controller, so that the embedded controller sends an initialization instruction to the microcontroller according to the firmware preparation instruction, so that the microcontroller executes the initialization process according to the initialization instruction, and returns feedback results to the embedded controller.

[0037] It can be understood that, first, after confirming that the firmware version does not match, the firmware management tool (TOOL end) will send a firmware preparation instruction to the microcontroller (MCU) through the EC end. The purpose of this instruction is to notify the EC end to start the firmware update collaboration process with the MCU and require the EC end to prepare to start the initialization communication with the MCU. Secondly, after receiving the firmware preparation instruction, the EC end further sends an initialization instruction to the MCU. The purpose of this instruction is to notify the MCU to prepare to enter the state of firmware update and start the internal initialization process. The initialization process includes shutting down the current firmware operation, releasing resources and preparing to receive new firmware data. This step is crucial because it ensures that the MCU will not be affected by the old firmware when accepting the new firmware, and the system can smoothly transition to the update state. Thirdly, after receiving the initialization instruction, the MCU starts to perform a series of internal initialization operations. These operations may include clearing the cache, setting the firmware update mode, locking hardware resources, etc. Through this process, the MCU is ready to receive the new firmware. After the initialization process is completed, the MCU will generate a feedback signal indicating that it has successfully entered the firmware update preparation state. In addition, once the MCU completes the initialization and is ready to receive the new firmware, it will feedback the "initialization completed" signal to the EC end through a data frame. The EC side parses the data frame and confirms that the MCU is ready for the firmware update. During this process, the data frame may contain the serial number, command number, data length, status information, etc. to ensure the integrity and accuracy of data transmission. Finally, the EC side forwards the initialization feedback information returned by the MCU to the firmware management tool (TOOL side) to complete the entire process of firmware update preparation. The TOOL side determines whether the firmware update process can be safely started based on the feedback results.

[0038] This embodiment can ensure that the MCU is in a clean and stable state by performing the initialization step before the firmware update process begins, thereby avoiding abnormalities or data corruption that may occur during the firmware update process. This step provides the necessary preparations to make the firmware update process more efficient and reliable. It avoids conflicts by ensuring that the MCU is not running old firmware before the update, and ensures the smooth loading and execution of the new firmware, thereby greatly improving the security and stability of the firmware update.

[0039] In some embodiments, the microcontroller executes an initialization process according to the initialization instruction and returns a feedback result to the embedded controller, including: receiving the feedback result forwarded by the embedded controller, and obtaining the response time according to the feedback result; judging whether the response time meets the preset time range according to the response time and the preset time range; if the response time meets the preset time range, determining to execute the firmware update process; if the response time does not meet the preset time range, determining not to execute the firmware update process.

[0040] It is understandable that the feedback result generated by the MCU after the initialization is completed is usually transmitted through a data frame, which contains the status and response time information of the MCU. The MCU sends the feedback result to the EC, and the EC forwards it to the firmware management tool (TOOL end). First, after receiving the feedback result from the EC, the firmware management tool first extracts the response time information therein. The response time refers to the time from the firmware management tool sending the initialization instruction to the MCU returning the initialization completion signal. This time needs to be accurately measured, and the EC usually records the start and end time after receiving the MCU feedback. Secondly, the firmware management tool compares the response time returned by the MCU according to a preset time range (for example, 2 seconds). The response time must be within the preset time range, and the judgment process is as follows: If the response time is less than or equal to 2 seconds, it means that the MCU initialization is successfully completed and the firmware update is ready within a reasonable time. The firmware management tool will think that the MCU is ready and can continue the firmware update process. If the response time is greater than 2 seconds, it means that the MCU initialization takes too long, and there may be problems such as system failure, insufficient hardware resources, or communication abnormalities. The firmware management tool will think that the MCU is not ready for firmware update, and therefore decides to stop the firmware update process.

[0041] This embodiment ensures the reliability and stability of the firmware update process by judging the response time. If the MCU responds abnormally (such as the response time is too long), the problem can be discovered in time and the firmware update can be avoided in an unreliable state, thereby preventing potential failures or data corruption during the firmware update process. Through this mechanism, the efficiency of the firmware update can be guaranteed, while the fault tolerance of the system is improved, ensuring that the firmware update is performed under stable and safe conditions.

[0042] After the communication interaction between the above-mentioned multiple terminals is completed, it is confirmed to start the firmware update process. The firmware update process includes: judging whether the firmware capacity is greater than the preset capacity threshold according to the firmware capacity and the preset capacity threshold; when the firmware capacity is greater than the preset capacity threshold, processing the target firmware data in batches and executing the first upgrade process.

[0043] In some embodiments, when the firmware capacity is greater than a preset capacity threshold, the target firmware data is processed in batches and a first upgrade process is executed, including: segmenting the target firmware data according to a preset segmentation rule to obtain a preset number of firmware sub-data; and executing the first upgrade process on the firmware sub-data.

[0044] It is understandable that in the firmware update process, the capacity of the firmware needs to be checked first. The system will compare the actual capacity of the target firmware with the preset capacity threshold. This preset capacity threshold is defined during system design and is used to distinguish between small firmware and large firmware: if the firmware capacity is not greater than the preset capacity threshold, it means that the firmware capacity is small and can be processed according to a simple process (i.e., the second upgrade process). If the firmware capacity is greater than the preset capacity threshold, it means that the firmware capacity is large and needs to be processed in batches to perform the complex steps of the first upgrade process. Among them, in the case of a large firmware capacity, the system will use batch processing to update the firmware. The specific process is as follows: First, in order to efficiently process large firmware data, it is necessary to define segmentation rules. The segmentation rules can be designed based on the following factors: The total capacity of the firmware: According to the size of the firmware, determine the capacity of each batch of firmware data (for example, the size of the firmware data transmitted each time is between 128Byte and 256Byte). The processing capacity of the MCU: According to the processing capacity of the MCU, determine the maximum amount of firmware data that can be accepted at one time to avoid processing delays or failures caused by transmitting too much data. Secondly, the firmware data is split according to the preset segmentation rules through the firmware management tool (TOOL side). The firmware file will be divided into multiple smaller sub-packets, which are called "firmware sub-data". These sub-data will be transmitted to the MCU in a certain order. Finally, each sub-packet is pushed from the EC side to the MCU through a predetermined protocol (such as SMBUS, I2C, etc.). The transmission process may include the following steps: Sending a data packet: The EC side or the TOOL side transmits a firmware sub-packet to the MCU. Receiving and verifying: After receiving each sub-packet, the MCU performs a check to confirm the integrity of the data. If the check passes, the MCU will return a confirmation signal, indicating that the sub-packet has been successfully received. Continue to transmit the next sub-packet: If the current sub-packet is successfully transmitted, the system will continue to transmit the next sub-packet until all firmware sub-data are transmitted.

[0045] In this embodiment, by judging the firmware capacity and the mechanism of batch processing, the system can flexibly and efficiently manage firmware updates of different capacities. For smaller firmware, the system can use a simpler process to update the firmware, and for larger firmware, batch processing can avoid overload and data transmission failure, thereby improving the reliability and efficiency of the firmware update process. Batch updates can not only ensure that the MCU can handle large-capacity data, but also provide a fault-tolerant mechanism during data transmission, thereby reducing the risk of errors during the firmware update process and improving the stability of the system.

[0046] In some embodiments, a first upgrade process is executed on firmware sub-data, including: sending the firmware sub-data and the firmware verification code to an embedded controller so that the embedded controller calculates the firmware sub-data to obtain the current firmware verification code; judging whether the current firmware verification code matches the firmware verification code based on the firmware verification code and the current firmware verification code; if the current firmware verification code matches the firmware verification code, determining to execute the status detection process; if the current firmware verification code does not match the firmware verification code, ending the first upgrade process.

[0047] In some embodiments, if the current firmware verification code matches the firmware verification code, the execution status detection process is determined, including: obtaining the current system status information of the microcontroller; detecting the current system status information to obtain a status detection result; if the status detection result satisfies that the current system status information is in an idle state, the firmware sub-data is sent to a designated area of ​​the microcontroller so that the microcontroller performs a firmware upgrade according to the firmware sub-data; if the status detection result satisfies that the current system status information is in a non-idle state, the first upgrade process is terminated.

[0048] It is understandable that a status check is required before the firmware sub-data executes the first upgrade process. First, when the firmware management tool (TOOL end) transmits the firmware in batches, it will send each batch of firmware sub-data and the corresponding firmware verification code to the embedded controller (EC). The key to this step is to ensure the integrity of the firmware sub-data, so the verification code is used to verify the correctness of the firmware data. The firmware sub-data and the verification code are transmitted to the embedded controller (EC) together through a communication protocol (such as I2C, SMBUS, etc.). After the EC receives the firmware data frame, it first extracts the firmware sub-data and the firmware verification code.

[0049] Secondly, after the embedded controller receives the firmware sub-data, it will calculate the current checksum of the data. The calculation method can be to use a hash algorithm (such as CRC32, MD5, etc.), and the specific algorithm depends on the firmware checksum strategy. The embedded controller compares the calculated current firmware checksum with the received firmware checksum. If the checksums match, it means that the firmware sub-data is transmitted correctly and the data is complete, and the next process will continue. If the checksums do not match, it means that there is a transmission error or damage to the firmware sub-data, and the data integrity cannot be guaranteed. At this time, the current firmware upgrade process will be stopped and the firmware upgrade will end.

[0050] Again, if the firmware verification passes, the embedded controller will continue to execute the status detection process. First, the embedded controller needs to obtain the current system status information of the microcontroller (MCU). The status of the MCU can be queried through the status register or specific commands. Common statuses include "idle", "busy", "error", etc. After obtaining the system status of the MCU, the embedded controller will detect it to determine whether the system is in an idle state. This process includes: Idle state detection: Check whether the MCU is performing other tasks (such as data processing, communication, etc.). If the MCU is currently idle, it can receive and process new firmware data. Non-idle state detection: If the MCU is in a busy or error state, the firmware update will be stopped to avoid updating in an inappropriate state. It is understandable that if the MCU state is idle, the embedded controller will transfer the firmware sub-data to the specified area of ​​the MCU (for example, flash memory, memory, etc.). If the MCU state is non-idle, the firmware update will be aborted, and the embedded controller will notify the firmware management tool that the update cannot be performed at present, and return an error message.

[0051] In addition, the MCU receives the firmware data frame from the embedded controller, processes the data frame, and verifies the data format and integrity. According to the structure of the data frame, the MCU extracts the firmware sub-data and prepares to store it in the specified memory area. After receiving valid firmware data, the MCU switches its system state to "idle", indicating that it can receive and process firmware update data. If an error occurs or verification fails during the reception process, the MCU switches to the "error" state and feeds back to the EC, indicating that the update failed.

[0052] Finally, when all firmware sub-data are successfully received and stored, the MCU will start to perform the upgrade, including writing new firmware, verifying firmware integrity, restarting the device, etc. If there is an error during the transmission process, the firmware update process will be aborted and the MCU will keep the current firmware unchanged until the next update attempt.

[0053] This embodiment ensures the security and reliability of the firmware update process by verifying the integrity of the firmware sub-data, detecting the MCU system status, and ensuring that the firmware upgrade is performed at the appropriate time. Firmware verification can avoid firmware update failures caused by data corruption or transmission errors; through status detection, it can ensure that the MCU accepts firmware updates when it is idle, avoid unstable updates in busy states, and reduce the risk of failure or system crash during the firmware update process. In addition, this design also improves the system's fault tolerance and enhances the controllability and stability of the firmware update process.

[0054] In some embodiments, when the firmware capacity is not greater than a preset capacity threshold, the target firmware data is stored in a designated area of ​​the embedded controller and then a second upgrade process is executed, including: sending the target firmware data to a designated area of ​​the embedded controller so that the embedded controller pushes the target firmware data to the microcontroller so that the microcontroller performs a firmware upgrade based on the target firmware data.

[0055] It can be understood that first, the firmware management tool (TOOL side) sends the target firmware data to the designated area of ​​the embedded controller (EC). The key to this process is to ensure that the target firmware data is correctly stored in the EC, and the EC temporarily stores the target firmware data through its memory or flash memory and other areas. It should be noted that the EC side no longer needs to transmit the firmware data through the TOOL side, but the firmware data storage is managed directly by the EC side. After the storage is completed, the EC will prepare the firmware data for subsequent push to the microcontroller (MCU). Among them, the storage of the target firmware data will be based on the size of the firmware capacity, which is suitable for firmware with smaller capacity. For smaller firmware, the EC has enough storage space for storage, and there is no need to store the firmware in an external storage device.

[0056] Secondly, according to the support mode of MCU, the embedded controller (EC) pushes the firmware data to the MCU through the SMBUS or IIC (I2C) communication protocol. The specific protocol to be used depends on the communication interface of the MCU itself and the communication mode supported. EC transmits the target firmware data to the MCU through these protocols. During the data transmission process, EC controls the push of firmware data to ensure that the firmware can be transmitted to the MCU in the correct order and structure. The transmission process may involve operations such as frame data packaging and CRC check, and it is also necessary to perform the status detection process described above.

[0057] Finally, after the MCU receives the firmware data transmitted via the SMBUS or IIC protocol, it will store it in a designated area (such as memory, flash memory, etc.). When receiving the data, the MCU will check the integrity and format of the data to ensure that there are no errors. After the firmware data is received, the MCU will perform the firmware upgrade process according to the target firmware data. The specific process includes writing the firmware, verifying the validity of the firmware, and starting the new firmware. During this process, the MCU needs to perform necessary status checks, back up the current firmware, and execute the new firmware code.

[0058] In addition, when the firmware capacity is not greater than the preset capacity threshold, and the firmware data is directly stored in the designated area of ​​the EC, it is also possible to allow the EC to automatically push the firmware when the terminal device (desktop or laptop) is powered on, based on the user's settings in the BIOS. This can be controlled by a switch, and the user can choose to enable or disable the function of automatically pushing firmware updates. If the user chooses to enable the automatic push function, the EC will decide whether to push the firmware based on the BIOS settings the next time it is powered on. The EC can determine whether to push the firmware by reading the configuration record saved in the Flash. If you choose to disable automatic push, the EC will not push the firmware update until the user manually triggers it or re-enables this function in subsequent operations.

[0059] Through the second upgrade process, this embodiment allows MCUs with smaller firmware capacity to directly store and push firmware data through an embedded controller (EC), simplifying the firmware update process. Data transmission using the SMBUS or IIC protocol ensures the reliability and efficiency of firmware updates. At the same time, this solution is suitable for scenarios where the firmware is small and the EC has sufficient storage space, improving the flexibility and response speed of the system. In this way, the firmware update process can complete fast and secure firmware upgrades without relying on complex hardware facilities, greatly improving the maintainability and stability of the system.

[0060] In some embodiments, when the firmware capacity is not greater than a preset capacity threshold, the firmware data can no longer rely on external tools (TOOL) for storage and transmission, but can be directly stored through an embedded controller (EC). Specifically, the MCU firmware data can be embedded in the EC firmware during the compilation or update process of the EC firmware. In this way, when the EC firmware is updated, the MCU firmware data is also stored in the designated area of ​​the EC. It can be understood that in this process, the MCU firmware data is packaged and stored together with the EC firmware, and the EC serves as a storage and management carrier without relying on external storage devices or TOOL tools to push data. When the EC is updated, the MCU firmware is already stored in a predetermined area inside the EC.

[0061] When the terminal device is powered on, the EC will automatically detect whether the MCU firmware needs to be updated. This process does not rely on the operating system or manual intervention, but is completed by the EC firmware itself. It can be understood that the EC will read the MCU firmware data stored in the specified area at power-on and compare it with the current MCU firmware version. If the current MCU firmware version does not match the preset firmware version, the EC will start the firmware update process and push the new firmware data to the MCU. This process does not require the intervention of the operating system and is completely completed at the hardware level through the communication protocol between the EC and the MCU (such as I2C or SMBUS). That is, when it is confirmed that an update is required, the EC will push the MCU firmware data from the EC storage area to the specified memory area of ​​the MCU through the I2C or SMBUS protocol. After the MCU receives the firmware data, it will execute the firmware upgrade process according to the firmware data. In this process, the MCU firmware upgrade is automatic. The MCU will verify and store the received firmware data, and restart after the verification passes to complete the firmware update.

[0062] It should be noted that when the EC is updated, the MCU firmware is also updated synchronously. This ensures that the MCU firmware always keeps the latest version when the terminal device is powered on and started, without additional manual operation.

[0063] This embodiment embeds the MCU firmware into the EC firmware, making the update process more automated and convenient. The terminal device can complete the update of the MCU firmware by powering on the device without the intervention of the operating system, avoiding the reliance on external tools and improving the stability and update efficiency of the system. This method is particularly suitable for application scenarios with small firmware capacity and high update frequency, reducing manual operations and device reliance, and improving user experience and the system's automated management capabilities.

[0064] The embodiment of the present application provides a firmware update system, which realizes multi-level judgment and optimization through communication interaction between a firmware management tool, an embedded controller and a microcontroller, and provides a flexible, efficient and reliable firmware update process, especially when facing firmware of different capacities, it can effectively handle the update task. First, by obtaining the target firmware data, combined with the firmware capacity and version information, it is ensured that the firmware update operation is carried out under the premise of version matching, thereby avoiding incorrect firmware upgrades and ensuring the stability and security of the device. Secondly, when judging the firmware capacity, the processing method adapted to firmware of different capacities is flexibly selected through the preset capacity threshold. When the firmware capacity is large, the firmware data is processed in batches by the firmware management tool, and the first upgrade process is executed. This method ensures that the large-capacity firmware will not fail due to the excessive burden of the transmission process when updating, and improves the processing capacity and efficiency of the system. For the case of a small firmware capacity, by storing the firmware data in a designated area of ​​the embedded controller and directly executing the second upgrade process, the operation process is simplified, the speed and convenience of the firmware update are improved, and the dependence on external hardware and complex configuration is reduced. This layered processing and intelligent judgment strategy can be flexibly applied in different hardware environments to meet the firmware update needs of various devices, enhancing the adaptability, scalability and overall performance of the firmware update system. Ultimately, by ensuring the accuracy of firmware version matching and capacity judgment, it not only improves the efficiency of firmware updates, but also minimizes the risks in the update process, ensuring the reliability and long-term stable operation of the equipment.

[0065] The present application also provides a firmware update method, which is applied to the above-mentioned firmware update system 100. Figure 2 , Figure 2 : is a flowchart of the firmware update method provided by the embodiment of the present application. Figure 2 As shown, the method includes:

[0066] S11: Obtain target firmware data;

[0067] S12: Obtaining firmware capacity and first firmware version information according to the target firmware data;

[0068] S13: Obtain second firmware version information of the microcontroller;

[0069] S14: judging whether the first firmware version information matches the second firmware version information according to the second firmware version information and the first firmware version information;

[0070] S15: When the first firmware version information does not match the second firmware version information, determine to execute the firmware update process of the microcontroller, and the firmware update process includes: judging whether the firmware capacity is greater than the preset capacity threshold according to the firmware capacity and the preset capacity threshold; when the firmware capacity is greater than the preset capacity threshold, processing the target firmware data in batches and executing the first upgrade process; when the firmware capacity is not greater than the preset capacity threshold, storing the target firmware data in a designated area of ​​the embedded controller and then executing the second upgrade process.

[0071] It should be noted that the above steps S11 to S15 are executed by the firmware update system 100 in the above embodiment, and its specific implementation can refer to the embodiment of the above firmware update system, which has the corresponding functional modules and beneficial effects of the execution method. For technical details not fully described in the firmware update method embodiment, refer to the firmware update system 100 provided in the embodiment of the present application.

[0072] The embodiment of the present application provides a firmware update method, by obtaining target firmware data; according to the target firmware data, obtaining the firmware capacity and the first firmware version information; obtaining the second firmware version information of the microcontroller; according to the second firmware version information and the first firmware version information, judging whether the first firmware version information matches the second firmware version information; when the first firmware version information does not match the second firmware version information, determining to execute the firmware update process of the microcontroller, the firmware update process includes: judging whether the firmware capacity is greater than the preset capacity threshold according to the firmware capacity and the preset capacity threshold; when the firmware capacity is greater than the preset capacity threshold, processing the target firmware data in batches and executing the first upgrade process; when the firmware capacity is not greater than the preset capacity threshold, storing the target firmware data in the designated area of ​​the embedded controller and executing the second upgrade process. Based on this, the present application can flexibly judge whether the firmware update is required according to the firmware capacity and version information, and select the most appropriate upgrade process according to the size of the firmware. For large-capacity firmware, the batch processing method is adopted to avoid the risk of failure caused by transmitting too much data and ensure the smooth progress of the upgrade process. For small-capacity firmware, it is directly stored in the designated area of ​​the embedded controller for push, which simplifies the operation process of firmware upgrade. This intelligent and flexible firmware update method can significantly improve production efficiency and post-shipment maintenance convenience, while reducing the risks caused by firmware update failures and ensuring system reliability.

[0073] The embodiment of the present application further provides a terminal device, which includes the firmware update system 100 described above. The specific structure and function of the firmware update system 100 can be found in the above embodiment, and will not be described in detail here.

[0074] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Under the concept of the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other changes in different aspects of the present application as described above, which are not provided in detail for the sake of simplicity. Although the present application has been described in detail with reference to the aforementioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the aforementioned embodiments can still be modified, or some of the technical features can be replaced by equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A firmware update method, characterized in that: The method comprises: Get the target firmware data; According to the target firmware data, obtaining firmware capacity and first firmware version information; Obtain second firmware version information of the microcontroller; According to the second firmware version information and the first firmware version information, determining whether the first firmware version information matches the second firmware version information; When the first firmware version information does not match the second firmware version information, determining to execute a firmware update process of the microcontroller, the firmware update process comprising: According to the firmware capacity and a preset capacity threshold, determining whether the firmware capacity is greater than the preset capacity threshold; When the firmware capacity is greater than the preset capacity threshold, the target firmware data is processed in batches and a first upgrade process is executed; When the firmware capacity is not greater than the preset capacity threshold, the target firmware data is stored in a designated area of ​​the embedded controller and then a second upgrade process is executed.

2. The firmware update method according to claim 1, characterized in that: The obtaining of the second firmware version information of the microcontroller includes: A version information acquisition instruction is sent to the embedded controller, so that the embedded controller acquires the second firmware version information from the microcontroller according to the version information acquisition instruction.

3. The firmware update method according to claim 1, characterized in that: Before determining to execute the firmware update process of the microcontroller when the first firmware version information does not match the second firmware version information, the method further includes: Sending a firmware preparation instruction to the embedded controller, so that the embedded controller sends an initialization instruction to the microcontroller according to the firmware preparation instruction, so that the microcontroller performs an initialization process according to the initialization instruction, and returns a feedback result to the embedded controller.

4. The firmware update method according to claim 3, characterized in that: The microcontroller executes an initialization process according to the initialization instruction and returns a feedback result to the embedded controller, including: receiving the feedback result forwarded by the embedded controller, and obtaining a response time according to the feedback result; According to the response time and the preset time range, determining whether the response time meets the preset time range; If the response time meets the preset time range, determine to execute the firmware update process; If the response time does not meet the preset time range, it is determined not to execute the firmware update process.

5. The firmware update method according to claim 1, characterized in that: When the firmware capacity is greater than the preset capacity threshold, the target firmware data is processed in batches and a first upgrade process is executed, including: According to a preset segmentation rule, the target firmware data is segmented to obtain a preset number of firmware sub-data; The first upgrade process is executed on the firmware sub-data.

6. The firmware update method according to claim 5, characterized in that: The performing the first upgrade process on the firmware sub-data includes: Sending the firmware sub-data and the firmware verification code to the embedded controller, so that the embedded controller calculates the firmware sub-data to obtain the current firmware verification code; According to the firmware verification code and the current firmware verification code, determining whether the current firmware verification code matches the firmware verification code; If the current firmware verification code matches the firmware verification code, determining to execute the status detection process; If the current firmware verification code does not match the firmware verification code, the first upgrade process ends.

7. The firmware update method according to claim 6, characterized in that: If the current firmware verification code matches the firmware verification code, determining to execute the status detection process includes: Acquiring current system status information of the microcontroller; Detecting the current system status information to obtain a status detection result; If the status detection result satisfies that the current system status information is an idle state, sending the firmware sub-data to a designated area of ​​the microcontroller, so that the microcontroller performs a firmware upgrade according to the firmware sub-data; If the status detection result satisfies that the current system status information is a non-idle state, the first upgrade process is terminated.

8. The firmware update method according to claim 1, characterized in that: When the firmware capacity is not greater than the preset capacity threshold, the target firmware data is stored in a designated area of ​​the embedded controller and then a second upgrade process is performed, including: The target firmware data is sent to a designated area of ​​the embedded controller, so that the embedded controller pushes the target firmware data to the microcontroller, so that the microcontroller performs a firmware upgrade according to the target firmware data.

9. A firmware update system, characterized in that: The firmware update system comprises: a firmware management tool, an embedded controller and a microcontroller, wherein the embedded controller is respectively connected to the firmware management tool and the microcontroller for communication; The firmware management tool is used to: Get the target firmware data; According to the target firmware data, obtaining firmware capacity and first firmware version information; Obtain second firmware version information of the microcontroller; According to the second firmware version information and the first firmware version information, determining whether the first firmware version information matches the second firmware version information; When the first firmware version information does not match the second firmware version information, determining to execute a firmware update process of the microcontroller, the firmware update process comprising: According to the firmware capacity and a preset capacity threshold, determining whether the firmware capacity is greater than the preset capacity threshold; When the firmware capacity is greater than the preset capacity threshold, the target firmware data is processed in batches and a first upgrade process is executed; When the firmware capacity is not greater than the preset capacity threshold, the target firmware data is stored in a designated area of ​​the embedded controller and then a second upgrade process is executed.

10. A terminal device, characterized in that: The terminal device includes the firmware updating system according to claim 9.

Images