Remote burning upgrade method of MCU firmware and cloud mobile phone ARM server

Abstract

The application provides a remote burning upgrade method of MCU firmware and a cloud mobile phone ARM server, and the method comprises the following steps: a BMC receives remote inputted burning upgrade required information of a target MCU and checks the burning upgrade required information, wherein the burning upgrade required information at least comprises target position information of the target MCU and required firmware information; after the checking succeeds, the BMC loads required MCU firmware according to the required firmware information and analyzes the required MCU firmware, and at least obtains a MCU model and a firmware version number; the BMC selects a corresponding communication channel according to the target position information, sends an upgrade instruction to the target MCU, and the upgrade instruction at least comprises the MCU model and the firmware version number; the target MCU checks the MCU model and the firmware version number, and sends checking information to the BMC; the BMC sends the required MCU firmware to the target MCU after confirming that the checking information is correct, the target MCU checks the required MCU firmware, erases original firmware and runs the required MCU firmware after the checking succeeds. The application saves time and labor, and does not affect case assembly and business operation.

Description

Technical Field

[0001] This invention belongs to the field of cloud phone technology, and particularly relates to a method for remotely burning and upgrading MCU firmware and a cloud phone ARM server. Background Technology

[0002] In the cloud phone field, ARM servers are a type of cloud phone server. ARM servers typically use a 2U server chassis, which houses a motherboard. The motherboard contains a Baseboard Management Controller (BMC), the management module for the entire server, used to remotely manage and upgrade the server's firmware or system. The motherboard communicates with the BMC and *a* carrier boards. Each carrier board has one Microcontroller Unit (MCU) and *b* core boards controlled by the MCU, enabling the ARM server to provide the computing power of *a*b* core boards for cloud phones, effectively supporting the smooth operation of cloud phones.

[0003] The MCU's operation and calculations rely on the MCU firmware programmed into it, which is typically done during the server assembly phase. Additionally, sometimes the MCU firmware needs to be upgraded to improve its performance; this upgrade can usually be performed during the server assembly or maintenance phases.

[0004] However, existing MCU firmware flashing and upgrading techniques have the following problems: 1. During the server assembly stage: Before server assembly, it is necessary to connect to the carrier board via a Windows computer and program or upgrade the MCU firmware on the carrier board (offline mode) before assembling the server. This method can only program or upgrade the MCU firmware on each carrier board before assembling the server. This not only consumes a lot of manpower and time, but also hinders the server assembly process. Furthermore, it cannot be done in batches, further affecting the server assembly.

[0005] 2. During server maintenance: If you want to upgrade the MCU firmware on the carrier board, you have to suspend all services of the ARM server. Then, you need to disassemble the server to remove the carrier board from the chassis, and then upgrade the MCU firmware on the carrier board offline (by connecting a computer to a J-Link (ARM emulator), and then using the J-Link to connect to the carrier board for programming or upgrading). Because you can only upgrade one carrier board at a time, rather than performing batch operations, the overall upgrade process is time-consuming, labor-intensive, slow, and inefficient, impacting business operations. Summary of the Invention

[0006] This invention provides a remote firmware flashing and upgrade method for MCUs, aiming to solve the technical problems of existing MCU firmware flashing and upgrade methods, which cannot be performed in batches, are time-consuming and labor-intensive, and affect chassis assembly and business operations.

[0007] This invention is implemented as follows: a remote firmware flashing and upgrade method for an MCU, used in a cloud phone ARM server. The cloud phone ARM server includes a substrate, a BMC electrically disposed on the substrate, and multiple carrier boards communicating with the substrate. Each carrier board is provided with an MCU communicating with the BMC. The remote firmware flashing and upgrade method for the MCU includes: The BMC receives remotely input information required for the pre-programming upgrade of the target MCU and verifies the information required for the pre-programming upgrade. The target MCU may include a single independent MCU or multiple concurrent MCUs. The information required for the pre-programming upgrade includes at least the target location information and the required firmware information of the target MCU. After successful verification, the BMC loads the required MCU firmware corresponding to the target MCU according to the required firmware information, and parses the required MCU firmware to obtain at least the MCU model adapted to the required MCU firmware and the firmware version number of the required MCU firmware. The BMC selects the corresponding communication channel according to the target location information, and sends the upgrade command to the target MCU through the communication channel. The upgrade command includes at least the MCU model and the firmware version number. The target MCU verifies the MCU model and firmware version number, and sends the verification information to the BMC through the communication channel; and After confirming that the verification information is correct, the BMC sends the required MCU firmware to the target MCU through the communication channel. The target MCU verifies the required MCU firmware, and after successful verification, erases the original firmware and runs the required MCU firmware.

[0008] In one embodiment, verifying the information required for the burning and upgrading process includes: The BMC verifies whether the target location information is within the normal location range and whether the file format of the required firmware information is a standard file format. If the target location information is within the normal location range, and the required firmware information is in a standard file format, then the verification passes; and If the target location information is not within the normal range and / or the file format of the required firmware information is not a standard file format, the verification will fail, and the BMC will issue an error message and terminate operation.

[0009] In one embodiment, the BMC loads the required MCU firmware corresponding to the target MCU according to the required firmware information, and parses the required MCU firmware, including: The BMC reads the required MCU firmware corresponding to the target MCU in binary stream form according to the required firmware information, caches the required MCU firmware frame by frame into the BMC's memory buffer, and stores it in segments; and The BMC obtains and parses the firmware header information of the required MCU firmware, and at least extracts the MCU model to which the required MCU firmware is adapted and the firmware version number of the required MCU firmware.

[0010] In one embodiment, sending the upgrade command to the target MCU via the communication channel includes: The BMC sends a connection command to the target MCU through the communication channel and waits for the target MCU to return connection information. If the target MCU returns connection information within a preset time, the BMC establishes a communication connection with the target MCU using the communication channel, and sends the upgrade command to the target MCU through the communication channel; and If the target MCU does not return connection information within a preset time, the BMC determines that the communication channel is faulty, terminates the programming and upgrade process, and records the fault log.

[0011] In one embodiment, the upgrade instruction includes a model verification instruction and a version verification instruction, wherein: The model verification instruction carries the MCU model and is used to request the target MCU to verify whether its own hardware model is consistent with the MCU model. The version verification instruction carries the firmware version number and is used to request the target MCU to verify whether the firmware version number is higher than the current version number of the currently running firmware.

[0012] In one embodiment, the target MCU verifies the MCU model and the firmware version number, and sends the verification information to the BMC through the communication channel, including: The target MCU verifies the MCU model against its own hardware model; If the MCU model does not match its own hardware model, the target MCU sends verification information representing the mismatch to the BMC through the communication channel, causing the BMC to terminate the programming and upgrade process; If the MCU model matches its own hardware model, the target MCU sends the verification information representing the model match to the BMC through the communication channel, and verifies the firmware version number with the current version number; If the firmware version number is higher than the current version number, then flashing and upgrading are allowed, and the target MCU sends the verification information representing the version passing to the BMC through the communication channel; If the firmware version number is not higher than the current version number, then no flashing or upgrade is required. The target MCU sends the verification information indicating that no flashing or upgrade is required to the BMC through the communication channel.

[0013] In one embodiment, after confirming that the verification information is correct, the BMC sends the required MCU firmware to the target MCU through the communication channel. The target MCU verifies the required MCU firmware, and after successful verification, erases the original firmware and runs the required MCU firmware, including: After confirming that the verification information is correct, the BMC will split the required MCU firmware into multiple data packets according to the communication baud rate and preset data length. The BMC sends data transmission instructions to the target MCU packet by packet through the communication channel. The data transmission instructions carry the data packets. The target MCU verifies each received data packet in sequence. After successfully sending all the data packets, the BMC sends a total verification command to the target MCU, the total verification command carrying the overall checksum of the required MCU firmware; and The target MCU verifies the required MCU firmware according to the total verification instruction. After successful verification, the original firmware is erased and the required MCU firmware is run.

[0014] In one embodiment, the BMC sends data transmission instructions packet by packet to the target MCU through the communication channel. Each data transmission instruction carries a data packet. The target MCU verifies each received data packet sequentially, including: The BMC sends a data transmission instruction to the target MCU through the communication channel and waits for the target MCU to return a verification message. The data transmission instruction carries the data packet. The target MCU verifies the received data packet and returns a verification success message or a verification failure message to the BMC. Upon receiving a successful verification message, the BMC sends the next data transmission instruction to the target MCU, continuing this process until all data packets are successfully transmitted packet by packet and the target MCU completes sequential verification of all data packets. When the BMC receives a verification failure message, it retransmits the data transmission instruction to retransmit the data packet that failed verification to the target MCU. If the target MCU still fails verification after n retransmissions, the BMC terminates the programming and upgrade process and records the verification failure log.

[0015] In one embodiment, the remote flashing and upgrading method for the MCU firmware further includes: If the target MCU successfully runs the required MCU firmware, an upgrade success identifier is sent to the BMC via the communication channel. The BMC then prints an upgrade success log based on the upgrade success identifier. The upgrade success log includes at least the channel number of the communication channel, the upgrade burning time, and the firmware version number; and If the target MCU fails to run the required MCU firmware, an upgrade failure identifier representing the cause of the error is sent to the BMC through the communication channel. The BMC records a fault log based on the upgrade failure identifier and supports resuming interrupted downloads.

[0016] This invention also provides a cloud phone ARM server, comprising: substrate; BMC electrically disposed on the substrate; and Multiple carrier boards that communicate with the base plate, each carrier board having an MCU that communicates with the BMC, the BMC and the MCU being used to execute the remote burning and upgrading method of the MCU firmware described above.

[0017] The remote firmware flashing and upgrade method for MCUs in this invention, compared to the offline method used in the existing technology during the server assembly and maintenance stages, allows remote login to the BMC and direct remote flashing and upgrade of the MCU firmware. This allows for remote firmware flashing after server assembly, eliminating the need for pre-flashing offline, thus optimizing the server assembly process and improving assembly efficiency. MCU firmware upgrades no longer require server disassembly, ensuring uninterrupted service operation and maintaining business continuity. Furthermore, for multiple MCUs on multiple carrier boards, simultaneous upgrades are possible without polling or queuing, significantly reducing firmware flashing and upgrade time and greatly improving efficiency. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the structure of the cloud phone ARM server provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the remote firmware burning and upgrade method for MCUs provided in this embodiment of the invention.

[0019] Component symbol explanation: Cloud phone ARM server-100; baseboard-10; BMC-20; carrier board-30; MCU-40. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the invention, and should not be construed as limiting the invention. Furthermore, it should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0021] In the description of this invention, it should be understood that the orientation or positional relationship indicated in the description of direction and positional relationship is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing this invention and simplifying the description, and is not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0022] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0023] The following disclosure provides many different embodiments or examples for implementing different structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. Of course, these are merely examples and are not intended to limit the invention.

[0024] Furthermore, the present invention may repeat reference numerals and / or reference letters in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or settings discussed. In addition, the present invention provides examples of various specific processes and materials, but those skilled in the art will recognize the application of other processes and / or the use of other materials.

[0025] Please see Figure 1 The cloud phone ARM server 100 of this embodiment includes: substrate 10; BMC20 electrically disposed on substrate 10; and Multiple carrier boards 30 communicate with the base plate 10. Each carrier board 30 is equipped with an MCU 40 that communicates with the BMC 20. The BMC 20 and MCU 40 are used to perform a remote burning and upgrading method for the MCU firmware.

[0026] In terms of hardware design, the substrate 10 is a PCB board, and the BMC20 is connected to the carrier board 30 through the circuitry on the PCB board. Specifically, the BMC20 converts multiple serial ports on the substrate 20 via USB to serial port conversion, and each serial port is connected to each carrier board 30, thereby enabling the BMC20 to communicate independently with each MCU40.

[0027] like Figure 1 As shown, the serial port connected to the BMC20 serial port of carrier board 6 is UART6, and the serial port connected to the BMC20 serial port of carrier board 4 is UART4.

[0028] The number of carrier boards 30 can be 12, that is, the BMC20 converts 12 serial ports through USB to serial port, and the 12 serial ports are respectively connected to the MCU40 on the 12 carrier boards 30.

[0029] It should be noted that the existing BMC does not have the function of remote burning and upgrading MCU firmware. Therefore, in terms of software design, the embodiments of the present invention have specially designed the MCU_updat program to run on the BMC20.

[0030] The MCU_update program is a dedicated MCU firmware burning / upgrade program created in this embodiment of the invention. It is developed based on the Linux system and is compatible with Windows cross-platform operation. The MCU_update program is deployed in BMC20. Its core functions include firmware parsing, instruction encapsulation, data transmission, verification control and result feedback, etc. No external emulator is required throughout the process. The entire operation can be completed by relying on the onboard serial port link.

[0031] Based on the combination of the above hardware and software designs, the operating logic, operation steps, and instruction specifications of the MCU_update program (i.e., BMC20) and the MCU40 on the carrier board 30 in this embodiment of the invention are roughly as follows: I. Basic Program Attributes and Runtime Environment 1. Operating platform: BMC20 (Linux system) of Cloud Phone ARM Server 100, supports remote calling from Windows, requires no installation of dependencies, can be run after decompression, and has no environment configuration threshold; 2. Core positioning: serial communication master control terminal, firmware parsing and loading terminal, upgrade process management terminal, replacing the traditional J-link emulator + computer burning tool; 3. Input parameters: Required parameters are the binary file of the MCU firmware (xxx.bin format) and the serial port number of the MCU40 (such as UART1-UART12). Optional parameters include concurrency flag, upgrade timeout and version verification switch, etc.

[0032] II. Firmware Loading and Parsing Logic After the MCU_update program starts, it first executes the firmware loading process to ensure that the firmware file is compliant and the data is complete. The specific steps are as follows: 1. Parameter verification: The MCU_update program reads the bin file path and serial port number input by the user, verifies whether the file format is the standard MCU firmware bin format (xxx.bin, which is the MCU firmware to be burned or upgraded), and whether the serial port number is within the valid range of UART1-UARTn (such as the serial port number UART6 of MCU40 on carrier board 6). If any abnormality is found, an error message will be issued immediately and the program will terminate. 2. Firmware reading: The required MCU firmware is read in binary stream form through the BMC20's file system interface and cached frame by frame into the BMC20's memory buffer to avoid lag when loading large files. 3. Firmware parsing: Parse the header information of the required MCU firmware, extract core parameters such as the compatible MCU model, firmware version number, total firmware length and checksum (CRC32). Then, the MCU_update program prepares the upgrade command and sends it to the target MCU40 of the corresponding carrier board 30 through the corresponding serial port. The target MCU40 pre-compares the upgrade command with the preset parameters and filters out mismatched firmware in advance to prevent burning / upgrade failure. 4. Memory storage: The parsed data of the required MCU firmware is stored in segments, the data packets are split according to the communication baud rate, and the length of a single packet is set (default 128 bytes) to prepare for subsequent packet transmission.

[0033] III. Upgrade Instruction Encapsulation and Interaction Specifications The MCU_update program uses a custom serial communication protocol, encapsulates standardized upgrade instructions, and enables bidirectional interaction with the MCU40. All instructions are in hexadecimal format and include a frame header, instruction code, data segment, checksum, and frame trailer. The core instruction types are as follows: 1. Handshake instruction (0x01): The MCU_update program sends a handshake frame to the target MCU40 to establish a serial communication connection and test the link's connectivity; 2. Model verification command (0x02): Carries the pre-parsed MCU model parameters and requests the target MCU40 to verify its own hardware model; 3. Version verification command (0x03): Carries the firmware version number and requests the target MCU40 to compare the current running version with the version to be upgraded to determine whether an upgrade is needed; 4. Data transmission command (0x04): Carries segmented firmware data to enable firmware packet distribution; 5. Total Verification Command (0x05): Carries the complete CRC32 checksum of the required MCU firmware, requesting the target MCU40 to verify the integrity of all data; 6. Startup command (0x06): The command loads the new firmware (i.e., the required MCU firmware) into the target MCU40 and restarts the program; 7. Result Feedback Command (0x07): Receive the upgrade success / failure flag and the reason for the exception returned by the target MCU40.

[0034] IV. Full-Process Upgrade Execution Steps 1. Program Startup and Parameter Input: Remotely log in to the BMC20 backend, call the MCU_update program, and enter the command format: . / MCU_update -f xxx.bin -p UARTn (-f specifies the firmware path, -p specifies the target serial port number, and n is the number of serial ports). Batch concurrent commands are supported: . / MCU_update -f xxx.bin -p UART1-UARTn; 2. Link handshake and initialization: The MCU_update program sends a handshake command through the specified UART serial port and waits for the target MCU40 to return a response frame. If no response is received within the timeout period, the link is determined to be faulty, the process is terminated and the log is recorded. 3. MCU Model Verification: The MCU_update program sends a model verification command. After receiving it, the target MCU40 compares it with its own chip model (e.g., STM32Fxxx). If they match, it returns an acknowledgment frame; if they do not match, it returns an error code, and the MCU_update program terminates the process. 4. Firmware version comparison: The MCU_update program sends a version verification command. The target MCU40 reads the local firmware version number. If the version to be upgraded is higher than the local version, the upgrade is allowed and a verification pass message is returned. If the versions are the same or lower, the MCU_update program prompts that no upgrade is needed and exits. 5. Firmware packet transmission: The MCU_update program sends data transmission instructions packet by packet according to the preset single packet length. After sending each packet, it waits for the target MCU40 to return a single packet verification success frame to ensure that the single packet data is without packet loss or errors. If the single packet verification fails, the MCU_update program automatically retransmits the packet data, with a maximum of 3 retransmissions. 6. Full data verification: After the MCU firmware is transmitted in packets, the MCU_update program sends a full verification command. The target MCU40 summarizes all the data, calculates the CRC32 checksum, and compares it with the checksum sent by the MCU_update program. If they match, the data is considered complete. 7. New firmware startup: The MCU_update program sends a startup command, the target MCU40 erases the original firmware, writes the new firmware and completes initialization, and loads and runs the new firmware; 8. Result Feedback and Log Recording: The target MCU40 returns an upgrade success flag to the MCU_update program. After receiving the flag, the MCU_update program prints an upgrade success log, which includes information such as the serial port number, time taken, and version number. If the upgrade fails, an exception code is returned (such as verification failure, power failure, etc.). The MCU_update program records the fault log and supports resuming interrupted upgrades.

[0035] V. Logic for Concurrent Upgrade Implementation The MCU_update program supports independent execution of multiple processes, enabling concurrent programming and upgrades across multiple carrier boards on a single server: For multiple UART serial ports, multiple independent MCU_update processes are launched, each bound to its own serial port and firmware file. Memory isolation and independent communication links exist between processes, preventing interference. The MCU_update program has a built-in process scheduling mechanism to balance BMC20 resource usage, avoid concurrent lag, and achieve simultaneous upgrades of multiple MCU40s, significantly improving upgrade efficiency.

[0036] It should be noted that in this embodiment of the invention, the MCU40 itself has the corresponding performance, and thus can realize the various steps that it is required to execute in the remote burning and upgrading method of MCU firmware. The various steps that are executed by BMC20 mentioned in the method are all implemented by the MCU_update program mentioned above in BMC20.

[0037] Please see Figure 1 The remote firmware flashing and upgrade method for MCUs in this embodiment of the invention is used in the cloud phone ARM server 100 mentioned above. Please refer to [link / reference]. Figure 2 The remote flashing and upgrading methods for MCU firmware include: Step S10: The BMC receives the remotely input information required for the pre-programming upgrade of the target MCU and verifies the information required for the pre-programming upgrade. The target MCU may include a single independent MCU or multiple concurrent MCUs. The information required for the pre-programming upgrade includes at least the target location information of the target MCU and the required firmware information.

[0038] When it is necessary to flash or upgrade the MCU firmware, the user enters the flashing and upgrade information required for the target MCU in the BMC. The flashing and upgrade information includes the target location information and the required firmware information. The target location information is the location of the target MCU, and the required firmware information is the MCU firmware information required for this flashing or upgrade of the target MCU. The BMC verifies the flashing and upgrade information to ensure the accuracy of the firmware file itself and to ensure the accurate transmission of the firmware file.

[0039] If the BMC communicates with n MCUs via serial communication, the target MCUs can be MCU1-MCUn, and the corresponding target position information can be position 1-position n. The position can be the serial port number, such as UART1-UARTn. The required firmware information is the binary file of the MCU firmware, in xxx.bin format.

[0040] For example, if the firmware of a single MCU6 is being flashed and upgraded, the command format can be entered in the BMC as: . / mcu_update -f xxx.bin -p UART6 (where -f specifies the firmware path and -p specifies the target serial port number). This command format is the information format required for the flashing and upgrade, where xxx.bin is the required firmware information and UART6 is the target location information.

[0041] If parallel programming and upgrading of MCU1-MCU12 is required this time, the BMC in this embodiment of the invention also supports batch concurrent commands: . / mcu_update -f xxx.bin -p UART1-UART12.

[0042] Step S20: After successful verification, the BMC loads the required MCU firmware corresponding to the target MCU according to the required firmware information, and parses the required MCU firmware to obtain at least the MCU model that the required MCU firmware is compatible with and the firmware version number of the required MCU firmware.

[0043] After BMC successfully verifies the information required for the flashing and upgrade, ensuring that the required firmware information and target location information are correct, it loads the corresponding required MCU firmware through the BMC file system interface according to the required firmware information (xxx.bin). BMC can cache the required MCU firmware in its own memory buffer to avoid lag caused by loading large files and facilitate direct transmission later.

[0044] After loading the required MCU firmware, BMC parses the required MCU firmware to obtain at least the MCU model (such as STM32Fxxx) and firmware version number. This is used to subsequently confirm whether the required MCU firmware is compatible with the target MCU and whether it is a higher version, thereby filtering out incompatible MCU firmware in advance and preventing burning and upgrade failures.

[0045] Step S30: The BMC selects the corresponding communication channel based on the target location information and sends the upgrade command to the target MCU through the communication channel. The upgrade command includes at least the MCU model and firmware version number.

[0046] The target location information is a serial port number, and the corresponding communication channel is the serial port corresponding to the target location information. For example, if the serial port number is UART6, the corresponding communication channel is serial port 6 on the substrate, which connects the carrier board 6 and the MCU6.

[0047] Step S40: The target MCU verifies the MCU model and firmware version number, and sends the verification information to the BMC through the communication channel.

[0048] When the target MCU receives an upgrade command, it verifies the MCU model and firmware version number contained in the upgrade command to ensure that the required MCU firmware is compatible with it and that the required MCU firmware version is a higher version, thus ensuring that the flashing and upgrade process can proceed normally.

[0049] Step S50: After confirming that the verification information is correct, the BMC sends the required MCU firmware to the target MCU through the communication channel. The target MCU verifies the required MCU firmware. After successful verification, the original firmware is erased and the required MCU firmware is run.

[0050] Once the BMC confirms that the verification information is correct, meaning the target MCU has confirmed that the required MCU firmware is compatible and that the required MCU firmware version is a higher version, the BMC will send the required MCU firmware to the target MCU. After that, the target MCU will verify the required MCU firmware again to ensure the integrity of the required MCU firmware data. Then, it will erase the original firmware, write the new required MCU firmware, and run it to realize the MCU firmware burning and upgrade.

[0051] The remote firmware flashing and upgrade method for MCUs in this invention, compared to the offline method used in the existing technology during the server assembly and maintenance stages, allows remote login to the BMC and direct remote flashing and upgrade of the MCU firmware. This allows for remote firmware flashing after server assembly, eliminating the need for pre-flashing offline, thus optimizing the server assembly process and improving assembly efficiency. MCU firmware upgrades no longer require server disassembly, ensuring uninterrupted service operation and maintaining business continuity. Furthermore, for multiple MCUs on multiple carrier boards, simultaneous upgrades are possible without polling or queuing, significantly reducing firmware flashing and upgrade time and greatly improving efficiency.

[0052] In one embodiment, step S10, the step of verifying the information required for the flashing upgrade, includes: Step S11: The BMC verifies whether the target location information is within the normal location range and whether the file format of the required firmware information is a standard file format.

[0053] The normal location range for the target location information is location 1 to location n, such as UART1 to UARTn, and the standard file format for the required firmware information is xxx.bin.

[0054] Step S12: If the target location information is within the normal location range and the required firmware information file format is a standard file format, then the verification passes.

[0055] For example, if the target location information is location 1, such as UART1, it proves that the target location information is within the normal location range. If the required firmware information file format is xxx.bin, it proves that the required firmware information file format is a standard file format. In this case, both the target location information and the required firmware information file format have passed the verification.

[0056] Step S13: If the target location information is not within the normal range and / or the file format of the required firmware information is not a standard file format, the verification will fail, the BMC will issue an error message and terminate the operation.

[0057] For example, if the target location information is location 0, such as UART0, it proves that the target location information is not within the normal location range. If the required firmware information file format is xxx.bln, it proves that the required firmware information file format is not a standard file format. As long as one of the above two does not meet the requirements, the file format of the target location information and the required firmware information will fail the verification. The BMC will immediately issue an error message and terminate the operation, prompting the user to manually check and re-enter the information.

[0058] In one embodiment, step S20, where the BMC loads the required MCU firmware corresponding to the target MCU based on the required firmware information and parses the required MCU firmware, includes: Step S21: The BMC reads the required MCU firmware corresponding to the target MCU in binary stream form according to the required firmware information, caches the required MCU firmware frame by frame into the BMC's memory buffer and stores it in segments.

[0059] Specifically, the required MCU firmware is a binary file. Therefore, the BMC reads the required MCU firmware in binary stream form and caches the required MCU firmware frame by frame to avoid lag when loading large files. The required MCU firmware is also stored in segments to prepare for subsequent transmission and speed up the transmission efficiency.

[0060] Step S22: The BMC obtains and parses the firmware header information of the required MCU firmware, and at least extracts the MCU model that the required MCU firmware is compatible with and the firmware version number of the required MCU firmware.

[0061] After BMC successfully loads the required MCU firmware, it can at least parse the MCU model and firmware version number from the firmware header information of the required MCU firmware, which can be used to verify whether the required MCU firmware is compatible with the target MCU.

[0062] Furthermore, BMC can also parse other parameters such as the total firmware length and checksum from the firmware header information, which can be used for log retention and further verification.

[0063] In one embodiment, step S30, which involves sending the upgrade command to the target MCU via the communication channel, includes: Step S31: The BMC sends a connection command to the target MCU through the communication channel and waits for the target MCU to return connection information.

[0064] The connection instruction is a handshake instruction (0x01), which is a handshake frame sent by the BMC to the target MCU, and the connection information is a response frame. Under normal circumstances, the target MCU will return a response frame within a preset time after receiving the handshake frame sent by the BMC.

[0065] Step S32: If the target MCU returns connection information within a preset time, the BMC establishes a communication connection with the target MCU through the communication channel and sends the upgrade command to the target MCU through the communication channel.

[0066] If the target MCU returns connection information to the BMC within a preset time, it indicates that the communication between the two is normal. At this time, the BMC sends the upgrade command to the target MCU through the communication channel, so that the target MCU can start the subsequent verification action based on the upgrade command.

[0067] Step S33: If the target MCU does not return connection information within the preset time, the BMC determines that the communication channel is faulty, terminates the programming and upgrade process, and records the fault log.

[0068] If the target MCU fails to return connection information to the BMC within the preset time, i.e., the target MCU times out and does not respond, the BMC determines that the communication channel or communication link is faulty, terminates the current burning and upgrade process, and records the fault log for subsequent inspection and maintenance.

[0069] In one embodiment, the upgrade instruction includes a model verification instruction and a version verification instruction, wherein: The model verification instruction (0x02) carries the MCU model and is used to request the target MCU to verify whether its own hardware model is consistent with the MCU model. That is, when the target MCU receives the model verification instruction, it compares the MCU model carried by the model verification instruction with its own hardware model. The version verification instruction (0x03) carries the firmware version number and is used to request the target MCU to verify whether the firmware version number is higher than the current version number of the firmware currently running. That is, when the target MCU receives the version verification instruction, it compares the firmware version number carried by the version verification instruction with the current version number of its own currently running firmware.

[0070] In one embodiment, step S40 includes: Step S41: The target MCU verifies the MCU model against its own hardware model.

[0071] When the target MCU receives the MCU model and firmware version number, it first verifies the MCU model, that is, it compares the MCU model with its own hardware model obtained from the reading to determine whether the two are the same, so as to ensure that the required MCU firmware is compatible with itself.

[0072] Step S42: If the MCU model does not match its own hardware model, the target MCU sends the verification information representing the mismatch to the BMC through the communication channel, causing the BMC to terminate the programming and upgrade process.

[0073] If the MCU model is different from the hardware model, it indicates that the required MCU firmware is incompatible with the target MCU. In this case, the target MCU sends verification information to the BMC. This verification information is an error code, which indicates that the current matching is incorrect. After receiving the error code, the BMC terminates the burning and upgrade process and prompts the user to manually verify the error.

[0074] Step S43: If the MCU model matches its own hardware model, the target MCU sends the verification information representing the model match to the BMC through the communication channel, and verifies the firmware version number with the current version number.

[0075] If the MCU model matches the hardware model, it indicates that the required MCU firmware is compatible with the target MCU. At this time, the target MCU sends verification information to the BMC. This verification information is an acknowledgment frame, which means that the current match is successful. The BMC waits for the target MCU to start the next process.

[0076] Step S44: If the firmware version number is higher than the current version number, then the flashing and upgrade are allowed. The target MCU sends the verification information representing the version passing to the BMC through the communication channel.

[0077] After the MCU model verification is passed, the target MCU starts to verify the firmware version number. First, it reads the current version number of the local firmware. If the firmware version number is higher than the current version number, it indicates that the current process belongs to firmware burning or upgrading. Then, burning or upgrading is allowed, and verification information is returned to the BMC so that the BMC knows that the version verification has passed and can start the next process.

[0078] Step S45: If the firmware version number is not higher than the current version number, then no flashing or upgrade is required. The target MCU sends the verification information indicating that no flashing or upgrade is required to the BMC through the communication channel.

[0079] If the firmware version number is the same as or lower than the current version number, it indicates that the target MCU's MCU firmware does not need to be flashed or upgraded at present. The target MCU returns verification information that no flashing or upgrade is required to the BMC. After receiving the verification information, the BMC issues a prompt that no upgrade is required (such as displaying a pop-up window to the user) and exits the current flashing and upgrade process.

[0080] In one embodiment, step S50 includes: Step S51: After confirming that the verification information is correct, the BMC splits the required MCU firmware into multiple data packets according to the communication baud rate and preset data length.

[0081] After the MCU model and firmware version number are verified, the BMC will split the required MCU firmware into multiple data packets according to the communication baud rate and preset data length. Splitting the required MCU firmware not only prepares for subsequent packet transmission and speeds up data transmission efficiency, but also avoids the problem of lag caused by transmitting a single large file of the required MCU firmware all at once.

[0082] The data length of a single data packet is a preset data length, which is 128 bytes by default.

[0083] Step S52: The BMC sends data transmission instructions to the target MCU packet by packet through the communication channel. The data transmission instructions carry data packets, and the target MCU verifies each received data packet in sequence.

[0084] After splitting the required MCU firmware into multiple data packets, the BMC sends a data transmission command (0x04) to the target MCU packet by packet, sending the multiple data packets to the target MCU in the order in which the required MCU firmware was split. The target MCU needs to verify each received data packet sequentially to ensure that no data is lost or corrupted, thus guaranteeing the integrity of the required MCU firmware.

[0085] Step S53: After successfully sending all data packets, the BMC sends a total verification command to the target MCU. The total verification command carries the overall verification code of the required MCU firmware.

[0086] After the required MCU firmware is transmitted in packets, the BMC sends a total verification command (0x05) to the target MCU. The total verification command carries a total checksum (CRC32) for the target MCU to compare and verify the data integrity of the received required MCU firmware.

[0087] Step S54: The target MCU verifies the required MCU firmware according to the general verification instruction. After successful verification, the original firmware is erased and the required MCU firmware is run.

[0088] The target MCU aggregates the received data packets to form the required MCU firmware, calculates the checksum of the required MCU firmware, and then compares the calculated checksum with the overall checksum carried by the total checksum command.

[0089] If the two check codes match, the target MCU determines that the data of the required MCU firmware is complete and returns the check information representing the data completeness to the BMC. After receiving the check information, the BMC sends a start command (0x06) to the target MCU. After receiving the start command, the target MCU erases its original firmware and writes the new required MCU firmware. After initialization is completed, it can be loaded and run.

[0090] If the two check codes do not match, the target MCU determines that the required MCU firmware data is incomplete and returns check information indicating incomplete data to the BMC. After receiving the check information, the BMC pauses the burning and upgrade process and can send an erase command to the target MCU to erase the required MCU firmware it has received. After the erasure is completed, the BMC resends the required MCU firmware to the target MCU.

[0091] In one embodiment, step S52 includes: Step S521: The BMC sends a data transmission command to the target MCU through the communication channel and waits for the target MCU to return a verification message. The data transmission command carries a data packet.

[0092] After splitting the required MCU firmware into multiple data packets, the BMC sends a data transmission command carrying a single data packet to the target MCU. After sending each data packet to the target MCU, the BMC waits for the target MCU to return a verification message for that data packet to ensure no packet loss or errors. The verification message can be a verification frame.

[0093] Step S522: The target MCU verifies the received data packet and returns a verification success message or a verification failure message to the BMC.

[0094] The target MCU verifies each data packet and returns a verification message for each packet. If the verification is successful, it returns a verification success message; if the verification fails, it returns a verification failure message. The verification success message can be a verification success frame, and the verification failure message can be a verification failure frame.

[0095] Step S523: When the BMC receives the verification success message, it sends the next data transmission instruction to the target MCU. This continues until all data packets are successfully sent one by one and the target MCU completes the sequential verification of all data packets.

[0096] For example, the BMC sends the first data packet to the target MCU. If the target MCU successfully verifies the first data packet, it returns the first verification success message to the BMC. The BMC then sends the second data packet to the target MCU. If the target MCU successfully verifies the second data packet, it returns the second verification success message to the BMC, and so on, until the BMC successfully sends all data packets to the target MCU, and the target MCU successfully completes the verification of all data packets.

[0097] Step S524: When the BMC receives the verification failure message, it resends the data transmission instruction to resend the data packet that failed the verification to the target MCU. If the target MCU still fails the verification after n resends, the BMC terminates the programming and upgrade process and records the verification failure log.

[0098] If a data packet fails to be verified by the target MCU, the target MCU sends a verification failure message to the BMC. After receiving the verification failure message, the BMC automatically retransmits the data packet. The maximum number of retransmissions is n. If the data packet still fails to be verified after n retransmissions, the BMC terminates the current burning and upgrade process, records the verification failure log, and sends a reminder to the user so that the user can manually check whether there is a problem with the data packet.

[0099] Where n is 3, that is, the maximum number of times the BMC can resend the same data packet to the target MCU is 3.

[0100] In one embodiment, the remote firmware flashing and upgrade method for MCUs further includes: Step S60: If the target MCU successfully runs the required MCU firmware, it sends an upgrade success identifier to the BMC through the communication channel. The BMC prints an upgrade success log based on the upgrade success identifier. The upgrade success log includes at least the channel number of the communication channel, the burning and upgrade time, and the firmware version number.

[0101] The BMC sends a result feedback instruction (0x07) to the target MCU. If the target MCU successfully loads and runs the required MCU firmware, it returns an upgrade success flag to the BMC. After receiving the upgrade success flag, the BMC prints an upgrade success log, which includes at least the channel number (i.e., serial port number), the burning and upgrade time, and the firmware version number, as data retention for the MCU firmware burning and upgrade process.

[0102] Step S70: If the target MCU fails to run the required MCU firmware, the upgrade failure flag representing the reason for the abnormality is sent to the BMC through the communication channel. The BMC records the fault log according to the upgrade failure flag and supports breakpoint resume.

[0103] When the target MCU receives the result feedback instruction, if the target MCU fails to load and run the required MCU firmware, that is, the current burning and upgrade fails, it returns an upgrade failure flag to the BMC. The upgrade failure flag can be different exception codes (such as verification failure, power failure, etc.). The BMC records the fault log and supports breakpoint resume to ensure that the subsequent burning and upgrade of the MCU firmware can continue when faced with resolvable exceptions (such as power failure).

[0104] In this specification, the terms "in one embodiment," "in another embodiment," etc., refer to specific features, structures, materials, or characteristics described in connection with embodiments or examples that are included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiments or examples. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0105] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for remotely burning and upgrading MCU firmware, used in a cloud phone ARM server, the cloud phone ARM server comprising a substrate, a BMC electrically disposed on the substrate, and multiple carrier boards communicating with the substrate, each of the carrier boards being provided with an MCU communicating with the BMC, characterized in that, The remote flashing and upgrading method for the MCU firmware includes: The BMC receives remotely input information required for the pre-programming upgrade of the target MCU and verifies the information required for the pre-programming upgrade. The target MCU may include a single independent MCU or multiple concurrent MCUs. The information required for the pre-programming upgrade includes at least the target location information and the required firmware information of the target MCU. After successful verification, the BMC loads the required MCU firmware corresponding to the target MCU according to the required firmware information, and parses the required MCU firmware to obtain at least the MCU model adapted to the required MCU firmware and the firmware version number of the required MCU firmware. The BMC selects the corresponding communication channel according to the target location information, and sends the upgrade command to the target MCU through the communication channel. The upgrade command includes at least the MCU model and the firmware version number. The target MCU verifies the MCU model and firmware version number, and sends the verification information to the BMC through the communication channel; and After confirming that the verification information is correct, the BMC sends the required MCU firmware to the target MCU through the communication channel. The target MCU verifies the required MCU firmware, and after successful verification, erases the original firmware and runs the required MCU firmware.

2. The remote firmware flashing and upgrade method for MCUs according to claim 1, characterized in that, The verification of the information required for the burning and upgrading process includes: The BMC verifies whether the target location information is within the normal location range and whether the file format of the required firmware information is a standard file format. If the target location information is within the normal location range, and the required firmware information is in a standard file format, then the verification passes; and If the target location information is not within the normal range and / or the file format of the required firmware information is not a standard file format, the verification will fail, and the BMC will issue an error message and terminate operation.

3. The remote firmware flashing and upgrade method for MCUs according to claim 1, characterized in that, The BMC loads the required MCU firmware corresponding to the target MCU according to the required firmware information, and parses the required MCU firmware, including: The BMC reads the required MCU firmware corresponding to the target MCU in binary stream form according to the required firmware information, caches the required MCU firmware frame by frame into the BMC's memory buffer, and stores it in segments; and The BMC obtains and parses the firmware header information of the required MCU firmware, and at least extracts the MCU model to which the required MCU firmware is adapted and the firmware version number of the required MCU firmware.

4. The remote firmware flashing and upgrade method for MCUs according to claim 1, characterized in that, Sending the upgrade command to the target MCU through the communication channel includes: The BMC sends a connection command to the target MCU through the communication channel and waits for the target MCU to return connection information. If the target MCU returns connection information within a preset time, the BMC establishes a communication connection with the target MCU using the communication channel, and sends the upgrade command to the target MCU through the communication channel; and If the target MCU does not return connection information within a preset time, the BMC determines that the communication channel is faulty, terminates the programming and upgrade process, and records the fault log.

5. The remote firmware flashing and upgrade method for MCUs according to claim 1 or 4, characterized in that, The upgrade instructions include a model verification instruction and a version verification instruction, wherein: The model verification instruction carries the MCU model and is used to request the target MCU to verify whether its own hardware model is consistent with the MCU model. The version verification instruction carries the firmware version number and is used to request the target MCU to verify whether the firmware version number is higher than the current version number of the currently running firmware.

6. The remote firmware flashing and upgrade method for MCUs according to claim 1, characterized in that, The target MCU verifies the MCU model and firmware version number, and sends the verification information to the BMC through the communication channel, including: The target MCU verifies the MCU model against its own hardware model; If the MCU model does not match its own hardware model, the target MCU sends verification information representing the mismatch to the BMC through the communication channel, causing the BMC to terminate the programming and upgrade process; If the MCU model matches its own hardware model, the target MCU sends the verification information representing the model match to the BMC through the communication channel, and verifies the firmware version number with the current version number; If the firmware version number is higher than the current version number, then flashing and upgrading are allowed, and the target MCU sends the verification information representing the version passing to the BMC through the communication channel; If the firmware version number is not higher than the current version number, then no flashing or upgrade is required. The target MCU sends the verification information indicating that no flashing or upgrade is required to the BMC through the communication channel.

7. The remote firmware flashing and upgrade method for MCUs according to claim 1, characterized in that, After confirming that the verification information is correct, the BMC sends the required MCU firmware to the target MCU through the communication channel. The target MCU verifies the required MCU firmware, and after successful verification, erases the original firmware and runs the required MCU firmware, including: After confirming that the verification information is correct, the BMC will split the required MCU firmware into multiple data packets according to the communication baud rate and preset data length. The BMC sends data transmission instructions to the target MCU packet by packet through the communication channel. The data transmission instructions carry the data packets. The target MCU verifies each received data packet in sequence. After successfully sending all the data packets, the BMC sends a total verification command to the target MCU, the total verification command carrying the overall checksum of the required MCU firmware; and The target MCU verifies the required MCU firmware according to the total verification instruction. After successful verification, the original firmware is erased and the required MCU firmware is run.

8. The remote firmware flashing and upgrade method for MCUs according to claim 7, characterized in that, The BMC sends data transmission instructions packet by packet to the target MCU through the communication channel. Each data transmission instruction carries a data packet. The target MCU verifies each received data packet sequentially, including: The BMC sends a data transmission instruction to the target MCU through the communication channel and waits for the target MCU to return a verification message. The data transmission instruction carries the data packet. The target MCU verifies the received data packet and returns a verification success message or a verification failure message to the BMC. Upon receiving a successful verification message, the BMC sends the next data transmission instruction to the target MCU, continuing this process until all data packets are successfully transmitted packet by packet and the target MCU completes sequential verification of all data packets. When the BMC receives a verification failure message, it retransmits the data transmission instruction to retransmit the data packet that failed verification to the target MCU. If the target MCU still fails verification after n retransmissions, the BMC terminates the programming and upgrade process and records the verification failure log.

9. The remote firmware flashing and upgrade method for MCUs according to claim 1, characterized in that, The remote flashing and upgrading method for the MCU firmware also includes: If the target MCU successfully runs the required MCU firmware, an upgrade success identifier is sent to the BMC via the communication channel. The BMC then prints an upgrade success log based on the upgrade success identifier. The upgrade success log includes at least the channel number of the communication channel, the upgrade burning time, and the firmware version number; and If the target MCU fails to run the required MCU firmware, an upgrade failure identifier representing the cause of the error is sent to the BMC through the communication channel. The BMC records a fault log based on the upgrade failure identifier and supports resuming interrupted downloads.

10. A cloud phone ARM server, characterized in that, include: substrate; BMC electrically disposed on the substrate; as well as Multiple carrier boards that communicate with the base plate, each carrier board having an MCU that communicates with the BMC, the BMC and the MCU being used to execute the remote burning and upgrading method of MCU firmware according to any one of claims 1 to 9.

Images