Firmware upgrading method, master control board and storage medium suitable for semiconductor device

Abstract

Embodiments of the present application relate to the technical field of firmware upgrade, and particularly relate to a firmware upgrade method suitable for semiconductor equipment, a main control board and a storage medium. Embodiments of the present application use a state bitmap to monitor the stage state of each slave control board in real time and accurately. Thus, the firmware upgrade file is transmitted to the slave control board according to the stage state of the slave control board, the state bitmap is updated according to the result of receiving the firmware upgrade file transmitted by the slave control board, and the slave control board is controlled to perform a firmware upgrade operation based on the firmware upgrade file according to the updated state bitmap. Thus, the firmware upgrade of the slave control board is efficiently and accurately performed, the firmware upgrade efficiency and maintenance efficiency are improved, and firmware data loss or transmission errors and the like are reduced or even avoided, thereby ensuring the wafer etching effect.

Description

Technical Field

[0001] This application relates to the field of firmware upgrade technology, and in particular to a firmware upgrade method, main control board and storage medium suitable for semiconductor devices. Background Technology

[0002] In embedded devices, industrial control systems, electrostatic chuck controllers, power module control devices, and distributed multi-board systems, online firmware upgrades are a common requirement. Related technologies typically employ a structure with a bootloader and application partitions, using serial ports, RS485, CAN, USB, EtherCAT mailboxes, or other bus interfaces to perform firmware reception, Flash writing, and reboot / jump operations.

[0003] In semiconductor equipment, to reduce the cost of board-by-board maintenance by the host computer, the host computer uses the main control board as an intermediate forwarding node to perform transparent upgrades to lower-level slave control boards / daughter boards. However, in related technologies, when the semiconductor equipment consists of multiple slave control boards and has a high bus load, the transparent upgrade scheme has significant limitations, including: 1) Each slave control board confirms data packet by packet, resulting in a large number of confirmation messages on the communication link. The effective bus payload is occupied by these confirmation messages, increasing the processing burden on the main control board, leading to low link communication efficiency. Furthermore, when packet loss occurs, the main control board cannot promptly determine whether the problem lies with a single slave control board or the entire communication link, reducing upgrade efficiency; 2) Semiconductor equipment has high precision requirements, and firmware data loss or transmission errors between subsystems and control boards can lead to poor wafer etching results; 3) The main control board cannot quickly identify completed, failed, or missing slave control boards, and cannot make unified progress or partial retransmission decisions based on the overall status of the slave control boards. This results in coarse-grained upgrade monitoring and low maintenance efficiency. Summary of the Invention

[0004] Therefore, one objective of this application is to provide a firmware upgrade method, main control board, and storage medium suitable for semiconductor devices, aiming to improve the low efficiency of firmware upgrades and maintenance of semiconductor devices in related technologies, as well as the poor wafer etching effect caused by missing firmware data or transmission errors.

[0005] In a first aspect, embodiments of this application provide a firmware upgrade method applicable to semiconductor devices, applied to a main control board. The firmware upgrade method for semiconductor devices includes: responding to a firmware upgrade task sent by a host computer, obtaining a firmware upgrade file and determining multiple slave control boards to be upgraded based on the firmware upgrade task; constructing a state bitmap based on the stage states of the slave control boards, the state bitmap including state identifiers representing the stage states of the slave control boards, one state identifier corresponding to one slave control board; transmitting the firmware upgrade file to a target board based on the state bitmap, the target board being the slave control board corresponding to the target identifier in the state bitmap, the target identifier being used to represent the stage state of the slave control board as upgrade ready; updating the state bitmap based on the receiving result identifier transmitted by the target board, obtaining an updated state bitmap, the receiving result identifier representing the result of the target board receiving the firmware upgrade file; and controlling a reference board to perform a firmware upgrade operation based on the firmware upgrade file based on the updated state bitmap, the reference board being the slave control board corresponding to the reference identifier in the updated state bitmap, the reference identifier being used to represent the stage state of the slave control board as submission ready.

[0006] In some embodiments, transmitting a firmware upgrade file to a target board based on a state bitmap includes: responding to a state bitmap satisfying a first preset condition, determining the slave board corresponding to a target identifier in the state bitmap as the target board, the first preset condition including all state identifiers in the state bitmap being target identifiers, the ratio of the number of target identifiers to the number of state identifiers in the state bitmap being greater than or equal to a preset ratio and the failed boards among the multiple slave boards being isolated, the state identifiers corresponding to critical boards among the multiple slave boards being target identifiers, and the state identifiers corresponding to active boards among the multiple slave boards being any one of the target identifiers; dividing the firmware upgrade file into data packets to obtain multiple upgrade data packets; and sequentially transmitting multiple sets of window data to the target board, the window data including at least one upgrade data packet.

[0007] In some embodiments, transmitting multiple sets of window data to the target board in sequence includes: in response to a missing packet bitmap transmitted by the target board, retransmitting the upgrade data packet corresponding to the missing packet identifier in the missing packet bitmap to the target board, wherein one missing packet bitmap corresponds to one set of window data, and the missing packet identifier is used to indicate that the target board has not successfully received the upgrade data packet; in response to the absence of a missing packet identifier in the missing packet bitmap, determining that multiple sets of window data have been successfully transmitted to the target board.

[0008] In some embodiments, the method further includes: marking the target board as a failed board in response to the fact that the number of retransmissions of the upgrade data packet corresponding to the missing packet identifier in the missing packet bitmap is greater than or equal to a preset retransmission number threshold.

[0009] In some embodiments, updating the state bitmap based on the received result identifier transmitted by the target board to obtain an updated state bitmap includes: in response to the received result identifier being a first identifier, updating the target identifier in the state bitmap to a reference identifier, wherein the first identifier indicates that the target board has successfully received the firmware upgrade file; in response to the received result identifier being a second identifier, updating the target identifier in the state bitmap to a verification failure identifier, wherein the second identifier indicates that the target board has not successfully received the firmware upgrade file, and the verification failure identifier indicates that the stage state of the slave control board is a verification failure state; and in response to all target identifiers in the state bitmap being updated, obtaining an updated state bitmap.

[0010] In some embodiments, based on the updated state bitmap, controlling the reference board to perform a firmware upgrade operation based on the firmware upgrade file includes: in response to the updated state bitmap satisfying a second preset condition, determining the slave board corresponding to the reference identifier in the updated state bitmap as the reference board, the second preset condition including all state identifiers in the updated state bitmap being reference identifiers, the ratio of the number of reference identifiers to the number of state identifiers in the updated state bitmap being greater than or equal to a preset ratio and the failed board among the multiple slave boards being isolated, the state identifier corresponding to the critical board among the multiple slave boards being a reference identifier, and the state identifier corresponding to the active board among the multiple slave boards being any one of the reference identifiers; sending a submit activation command to the reference board, so that the reference board performs a firmware upgrade operation based on the firmware upgrade file after receiving the submit activation command.

[0011] In some embodiments, the activation command submission includes activation trigger conditions. After receiving the activation command submission, the reference board performs a firmware upgrade operation based on the firmware upgrade file, including: the reference board parses the activation command submission and extracts the activation trigger conditions; in response to the activation trigger conditions being met, the reference board performs upgrade pre-operations; in response to the completion of the upgrade pre-operations, the reference board loads the firmware upgrade file to jump to the application corresponding to the firmware upgrade file.

[0012] In some embodiments, after sending an activation submission command to the reference board, the reference board performs a firmware upgrade operation based on the firmware upgrade file upon receiving the activation submission command. The method further includes: in response to the presence of a reference identifier in the status bitmap and the failure to receive an activation success identifier transmitted by the reference board within a preset time, controlling the reference board to revert to the application corresponding to the previous version of the firmware upgrade file, or entering a safe waiting mode.

[0013] Secondly, embodiments of this application provide a main control board, including a processor and a memory. The memory is communicatively connected to the processor and stores computer program instructions executable by the processor. When executed by the processor, the computer program instructions cause the main control board to execute the firmware upgrade method for semiconductor devices provided in the first aspect.

[0014] Thirdly, embodiments of this application provide a computer-readable storage medium storing processor-executable computer program instructions, which, when executed by a processor, cause the processor to perform the firmware upgrade method for semiconductor devices provided in the first aspect.

[0015] The embodiments of this application have the following beneficial effects: Unlike related technologies, the embodiments of this application utilize a state bitmap to monitor the stage status of each slave control board in real time and accurately. Thus, firmware upgrade files are transmitted to the slave control boards according to their stage status. The state bitmap is updated based on the result of receiving the firmware upgrade files transmitted by the slave control boards. Based on the updated state bitmap, the slave control boards are controlled to perform firmware upgrade operations based on the firmware upgrade files. In this way, firmware upgrades are performed on the slave control boards efficiently and accurately, improving firmware upgrade efficiency and maintenance efficiency, reducing or even avoiding situations such as missing firmware data or transmission errors, thereby ensuring the wafer etching effect. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the related technologies or embodiments will be briefly introduced below. Obviously, the drawings described below only show some embodiments of this application and should not be considered as limiting the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram illustrating an application scenario of the firmware upgrade method for semiconductor devices provided in some embodiments of this application; Figure 2 This is a schematic diagram of the main control board provided in some embodiments of this application; Figure 3 This is a flowchart illustrating a firmware upgrade method for semiconductor devices provided in some embodiments of this application; Figure 4 This is a schematic diagram of the slave control board and status bitmap provided in some embodiments of this application. Figure 1 ; Figure 5 This is a schematic diagram of the slave control board and status bitmap provided in some embodiments of this application. Figure 2 ; Figure 6 This is a schematic diagram of the slave control board and status bitmap provided in some embodiments of this application. Figure 3 ; Figure 7A This is a schematic diagram of the process of the main control board transmitting window data in some embodiments of this application. Figure 1 ; Figure 7B This is a schematic diagram of the process of the main control board transmitting window data in some embodiments of this application. Figure 2 ; Figure 8 This is a schematic diagram of the slave control board and status bitmap provided in some embodiments of this application. Figure 4 . Detailed Implementation

[0018] To make the objectives and advantages of the embodiments of this application more readily understood, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. The detailed description of the embodiments of this application in the accompanying drawings is not intended to limit the scope of protection claimed by this application, but only represents selected embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] It should be noted that, unless there is a conflict, the various technical features involved in the embodiments of this application described below can be combined with each other, and all are within the protection scope of this application. Furthermore, although functional modules are divided in the device or structural schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. In addition, the terms "first," "second," "third," and other similar expressions used herein do not limit the data or execution order, but are only for illustrative purposes and to distinguish identical or similar items with substantially the same function and effect, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features.

[0020] Unless otherwise defined, the technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. It should be understood that the term "and / or" as used in this specification includes any and all combinations of one or more of the listed items.

[0021] In semiconductor equipment, to reduce the cost of board-by-board maintenance by the host computer, the host computer uses the main control board as an intermediate forwarding node to perform transparent transmission upgrades to the lower-level slave control boards / daughter boards. Related technologies mainly include the following transparent transmission schemes: 1) Serial polling upgrade scheme: The host computer or main control board sequentially sends firmware data to each slave control board / daughter board and waits for confirmation; 2) Broadcast distribution upgrade scheme: The main control board broadcasts the same firmware to multiple slave control boards / daughter boards, but the slave control boards / daughter boards still use independent confirmation, independent writing, and independent restart mechanisms; 3) Point-to-point confirmation upgrade scheme: Each slave control board / daughter board replies with feedback information packet by packet after receiving a data packet, and the main control board retransmits according to the response status; 4) Local valid flag jump scheme: After completing the writing, the slave control board / daughter board only sets the upgrade success flag locally and determines whether to switch to the new application during the next reset.

[0022] In scenarios with a single slave control board or a small number of slave control boards, the above solution can meet basic upgrade requirements. However, when the semiconductor equipment is expanded to multiple slave control boards and the bus load is high, its limitations are obvious, including: 1) Each slave control board confirms data packet by packet, resulting in a large number of confirmation messages on the communication link. The effective bus load is squeezed by the confirmation messages, increasing the processing burden on the main control board, resulting in low link communication efficiency. When packet loss occurs, the main control board cannot determine in time whether the problem is with a single slave control board or the entire communication link, reducing upgrade efficiency; 2) Semiconductor equipment has high precision requirements. Situations such as missing firmware data or transmission errors between subsystems and control boards can lead to poor wafer etching results; 3) The main control board cannot quickly identify slave control boards that have completed, failed, or are missing some sub-packets. It cannot make unified progress or partial retransmission decisions based on the overall status of the slave control boards, resulting in coarse upgrade monitoring granularity and low maintenance efficiency.

[0023] In view of this, embodiments of this application provide a firmware upgrade method applicable to semiconductor devices. By utilizing a state bitmap to monitor the stage status of each slave control board in real time and accurately, firmware upgrade files are transmitted to the slave control boards according to their stage status. The state bitmap is updated based on the result of receiving the firmware upgrade files transmitted by the slave control boards. Based on the updated state bitmap, the slave control boards are controlled to perform firmware upgrade operations based on the firmware upgrade files. In this way, firmware upgrades of the slave control boards are performed efficiently and accurately, improving firmware upgrade efficiency and maintenance efficiency, reducing or even avoiding situations such as firmware data loss or transmission errors, thereby ensuring the wafer etching effect.

[0024] Please see Figure 1 , Figure 1 The illustrations depict application scenarios of firmware upgrade methods for semiconductor devices provided in some embodiments of this application.

[0025] See Figure 1As shown, this application scenario includes a host computer 200, a constant current source 10, and a plasma etching machine 500. The constant current source 10 includes a main control board 100 and N slave control boards (i.e., Figure 1 The diagram shows slave control boards 301, 302, ..., and 30N, and N execution boards (i.e., ...). Figure 1 The execution boards 401, 402, ..., and 40N are shown. Here, N is an integer greater than or equal to 2. The main control board 100 communicates with the host computer 200 and the N slave control boards via a network. It is understood that examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0026] The plasma etching machine 500 is used to etch the substrate 20. The plasma etching machine 500 includes an etching chamber 51 and a coil assembly 52. ​​The coil assembly 52 includes a coil tray 52b and at least one coil 52a stacked on the coil tray 52b. The coil tray 52b is fixed outside the etching chamber 51, and at least one coil 52a is sleeved outside the etching chamber 51. The etching chamber 51 is a sealed, controllable vacuum chamber, a dedicated space for plasma generation and substrate 20 etching, providing a stable, clean, and precisely controllable process environment for the etching of the substrate 20.

[0027] The constant current source 10, acting as a magnetic field control system, generates a controllable auxiliary magnetic field near the etching area of ​​the substrate 20. This field constrains, deflects, or homogenizes the plasma, improving etching uniformity and profile, and enhancing etching accuracy and process stability. The plasma, an ionized beam of charged particles, serves as the etching medium, physically bombarding and chemically etching the surface of the substrate 20 to achieve the fabrication of micro / nano structures with predefined patterns. The substrate 20 is the base material to be etched, typically a silicon wafer, semiconductor wafer, or functional substrate. Under the control of the magnetic field, the plasma directionally etches the surface of the substrate 20 to form the desired micro / nano structures. It is understood that the plasma etching machine 500 in this application embodiment can be a plasma etching machine provided by the prior art. However, the working principle of the constant current source 10 provided in this application embodiment is closely related to the product structure and principle of the plasma etching machine 500. It can cooperate with the plasma etching machine 500 to monitor the working status of the coil 52a and generate a controllable auxiliary magnetic field near the etching area of ​​the substrate 20 to constrain, deflect or homogenize the plasma, thereby improving the etching uniformity and etching profile.

[0028] An execution board is connected to a coil 52a and a slave control board. The slave control board receives and forwards drive commands from the master control board to the execution board. After receiving the drive commands, the execution board provides drive current to the coil 52a, driving the connected coil 52a to generate a magnetic field within the etching cavity 51, thereby controlling the magnetic field of the plasma motion state. By using an independent execution board to drive each individual coil 52a, independent control and current adjustment of the working state of each coil 52a can be achieved, ensuring the controllability and flexibility of the magnetic field distribution within the etching cavity 51. This results in a higher degree of matching between the magnetic field and the plasma, which is beneficial for improving the etching uniformity and etching accuracy of the substrate 20.

[0029] In this embodiment, the main control board 100 is the core control unit of a multi-board distributed system (including a main control board, multiple slave control boards, and multiple execution boards). It is responsible for overall logic scheduling, communication management, human-machine interaction, and data processing, as well as issuing instructions to lower-level boards (e.g., slave control boards). Those skilled in the art will understand that the main control board 100 includes a main control circuit board with an FPGA (Field-Programmable Gate Array), a main control circuit board with a CPU (Central Processing Unit), a main control circuit board with an MPU (Microprocessor Unit), a main control circuit board with an MCU (Microcontroller Unit), or any other suitable circuit board.

[0030] In this embodiment, the main control board 100 acts as a forwarding node for firmware upgrades, transmitting firmware upgrade instructions and files from the host computer to each slave control board, thus enabling batch / centralized firmware upgrades on the slave control boards. It should be understood that the main control board 100 also determines the corresponding drive current for different coils 52a based on their installation positions and structures, generates drive instructions based on the drive current, and sends these instructions to the slave control boards. The slave control boards then forward the drive instructions to the corresponding execution boards. The execution boards parse the drive instructions and provide drive current to the corresponding coils 52a, thereby achieving independent control and current regulation of the operating state of each coil 52a.

[0031] The host computer 200 includes any suitable type of device or apparatus, such as those described in [reference needed]. Figure 1 As shown, the host computer 200 includes a server 201, a laptop computer 202, and a desktop computer 203.

[0032] The slave control board is a lower-level circuit board under the unified management and control of the main control board 100. The slave control board is only responsible for local execution, data acquisition, driving, and communication, and is not responsible for global scheduling. During firmware upgrades, it does not directly connect to the host computer 200; instead, the main control board 100 transmits firmware upgrade instructions and files to complete the firmware upgrade. In some embodiments, the slave control board includes any suitable type of board such as a driver board, data acquisition board, adapter board, expansion board, and interface board. The execution board includes any suitable type of board such as a power board and output board.

[0033] In this embodiment, the host computer 200 sends a firmware upgrade task to the main control board 100 via the network. The firmware upgrade task carries the firmware upgrade file and the unique identifier of the slave control board to be upgraded. The main control board 100 responds to the firmware upgrade task sent by the host computer 200, obtains the firmware upgrade file and identifies multiple slave control boards based on the firmware upgrade task, that is, it parses the firmware upgrade task, extracts the firmware upgrade file and the unique identifier of multiple slave control boards to be upgraded, and determines the slave control boards to be upgraded based on the unique identifier of the slave control boards to be upgraded. For example, the slave control boards to be upgraded include slave control boards 301, 302, 303 and 304.

[0034] For example, the main control board 100 acquires the slave control boards to be upgraded and constructs a state bitmap based on the stage states of the slave control boards to be upgraded (e.g., slave control boards 301, 302, 303, and 304). The state bitmap includes state identifiers representing the stage states of the slave control boards, and one state identifier corresponds to one slave control board. It is readily understood that engineers can use any suitable form or data structure to represent the state bitmap, such as using an array structure, a chart, etc. The embodiments of this application do not impose any limitations on this.

[0035] It should be understood that the state identifiers in the state bitmap change with the stage states of the slave control board. In the embodiments of this application, different state identifiers are used to represent different stage states of the slave control board. For example, the stage states of the slave control board include, but are not limited to, preparation completed, erase completed, upgrade ready, receive completed, verification passed, submission ready, and activation successful, which are represented by the first identifier A1, the second identifier A2, the target identifier A3, the fourth identifier A4, the fifth identifier A5, the reference identifier A6, and the seventh identifier A7, respectively. In some embodiments, the stage states of slave control board 301, slave control board 302, slave control board 303, and slave control board 304 are preparation completed, erase completed, upgrade ready, and upgrade ready, respectively, and the constructed state bitmap is [A1, A2, A3, A3].

[0036] Next, based on the state bitmap, the main control board 100 identifies the slave control board whose stage state is upgrade-ready (i.e., the state identifier is the target identifier) ​​as the target board, and transmits the firmware upgrade file to the target board. The target board is the slave control board corresponding to the target identifier in the state bitmap, and the target identifier is used to represent that the stage state of the slave control board is upgrade-ready. As described in the previous embodiment, the state bitmap is [A1,A2,A3,A3], and the two target identifiers A3 correspond to slave control boards 303 and 304 respectively. The target identifier A3 represents that the stage states of slave control boards 303 and 304 are both upgrade-ready. Thus, slave control boards 303 and 304 are identified as target boards, and the firmware upgrade file is transmitted to the target boards (i.e., slave control boards 303 and 304).

[0037] In this process, the target board receives the firmware upgrade file and generates a reception result identifier based on whether the firmware upgrade file was successfully received, and transmits the reception result identifier to the main control board 100. The main control board 100 updates the status bitmap based on the reception result identifier transmitted by the target board, obtaining an updated status bitmap. The reception result identifier is used to characterize the result of the target board receiving the firmware upgrade file. Referring to the aforementioned embodiment, both the target board (i.e., slave control boards 303 and 304) successfully receive the firmware upgrade file, update the stage status to the reception completion state, and send back a successful reception identifier (characterizing that the target board successfully received the firmware upgrade file) to the main control board 100. The main control board 100 receives the successful reception identifier transmitted by the target board, identifies that the target board has successfully received the firmware upgrade file, and updates the stage status to the reception completion state. It then updates the status identifier corresponding to the target board in the status bitmap (at this time, the target identifier A3) to the fourth identifier A4 to characterize the target board's stage status as the reception completion state. In this embodiment, after successfully receiving the firmware upgrade file, the target board (i.e., slave control board 303 and slave control board 304) verifies the firmware upgrade file and performs a submission preparation operation. After successful verification and completion of the submission preparation operation, it updates the stage status to the submission preparation status and sends a submission preparation flag back to the main control board 100. The main control board 100 receives the successful reception flag transmitted by the target board, identifies that the target board has verified the firmware upgrade file and completed the submission preparation operation, and the stage status has been updated to the submission preparation status. It then updates the status flag corresponding to the target board in the status bitmap (at this time, the fourth flag A4) to the reference flag A6 to characterize the stage status of the target board as the submission preparation status. At this time, the updated status bitmap is [A1, A2, A6, A6].

[0038] In this embodiment, the main control board 100, based on the updated state bitmap, identifies the slave control board whose stage state is "submission preparation" (i.e., the state identifier is a reference identifier) ​​as the reference board, and controls the reference board to perform a firmware upgrade operation based on the firmware upgrade file, thereby completing the firmware upgrade. The reference board is the slave control board corresponding to the reference identifier in the updated state bitmap, and the reference identifier is used to characterize the stage state of the slave control board as "submission preparation". As in the aforementioned embodiment, the updated state bitmap is [A1, A2, A6, A6], and the two reference identifiers A6 correspond to slave control boards 303 and 304 respectively. Reference identifier A6 characterizes that both slave control boards 303 and 304 are in the "submission preparation" stage state. Thus, slave control boards 303 and 304 are identified as reference boards, and the reference boards (i.e., slave control boards 303 and 304) are controlled to perform a firmware upgrade operation based on the firmware upgrade file, enabling the reference boards (i.e., slave control boards 303 and 304) to complete the firmware upgrade. The above methods enable efficient and accurate firmware upgrades for slave control boards, improving firmware upgrade and maintenance efficiency, reducing or even avoiding firmware data loss or transmission errors, thereby ensuring the effectiveness of wafer etching in semiconductor equipment.

[0039] It should be understood that Figure 1 The embodiments shown are merely illustrative of some embodiments of this application, illustrating the use of a main control board 100 to perform firmware upgrades on multiple slave control boards. They do not limit the structure, type, or number of main control boards in other embodiments. For example, in some other embodiments, the main control board may also include... Figure 1 The structure shown has more or fewer components, or has the same Figure 1 The diagram shows different configurations of the structure.

[0040] To facilitate understanding of the firmware upgrade method for semiconductor devices provided in the embodiments of this application, the main control board provided in the embodiments of this application will be described in detail first.

[0041] Please see Figure 2 , Figure 2 A schematic diagram of the main control board provided in some embodiments of this application is shown.

[0042] like Figure 2 As shown, the main control board 100 includes at least one processor 110 and at least one memory 120 connected in communication, wherein, Figure 2 Taking a bus system 130, a processor 110, and a memory 120 as an example, the various components in the main control board 100 are coupled together through the bus system 130, which is used to realize the connection and communication between the various components. It is easy to understand that the bus system 130 may include not only a data bus, but also a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity and brevity, [the following is omitted as it is not part of the main text]. Figure 2 The general labels all buses as Bus System 130. This is understandable. Figure 2 The structures shown in the embodiments are merely illustrative and do not limit the structure of the main control board described above. For example, the main control board may also include components that are more... Figure 2 The structure shown has more or fewer components, or has the same as Figure 2 The diagram shows different configurations of the structure.

[0043] Specifically, the processor 110 is configured to provide computing and control capabilities, supporting the main control board 100 in executing corresponding business logic and functions. For example, it supports the main control board 100 in executing the firmware upgrade method for semiconductor devices provided in the embodiments of this application, or in executing the steps of any possible implementation of the firmware upgrade method for semiconductor devices provided in the embodiments of this application. It is understood that the processor 110 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., and may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0044] The memory 120, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, instructions, and modules, such as the programs, instructions, and modules corresponding to the firmware upgrade method for semiconductor devices in the embodiments of this application. In some embodiments, the memory 120 may include a program storage area and a data storage area. The program storage area stores the operating system and applications required for at least one function, while the data storage area stores data created according to the use of the processor 110. The processor 110 executes various functional applications and data processing of the main control board 100 by running the non-transitory software programs, instructions, and modules stored in the memory 120, thereby implementing the firmware upgrade method for semiconductor devices provided in the embodiments of this application, or executing the steps in any possible implementation of the firmware upgrade method for semiconductor devices provided in the embodiments of this application. In some embodiments, the memory 120 may include high-speed random access memory and may also include non-transitory memory. For example, at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 120 may also include memories remotely located relative to the processor 110, which can be connected to the processor 110 via a communication network. It is understood that examples of the aforementioned communication networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0045] As can be understood from the above, the firmware upgrade method for semiconductor devices provided in this application can be implemented by any suitable type of main control board with certain computing and control capabilities, such as the main control board 100 described above. In some feasible implementations, the firmware upgrade method for semiconductor devices provided in this application can be implemented by a processor executing computer program instructions stored in memory.

[0046] The firmware upgrade method for semiconductor devices provided in this application will be described in detail below, taking into account the exemplary application and implementation of the main control board provided in the embodiments of this application.

[0047] Those skilled in the art will understand that the firmware upgrade method for semiconductor devices provided in this application embodiment can be applied to the aforementioned main control board (such as main control board 100). Specifically, the main body executing the firmware upgrade method for semiconductor devices is one or at least two processors of the main control board.

[0048] Please see Figure 3 In this embodiment of the application, firmware upgrade of the slave control board is achieved based on the state bitmap through steps S31 to S35.

[0049] Step S31: In response to the firmware upgrade task sent by the host computer, obtain the firmware upgrade file and identify multiple slave control boards to be upgraded based on the firmware upgrade task.

[0050] For example, in this embodiment of the application, a firmware upgrade task issued by a host computer is received through a preset communication interface (such as serial port, CAN, Ethernet), the firmware upgrade task is parsed, and task fields are extracted. The task fields include firmware identification information (such as firmware version number, firmware type, target product model), firmware storage path or transmission address (such as URL, local path, data packet identifier), target device range information (such as device ID list, device type, group identifier), and upgrade control parameters (such as upgrade mode, whether to force upgrade, batch strategy).

[0051] For example, the firmware acquisition operation is performed based on the firmware storage path or transmission address. When the address is remote, the firmware upgrade file is downloaded to the main control board's local storage via network protocol. When the data is fragmented, the firmware data packet is received and reassembled to obtain the complete firmware upgrade file. Subsequently, the acquired firmware upgrade file is cached in a preset storage area, and the file index information is recorded.

[0052] This application embodiment obtains the set of currently online slave control boards through bus scanning or heartbeat detection mechanisms. Based on this set, a basic information table for the slave control boards is established. This basic information includes the unique identifier (e.g., ID, address), type (e.g., functional module type), and currently running firmware version of the slave control board. Based on the extracted target device range information, the online slave control boards are filtered to obtain a candidate set. For each candidate slave control board, it is determined whether the board type matches the firmware type and whether the current firmware version meets the upgrade conditions (e.g., version lower than the target version or meets the forced upgrade conditions). Slave control boards that meet these conditions are identified as those to be upgraded, resulting in multiple slave control boards to be upgraded.

[0053] Step S32: Construct a state bitmap based on the stage state of the slave control board.

[0054] In this embodiment, the state bitmap includes state identifiers that represent the stage states of the slave control board, with one state identifier corresponding to one slave control board.

[0055] For example, in this embodiment of the application, multiple selected slave control boards to be upgraded are numbered, and a mapping relationship between the slave control boards and the bit order / position in the status bitmap is established. That is, a unique index value (such as H1, H2, H3, ..., and HN) is assigned to each slave control board, and an index mapping table is established. The index mapping table is used to represent the correspondence between the slave control board identifier (e.g., the assigned unique index value) and the bit order / position of the slave control board in the status bitmap. Throughout the firmware upgrade process, the index mapping table remains unchanged and is used for subsequent slave control board location and status updates.

[0056] This application embodiment predefines a set of stage states for the slave control board and assigns a coded value to each stage state. Stage states include: preparation complete, erase complete, upgrade ready, receive complete, verification passed, submission ready, activation successful, etc. Based on specific implementation requirements, the state encoding method is determined; this application embodiment uses multiple bits (e.g., 2 bits) to represent different stage states of the slave control board.

[0057] Allocate storage space for the status bitmap based on the number of slave control boards and the status encoding method. Initialize a storage space with a size of [size missing]. The state bitmap. To the number of control boards, The number of bits occupied by each slave control board's stage state. The state bitmap is initialized, with the default state set to "normal active state". In this embodiment, all slave control boards are traversed, and based on their default states, a state write operation is performed: the target position / target bit order of the slave control board in the state bitmap is determined according to its index, and the bits corresponding to the target position / target bit order are set to the encoded value of "normal active state" according to a preset encoding rule. After writing the state of all slave control boards, an initial state bitmap is obtained. Finally, the initial state bitmap and index mapping table are stored in local storage for subsequent target board selection, state updates, and upgrade triggering, etc.

[0058] For example, please see Figure 4 , Figure 4 The symbol 'a' shows 25 slave control boards, labeled Q1, Q2, Q3, Q4, Q5, B1, B2, B3, ..., E3, E4, and E5. Figure 4 b in the diagram shows the initial state bitmap, according to Figure 4 In the state bitmap, the bit order / position of each slave control board is L1, L2, L3, L4, L5, M1, M2, M3, ..., P3, P4, and P5. An index mapping table is constructed based on the identifier of each slave control board and its bit order / position in the state bitmap. In this embodiment, based on the default state (i.e., normal active state) of each slave control board, the state identifier corresponding to each slave control board in the state bitmap is initialized to a normal active identifier representing the stage state of each slave control board as normal active, thus obtaining the initial state bitmap. It can be understood that the normal active identifier is... Figure 4 The state identifier A0 in b. It's easy to understand that... Figure 4 In the diagram, position L1 represents row L, column 1; position L2 represents row L, column 2; and so on. Position P4 represents row P, column 4; and position P5 represents row P, column 5.

[0059] This application embodiment divides the entire firmware upgrade process into multiple stages, with each stage connected and transitioned by barrier conditions. The barrier conditions are configured to be any one of the following: all slave control boards are in the corresponding stage state, critical slave control boards are in the corresponding stage state, active slave control boards are in the corresponding stage state, the ratio of the number of slave control boards in the corresponding stage state to the total number of slave control boards is greater than or equal to a preset ratio, and failed slave control boards have been isolated.

[0060] In the embodiments of this application, multiple stages include a preparation stage, an erasure stage, a receiving stage, a verification stage, a submission stage, and an activation stage. The barrier conditions corresponding to each stage may be the same or different.

[0061] This application embodiment parses the firmware upgrade task, generates a unique upgrade session number, and broadcasts a START command and a PREPARE command to all slave control boards. During the preparation phase, upon receiving the upgrade session number, the slave control board locks the upgrade session, checks local resources (such as storage and communication resources), and confirms whether it meets the conditions for receiving data. When the data reception conditions are met, this application embodiment sets the bit corresponding to the target position / target bit sequence in the status bitmap of the slave control board to the encoded value of the "PREPARED" state. It can be understood that after setting the encoded values ​​of the bits corresponding to all slave control boards that meet the conditions (i.e., updating the stage states of all slave control boards that meet the data reception conditions in the status bitmap), the status bitmap is considered as a Prepared_Bitmap. This application embodiment aggregates the Prepared_PREPARED states of all slave control boards, and after meeting or reaching the barrier conditions corresponding to the preparation phase (such as all critical slave control boards being in the Prepared_PREPARED state), it enters the erase phase.

[0062] During the erasure phase, this embodiment of the application sends an erasure command to the slave control board in the PREPARRED state according to the Prepared_Bitmap. After the slave control board receives the erasure command and completes the erasure of the target memory area, this embodiment of the application sets the bit corresponding to the target position / target bit sequence of the slave control board in the status bitmap to the encoded value of "erasure completion state". It can be understood that after setting the encoded values ​​of the bits corresponding to all slave control boards that meet the erasure conditions (that is, updating the stage states of all slave control boards after completing the erasure of the target memory area in the status bitmap), the status bitmap is regarded as the Erased_Bitmap. This embodiment of the application aggregates the erasure completion states of all slave control boards, and enters the receiving phase after the barrier conditions corresponding to the erasure phase are met or reached.

[0063] During the receiving phase, this embodiment broadcasts the firmware upgrade file to the slave control board in units of data windows. Each data window consists of multiple consecutive data packets, which are first buffered, then verified, and then written to the data storage area by each slave control board. This embodiment transmits data from multiple data windows to the slave control board in the erase-complete state according to the Erased_Bitmap. After receiving the data from multiple data windows, this embodiment sets the bit corresponding to the target position / target bit sequence of the slave control board in the status bitmap to the encoded value of "receive-complete state". It can be understood that after setting the encoded values ​​of the bits corresponding to all slave control boards that meet the receiving conditions (i.e., updating the stage states of all slave control boards after receiving data from multiple data windows in the status bitmap), the status bitmap is considered as the receive-complete bitmap Window_Done_Bitmap. This embodiment aggregates the receive-complete states of all slave control boards, and after meeting or reaching the barrier conditions corresponding to the receiving phase, enters the verification phase.

[0064] During the verification phase, after all data windows have been written to the data storage area, each slave control board performs a full packet verification based on a checksum (e.g., CRC, Hash, or signature information), i.e., verifies the legality and integrity of the entire firmware upgrade file. In some embodiments, this application transmits a verification command to all slave control boards in the received state according to the received completion bitmap Window_Done_Bitmap. After the data verification passes, the slave control board receives the verification command and, in this application embodiment, sets the bit corresponding to the target position / target bit sequence of the slave control board in the status bitmap to the encoded value of "verification passed state". It can be understood that after setting the encoded values ​​of the bits corresponding to all slave control boards that meet the verification conditions (i.e., updating the stage states of all slave control boards after verification in the status bitmap), the status bitmap is regarded as the verification passed bitmap Verify_Bitmap. This application embodiment aggregates the verification passed states of all slave control boards, and enters the submission stage after the barrier conditions corresponding to the verification stage are met or reached.

[0065] During the submission phase, this embodiment transmits the submission command to the slave control board in the verification-passed state according to the Verify_Bitmap. After receiving the submission command and performing the submission preparation operation, the slave control board sets the bit corresponding to the target position / target bit sequence in the status bitmap to the encoded value of "submission preparation state". It can be understood that after setting the encoded values ​​of the bits corresponding to all slave control boards that meet the submission conditions (i.e., updating the stage states of all slave control boards after performing the submission preparation operation in the status bitmap), the status bitmap is considered as the Commit_Ready_Bitmap. This embodiment aggregates the submission preparation states of all slave control boards, and enters the activation phase after satisfying or reaching the barrier conditions corresponding to the submission phase.

[0066] During the activation phase, this embodiment transmits an activation command to the slave control board in the commit-ready state according to the Commit_Ready_Bitmap. The activation command carries activation conditions (such as activation timestamp, synchronization count value, or activation window number). Upon receiving the activation command, the slave control board loads the firmware upgrade file after meeting the activation conditions to activate the new application corresponding to the firmware upgrade file. This embodiment sets the bit of the target position / target bit sequence corresponding to the slave control board in the status bitmap to the encoded value of "activation success status". It can be understood that after setting the encoded values ​​of the bits corresponding to all slave control boards that meet the activation success conditions (i.e., updating the stage states of all slave control boards after successful activation in the status bitmap), the status bitmap is considered as the activation success bitmap Activate_Bitmap. This embodiment aggregates the activation success states of all slave control boards to intuitively represent the firmware upgrade status of the slave control boards.

[0067] It is understandable that at each stage, the slave control board can provide feedback on success or failure status. For example, in the submission stage, the slave control board provides feedback on submission preparation (success) status or submission preparation failure status to the master control board. The master control board sets the bit corresponding to the slave control board in the status bitmap that is in the submission preparation (success) status or submission preparation failure status to the encoded value of "submission preparation (success) status" or "submission preparation failure status".

[0068] Step S33: Based on the status bitmap, transfer the firmware upgrade file to the target board.

[0069] In this embodiment, the target board is the slave control board corresponding to the target identifier in the state bitmap. The target identifier is used to characterize the stage state of the slave control board as the upgrade ready state.

[0070] For example, in this embodiment of the application, the current state bitmap is read, and the target identifier is identified based on a preset state encoding rule. According to the target identifier, combined with the slave control board index mapping relationship, the slave control board in the upgrade ready state (i.e., the stage state is upgrade ready state) is found, and the slave control board in the upgrade ready state is determined as the target board.

[0071] For example, please see Figure 5 The current state bitmap is as follows Figure 5 As shown in c, the slave control boards corresponding to target identifier A3 in the state bit diagram include slave control boards Q3, Q4, Q5, B1, B2, ..., E3, E4 and E5. Therefore, slave control boards Q3, Q4, Q5, B1, B2, ..., E3, E4 and E5 are the target boards.

[0072] For example, this application embodiment constructs a transmission scheduling queue based on a set of target boards. The transmission scheduling queue is used to manage the order in which firmware upgrade files are distributed. A communication session is established for each target board in the transmission scheduling queue. An upgrade preparation instruction is sent to the target board based on the communication session. The upgrade preparation instruction includes at least firmware identification information, file size, and verification information (such as CRC / hash value). A preparation response signal is received from the target board. If the target board confirms that it can receive data, the data transmission phase begins. The firmware upgrade file is divided into multiple data packets (e.g., fixed-size data blocks), each data packet is assigned a sequence number, verification information is appended to the data packets, and the firmware data is sent to the target board packet by packet. During transmission, a flow control mechanism is executed, i.e., the data transmission rate is controlled based on the feedback from the target board. After each data packet is sent, a reception confirmation message is received from the target board. Based on the confirmation result, the following processing is performed: if the confirmation is successful, the next data packet is sent; if the confirmation fails or times out, a retransmission operation is performed. When the number of retransmissions exceeds a preset threshold, the target board is marked as a failed board, and the transmission task for that target board is terminated. This application embodiment receives a reception result identifier returned by the target board. Based on the reception result identifier, it determines whether the target board has successfully received the firmware upgrade file. If reception is successful, the encoding value of the corresponding bit in the status bitmap of the target board is updated to obtain the updated status identifier, which represents the stage status of the target board as "reception completed". If reception fails, the status identifier is rolled back to "upgrade ready" or the target board is marked as a failed board. It is determined whether there are still target boards in the transmission scheduling queue that have not completed transmission. If so, the next batch of target boards is scheduled to perform firmware upgrade file transmission. If not, the current round of firmware transmission process ends, and the updated status bitmap is output.

[0073] Step S34: Update the status bitmap based on the received result identifier transmitted by the target board to obtain the updated status bitmap.

[0074] In this embodiment, the receiving result identifier represents the result of the target board receiving the firmware upgrade file. That is, the receiving result identifier is used to indicate whether the target board successfully received the firmware upgrade file or failed to receive the firmware upgrade file.

[0075] For example, in this embodiment of the application, a reception result identifier returned by each target board is received. The reception result identifier includes at least the following fields: slave board identifier (or communication address), reception result type (e.g., reception successful, reception failed, verification failed), and extended information (e.g., failure reason code, received data offset). Protocol parsing is performed on the reception result identifier to extract key fields (such as slave board identifier, reception result type, etc.). Based on the slave board identifier in the reception result identifier, an index mapping table is queried to determine the target position (e.g., bit) of the slave board in the status bitmap, and the corresponding status identifier is determined according to the target position. The status identifier corresponding to the slave board is updated according to the reception result type. That is, if the reception result type is "reception successful," the status identifier is updated to a reception completion identifier indicating that the stage status of the slave board is "reception completed." If the reception result type is reception failed or verification failed, the status identifier is updated to an upgrade ready identifier indicating that the stage status of the slave board is "upgrade ready" or a verification failed identifier indicating that the stage status of the slave board is "verification failed."

[0076] The stage status update follows preset state machine rules to avoid illegal state transitions (such as directly transitioning from "upgrade ready" to "submit ready"). According to the status encoding rules, the stage status of each slave board is written to the corresponding target location's bit, i.e., the encoded value of the corresponding bit is updated. After completing the stage status update for all target boards, all updated status identifiers are summarized to generate the updated status bitmap.

[0077] It is understandable that after updating the status bitmap based on the received result identifier transmitted by the target board and obtaining the updated status bitmap, the verification stage begins. Each slave control board verifies whether the received firmware upgrade file is complete and valid, etc. In this embodiment of the application, the status bitmap is updated synchronously to indicate whether each slave control board has passed the verification.

[0078] In this embodiment, after all slave control boards have been verified, the status bitmap is updated based on the verification results (such as verification passed, verification failed, or verification timed out). Specifically, when a slave control board passes verification, the status identifier corresponding to the slave control board in the status bitmap is updated to a verification pass identifier indicating that the slave control board's stage status is "verification passed." If verification fails or times out, the status identifier corresponding to the slave control board in the status bitmap remains unchanged, resulting in an updated status bitmap.

[0079] For example, in this embodiment of the application, a submission command is sent to the slave control boards in the verification passed state. Each slave control board receives the submission command and performs a submission preparation operation according to it. After all slave control boards have performed the submission preparation operation, the status bitmap is updated. Specifically, when a slave control board completes its submission preparation, the status identifier corresponding to the slave control board in the status bitmap is updated to a submission preparation identifier that indicates the stage state of the slave control board as "submission preparation state". If the submission preparation fails or the submission preparation times out, the status identifier corresponding to the slave control board in the status bitmap remains unchanged, resulting in an updated status bitmap.

[0080] For example, please see Figure 6 The status bitmap after the control panel performs the submit preparation operation is as follows: Figure 6 As shown in d, in the state bit diagram, the state identifiers corresponding to slave control boards Q1 and Q2 are normal active identifiers A0, the state identifier corresponding to slave control board Q2 is target identifier A3, and the state identifiers corresponding to slave control boards Q4, Q5, B1, B2, B3, ..., E3, E4 and E5 are all reference identifiers A6.

[0081] Step S35: Based on the updated state bitmap, control the reference board to perform a firmware upgrade operation based on the firmware upgrade file.

[0082] In this embodiment, the reference board is the slave control board corresponding to the reference identifier in the updated state bitmap. The reference identifier is used to characterize the stage state of the slave control board as the submission preparation state.

[0083] For example, in this application embodiment, the updated status bitmap is read, the reference identifier is identified according to the status coding rules, and the slave control board index mapping relationship is combined to determine the slave control board that is in the submission preparation state (i.e. the stage state is the submission preparation state), and the slave control board that is in the submission preparation state is determined as the reference board.

[0084] For example, please see Figure 6 The status bitmap after the control panel performs the submit preparation operation is as follows: Figure 6 As shown in d, the slave control boards corresponding to reference identifier A6 in the status bit diagram include slave control boards Q4, Q5, B1, B2, B3, ..., E3, E4 and E5. Then slave control boards Q3, Q4, Q5, B1, B2, ..., E3, E4 and E5 are reference boards.

[0085] For example, an upgrade trigger queue is constructed based on a set of reference boards. An upgrade execution command is sent to each reference board in the upgrade trigger queue. The upgrade execution command includes at least the firmware file index or storage address, the upgrade entry address or startup parameters, and verification parameters (such as the overall hash value). The system receives execution confirmation information from the reference board, confirming that the reference board has entered the upgrade process. After receiving the upgrade execution command, the reference board performs a firmware upgrade operation, including: writing the received firmware upgrade file to the target storage area (such as a Flash partition), performing segmented verification during the writing process, performing an overall integrity verification after writing is complete, and performing firmware switching according to the upgrade strategy (such as rebooting to load new firmware or switching between two partitions). During the upgrade execution process, the main control board monitors the status of the reference boards, specifically including: receiving periodic status reports (such as upgrade progress, current stage), detecting abnormal situations (such as upgrade timeout, write failure), and if an abnormality is detected, marking the corresponding reference board as having an abnormal upgrade status and recording the abnormal information for subsequent processing.

[0086] After the reference board completes the upgrade, the system receives the upgrade result identifier returned by the reference board. This identifier includes an upgrade success identifier or an upgrade failure identifier, and an optional error code or failure reason. Based on the upgrade result, a status update is performed. If the upgrade is successful, the status identifier corresponding to the slave control board in the status bitmap is updated to an activation success identifier indicating that the slave control board's stage status is "activation successful." If the upgrade fails, the status identifier corresponding to the slave control board in the status bitmap is updated to an upgrade failure identifier indicating that the slave control board's stage status is "upgrade failed" or an upgrade ready identifier indicating that the slave control board's stage status is "upgrade ready." The system checks whether there are still reference boards in the upgrade trigger queue that have not yet been upgraded or whose upgrades have not been completed. If so, the system continues to schedule reference boards to perform firmware upgrade operations; otherwise, the upgrade execution process ends. This embodiment summarizes the stage statuses of all reference boards, generates a final status bitmap, and feeds the final status bitmap back to the host computer or records it in the system log for upgrade result confirmation and traceability.

[0087] This application embodiment utilizes a state bitmap to monitor the stage status of each slave control board in real time and accurately. Thus, the firmware upgrade file is transmitted to the slave control board according to its stage status, and the state bitmap is updated according to the result of receiving the firmware upgrade file transmitted by the slave control board. Based on the updated state bitmap, the slave control board is controlled to perform a firmware upgrade operation based on the firmware upgrade file to complete the firmware upgrade. In this way, the firmware upgrade of the slave control board is performed efficiently and accurately, improving the firmware upgrade efficiency and maintenance efficiency, reducing or even avoiding situations such as firmware data loss or transmission errors, thereby ensuring the wafer etching effect.

[0088] In one embodiment, the present application embodiment achieves the transmission of firmware upgrade files to the target board based on a state bitmap through steps S331 to S333.

[0089] Step S331: If the response state bitmap meets the first preset condition, determine the slave control board corresponding to the target identifier in the state bitmap as the target board.

[0090] In this embodiment, the first preset conditions include all state identifiers in the state bitmap being target identifiers, the ratio of the number of target identifiers to the number of state identifiers in the state bitmap being greater than or equal to a preset ratio and the failed boards in the multiple slave control boards being isolated, the state identifiers corresponding to the critical boards in the multiple slave control boards being target identifiers, and the state identifiers corresponding to the active boards in the multiple slave control boards being any one of the target identifiers.

[0091] For example, when all status identifiers in the status bitmap are target identifiers, it means that all slave control boards are in the upgrade ready state (i.e., all stage states are upgrade ready state). The status bitmap meets the first preset condition, and the slave control board corresponding to each target identifier in the status bitmap is determined as the target board.

[0092] For example, when the ratio of the number of target identifiers to the number of status identifiers in the status bitmap is greater than or equal to a preset ratio, and the failed boards among multiple slave control boards are isolated, it indicates that most slave control boards are in the upgrade-ready state (i.e., all stages are in the upgrade-ready state), and the failed boards are isolated (slave control boards marked as failed boards will no longer undergo firmware upgrades, which does not affect the upgrades of other slave control boards). The slave control boards corresponding to each target identifier in the status bitmap are then identified as target boards. For example, the preset ratio is set to 90%, and the number of status identifiers in the status bitmap is... The number of target identifiers is [number]. The ratio of the number of target identifiers to the number of state identifiers in the state bitmap is calculated as follows: Therefore, the ratio If the ratio is greater than 90% of the preset value, the status bitmap meets the first preset condition, and the slave control board corresponding to each target identifier in the status bitmap is determined as the target board.

[0093] For example, when the status identifier corresponding to the key board among multiple slave control boards is the target identifier, that is, the status identifier corresponding to the slave control board marked as a key board in the status bitmap is the target identifier, please refer to [link to relevant documentation]. Figure 5 Control boards B1, B2, B3, B4, ..., E3, E4, and E5 are all marked as critical boards, and the status bitmap (i.e. Figure 5In c), the status identifiers corresponding to the key boards (i.e., slave control boards B1, B2, B3, B4, ..., E3, E4 and E5) are all target identifiers A3. The status bitmap satisfies the first preset condition, and the slave control boards corresponding to each target identifier in the status bitmap are determined as target boards.

[0094] For example, when the status identifier corresponding to the active board among multiple slave control boards is the target identifier, that is, the status identifier corresponding to the slave control board marked as the active board in the status bitmap is the target identifier, please refer to [link to relevant documentation]. Figure 5 Control boards B1, B2, B3, B4, ..., E3, E4, and E5 are all marked as active boards, according to the status bitmap (i.e., Figure 5 In c), the status identifiers corresponding to the active boards (i.e., slave control boards B1, B2, B3, B4, ..., E3, E4 and E5) are all target identifiers A3. The status bitmap satisfies the first preset condition, and the slave control boards corresponding to each target identifier in the status bitmap are determined as target boards.

[0095] Step S332: Divide the firmware upgrade file into data packets to obtain multiple upgrade data packets.

[0096] Step S333: Transfer multiple sets of window data to the target board in sequence.

[0097] In this embodiment, the window data includes at least one upgrade data packet. Specifically, in this embodiment, the firmware upgrade file is divided into data packets to obtain multiple upgrade data packets. Continuous firmware packets (i.e., upgrade data packets) are sent in units of windows; that is, multiple upgrade data packets are grouped in units of windows to obtain multiple sets of window data. A sequence number is assigned to each set of window data, and the multiple sets of window data are transmitted to the target board sequentially according to the sequence number.

[0098] In some embodiments, the present application implements the sequential transmission of multiple sets of window data to the target board through steps 3331 to 3332.

[0099] Step S3331: In response to the missing packet bitmap transmitted by the target board, retransmit the upgrade data packet corresponding to the missing packet identifier in the missing packet bitmap to the target board.

[0100] In this embodiment, one missing packet bitmap corresponds to a set of window data. The missing packet bitmap includes a missing packet identifier and / or a completion identifier. The completion identifier indicates that the target board successfully received the upgrade data packet, and the missing packet identifier indicates that the target board failed to receive the upgrade data packet. It can be understood that the number of identifiers in the missing packet bitmap is the same as the number of upgrade data packets, and one identifier corresponds to one upgrade data packet. This identifier is used to indicate whether the target board successfully received or failed to receive the upgrade data packet.

[0101] For example, during the process of sending multiple sets of window data to the target board in units of windows, for each set of window data, the target board receives the window data, generates a corresponding missing packet bitmap based on the reception status of each upgrade data packet in each set of data, and transmits the missing packet bitmap to the main control board. In this embodiment, the missing packet bitmap transmitted by the target board is received, parsed, and it is determined whether there is a missing packet marker in the missing packet bitmap. When a missing packet marker exists in the missing packet bitmap, the upgrade data packet corresponding to the missing packet marker (i.e., the lost upgrade data packet) is determined based on the missing packet marker, and the target board has not successfully received this upgrade data packet (i.e., the lost upgrade data packet). After determining the lost upgrade data packet, this embodiment retransmits the upgrade data packet corresponding to the missing packet marker (i.e., the lost upgrade data packet) to the target board.

[0102] For example, see Figure 7A To the target board ( Figure 7A (Taking slave control boards B1, B2, and B3 as examples) During the transmission of window data W1, slave control boards B1, B2, and B3 respectively transmit the generated missing packet bitmaps V1, V2, and V3 to the main control board. Missing packet bitmap V1 is 00000000, V2 is 00010010, and V3 is 00000010. In this embodiment, the identifiers of the missing packet bitmaps include the numbers 0 and / or 1. Number 0 is a completion identifier, indicating that the target board has successfully received the upgrade data packet, while number 1 is a missing packet identifier, indicating that the target board has not successfully received the upgrade data packet. All identifiers in the missing packet bitmap V1 of slave control board B1 are completion identifiers, indicating that slave control board B1 has successfully received all upgrade data packets. In the packet loss bitmap V2 of control board B2, the fourth and seventh identifiers are packet loss identifiers, and the other identifiers are completion identifiers. This indicates that control board B2 has successfully received all upgrade data packets in window data W1 except for the fourth and seventh upgrade data packets. The fourth and seventh upgrade data packets in window data W1 were not successfully received, meaning they are lost upgrade data packets. In this embodiment, the fourth and seventh upgrade data packets in window data W1 are retransmitted to control board B2. Similarly, in the packet loss bitmap V3 of control board B3, the seventh identifier is a packet loss identifier, and the other identifiers are completion identifiers. This indicates that control board B3 has successfully received all upgrade data packets in window data W1 except for the seventh upgrade data packet. The seventh upgrade data packet in window data W1 was not successfully received, meaning it is a lost upgrade data packet. In this embodiment, the seventh upgrade data packet in window data W1 is retransmitted to control board B3.

[0103] It is understandable that when the upgrade data packet corresponding to the missing packet flag (i.e., the lost upgrade data packet) is retransmitted to the target board, the target board regenerates the missing packet bitmap. In the regenerated missing packet bitmap, the flags corresponding to the successfully received upgrade data packets are assigned the value of a completion flag. Based on the reception status of the retransmitted upgrade data packets, the target board assigns either a completion flag or a missing packet flag to the flags corresponding to the retransmitted upgrade data packets in the missing packet bitmap, and then transmits the regenerated missing packet bitmap to the main control board. Specifically, when all flags in the missing packet bitmap are completion flags, it indicates that the target board has successfully received all upgrade data packets in the window data and sends a receive flag (OK) to the main control board. For example, please refer to [link to relevant documentation]. Figure 7A As shown, slave control boards B1, B2, and B3 have all successfully received all upgrade data packets in window data W1, and each sends a receive flag OK to the main control board. The main control board then sends a command to the host computer indicating that the window data W1 has been successfully received, thus notifying the host computer that slave control boards B1, B2, and B3 have all successfully received window data W1.

[0104] In some embodiments, when the main control board performs a firmware upgrade on the execution board, the target board is the execution board that is to be upgraded and is in an upgrade-ready state. Please refer to... Figure 7B The main control board sends data to the target board ( Figure 7B (Taking execution boards B11 and B21 as examples) During the process of sending window data W2, execution board B11 transmits the generated missing packet bitmap V11 to slave control board B1, and slave control board B1 transmits the missing packet bitmap V11 to master control board; execution board B21 transmits the generated missing packet bitmap V21 to slave control board B2, and slave control board B2 transmits the missing packet bitmap V21 to master control board. Missing packet bitmap V11 is 00000000, and missing packet bitmap V21 is 00000110. In this embodiment, the identifiers of the missing packet bitmaps include the numbers 0 and / or 1, where 0 is a completion identifier, indicating that the target board has successfully received the upgrade data packet, and 1 is a missing packet identifier, indicating that the target board has not successfully received the upgrade data packet. All identifiers in the missing packet bitmap V11 are completion identifiers, indicating that execution board B11 has successfully received all upgrade data packets. In the missing packet bitmap V21, the sixth and seventh identifiers are missing packet identifiers, and the other identifiers are completion identifiers. The execution board B21 has successfully received all upgrade packets in window data W2 except for the sixth and seventh upgrade packets. The sixth and seventh upgrade packets in window data W2 were not successfully received. That is, the sixth and seventh upgrade packets in window data W2 are lost upgrade packets. In this embodiment, the sixth and seventh upgrade packets in window data W2 are retransmitted to the slave control board B2, and the slave control board B2 transmits the sixth and seventh upgrade packets in window data W2 to the execution board B21.

[0105] It is understandable that when the upgrade data packets corresponding to the missing packet flags (i.e., the lost upgrade data packets) are retransmitted to the target boards (including execution boards B11 and B21), the target boards regenerate the missing packet bitmap. In the regenerated missing packet bitmap, the flags corresponding to the successfully received upgrade data packets are assigned the value of a completion flag. Based on the reception status of the retransmitted upgrade data packets, the target boards assign either a completion flag or a missing packet flag to the flags corresponding to the retransmitted upgrade data packets in the missing packet bitmap, and then transmit the regenerated missing packet bitmap to the main control board. When all flags in the missing packet bitmap are completion flags, it indicates that the target board has successfully received all upgrade data packets in the window data, and sends the "OK" reception flag to the main control board. For example, please refer to [link to relevant documentation]. Figure 7B As shown, both execution boards B11 and B21 have successfully received all upgrade data packets of window data W2, and respectively send a receive flag OK to slave control boards B1 and B2. Slave control boards B1 and B2 then transmit the receive flag OK to the main control board. After successfully receiving the receive flag OK, the main control board sends a command to the host computer indicating that the reception of window data W2 is complete, informing the host computer that both execution boards B11 and B21 have successfully received window data W2.

[0106] Understandably, in Figure 7B In the illustrated embodiment, the slave control board B1 acts as a forwarding board, transmitting window data W2 and other data sent by the main control board to the execution board B11, and transmitting the missing packet bitmap V11 and the receive flag OK sent by the execution board B11 to the main control board. Similarly, the slave control board B2 acts as a forwarding board, transmitting window data W2 and retransmitted lost upgrade data packets sent by the main control board to the execution board B21, and transmitting the missing packet bitmap V21 and the receive flag OK sent by the execution board B21 to the main control board.

[0107] Step S3332: In response to the absence of a missing packet marker in the missing packet bitmap, determine that multiple sets of window data have been successfully transmitted to the target board.

[0108] For example, after receiving and parsing the missing packet bitmap transmitted by the target board, if there is no missing packet marker in the missing packet bitmap, it indicates that the target board has successfully received the window data corresponding to the missing packet bitmap, and all upgrade data packets in that window data group have been correctly and completely transmitted to the target board. If none of the missing packet bitmaps transmitted by the target board contain missing packet markers, it indicates that the target board has successfully received all window data, and all window data has been correctly and completely transmitted to the target board, confirming that multiple groups of window data have been successfully transmitted to the target board.

[0109] Compared to the packet-by-packet confirmation method, the mechanism provided in this application significantly reduces the number of confirmations required by packet-by-packet confirmation, thereby reducing the number of message interactions, reducing bus bandwidth usage, and allowing for accurate resending of individual lost upgrade data packets, thus improving firmware upgrade efficiency and accuracy.

[0110] In some embodiments, the firmware upgrade method for semiconductor devices provided in this application further includes step S3333.

[0111] Step S3333: In response to the fact that the number of retransmissions of the upgrade data packet corresponding to the missing packet identifier in the missing packet bitmap is greater than or equal to the preset retransmission number threshold, the target board is marked as a failed board.

[0112] In this embodiment, for each set of window data, the main control board determines the upgrade data packet corresponding to the missing packet identifier based on the missing packet bitmap fed back by the target board, and retransmits the upgrade data packet corresponding to the missing packet identifier, then counts the number of retransmissions. If the number of retransmissions of the upgrade data packet corresponding to the missing packet identifier is greater than or equal to a preset retransmission threshold, it indicates that the target board's data reception has failed, and the retransmission of the upgrade data packet to the target board is stopped, and the target board is marked as a failed board. It is understood that engineers can customize and set the retransmission threshold based on experimental data and experience data, such as setting the retransmission threshold to 2 times, 3 times, or other any other suitable number. This embodiment does not make any specific limitation in this regard.

[0113] In this embodiment, if a slave control board still experiences data reception failures (such as write failure, verification failure, or communication timeout) within a preset retransmission threshold, this embodiment marks the slave control board as a failed board, stops firmware upgrades for the failed board, does not terminate the firmware upgrade process for other slave control boards, and continues to advance the firmware upgrade process for other slave control boards. This avoids the failure of a single slave control board from hindering the firmware upgrade and update of the entire batch of slave control boards, improves the completion rate of batch firmware upgrade tasks, and enhances the fault tolerance capability and on-site maintenance efficiency of firmware upgrades.

[0114] For example, in this embodiment of the application, steps S341 to S343 are used to update the status bitmap based on the received result identifier transmitted by the target board, and obtain the updated status bitmap.

[0115] Step S341: In response to the received result identifier being the first identifier, update the target identifier in the state bitmap to the reference identifier.

[0116] In this embodiment, the first identifier indicates that the target board has successfully received the firmware upgrade file, and the reference identifier is used to indicate that the stage status of the slave control board is the submission preparation state.

[0117] For example, in this embodiment of the application, the receiving result identifier transmitted by the target board is parsed. If the receiving result identifier is the first identifier, it indicates that the target board has successfully received the firmware upgrade file. The verification command and the submission command are sent to the target, so that the target board performs the firmware upgrade file verification operation according to the verification command to verify the firmware upgrade file, and performs the submission preparation operation according to the submission command to enter the submission stage.

[0118] For example, after the target board performs the verification operation and the submission preparation operation, the target board is in the submission preparation state (that is, the stage state of the target board is the submission preparation state), and the state identifier corresponding to the target board in the state bitmap is updated from the target identifier to the reference identifier.

[0119] For example, please see Figure 6 After performing the verification and submission preparation operations on the target boards (i.e., slave control boards Q4, Q5, B1, B2, B3, ..., E3, E4, and E5), the updated status bitmap is as follows: Figure 6 As shown in d, in the status bit diagram, the status identifiers corresponding to control board Q4, Q5, B1, B2, B3, ..., E3, E4 and E5 have all been updated from target identifier A3 to reference identifier A6.

[0120] Step S342: In response to the received result identifier being the second identifier, update the target identifier in the status bitmap to the verification failure identifier.

[0121] In this embodiment, the second identifier indicates that the target board has not successfully received the firmware upgrade file, and the verification failure identifier indicates that the stage status of the slave control board is a verification failure state.

[0122] For example, in this embodiment of the application, the receiving result identifier transmitted by the target board is parsed. If the receiving result identifier is the second identifier, it means that the target board has not successfully received the firmware upgrade file and the target board is in a verification failure state (i.e., the stage state of the target board is the verification failure state). The status identifier corresponding to the target board in the status bitmap is updated from the target identifier to the verification failure identifier.

[0123] For example, please see Figure 8 When the received result identifiers transmitted by the target board (i.e., the control boards Q4, Q5, B1, B2, B3, ..., E3, E4, and E5) are all the second identifier, the updated status bitmap is as follows: Figure 8 As shown in e, in the updated status bitmap, the status identifiers corresponding to control board Q4, Q5, B1, B2, B3, ..., E3, E4 and E5 have all been updated from target identifier A3 to verification failure identifier F9.

[0124] Step S343: In response to the fact that all target identifiers in the state bitmap have been updated, the updated state bitmap is obtained.

[0125] For example, based on the received result identifier transmitted by the target board, all target identifiers in the status bitmap are updated to the corresponding reference identifiers or verification failure identifiers to obtain the updated status bitmap.

[0126] For example, in the embodiments of this application, steps S351 to S352 are used to control the reference board to perform a firmware upgrade operation based on the firmware upgrade file, based on the updated state bitmap.

[0127] Step S351: In response to the updated state bitmap satisfying the second preset condition, determine the slave control board corresponding to the reference identifier in the updated state bitmap as the reference board.

[0128] In this embodiment, the second preset conditions include all state identifiers in the updated state bitmap being reference identifiers, the ratio of the number of reference identifiers to the number of state identifiers in the updated state bitmap being greater than or equal to a preset ratio and the failed boards in the multiple slave control boards being isolated, the state identifiers corresponding to the critical boards in the multiple slave control boards being reference identifiers, and the state identifiers corresponding to the active boards in the multiple slave control boards being any one of the reference identifiers.

[0129] For example, when all status identifiers in the updated status bitmap are reference identifiers, it means that all slave control boards are in the submission preparation state (i.e., all stage states are in the submission preparation state). That is, the updated status bitmap meets the second preset condition, and the slave control board corresponding to each reference identifier in the updated status bitmap is determined as the reference board.

[0130] For example, when the ratio of the number of reference identifiers to the number of status identifiers in the updated status bitmap is greater than or equal to a preset ratio, and the failed boards among multiple slave control boards are isolated, it indicates that most slave control boards are in the commit-ready state (i.e., all stages are in the commit-ready state), and the failed boards are isolated (slave control boards marked as failed boards will no longer undergo firmware upgrades, and this does not affect the upgrades of other slave control boards). In this case, the slave control board corresponding to each reference identifier in the updated status bitmap is determined as the reference board. For example, the preset ratio is set to 90%, and the number of status identifiers in the updated status bitmap is... There are [number] reference identifiers. The ratio of the number of reference markers to the number of state markers in the updated state bitmap is calculated as follows: Therefore, the ratio If the ratio is greater than 90% of the preset value, the updated state bitmap meets the second preset condition, and the slave control board corresponding to each reference icon in the updated state bitmap is determined as the reference board.

[0131] For example, when the status identifier corresponding to the key board among multiple slave control boards is a reference identifier, that is, in the updated status bitmap, the status identifiers corresponding to the slave control boards marked as key boards are all reference identifiers, please refer to [link to relevant documentation]. Figure 6 Control boards B1, B2, B3, B4, ..., E3, E4, and E5 are all marked as critical boards, and the updated status bitmap (i.e. Figure 6In section d), the status identifiers corresponding to the key boards (i.e., slave control boards B1, B2, B3, B4, ..., E3, E4 and E5) are all reference identifiers A6. The updated status bitmap satisfies the second preset condition, and the slave control boards corresponding to each reference identifier in the updated status bitmap are determined as reference boards.

[0132] For example, when the status identifier corresponding to the active board among multiple slave control boards is the reference identifier, that is, in the updated status bitmap, the status identifiers corresponding to the slave control boards marked as active boards are all reference identifiers, please refer to [link to relevant documentation]. Figure 6 Control boards B1, B2, B3, B4, ..., E3, E4, and E5 are all marked as active boards, and the updated status bitmap (i.e., Figure 6 In d), the status identifiers corresponding to the active boards (i.e., slave control boards B1, B2, B3, B4, ..., E3, E4 and E5) are all reference identifiers A3. The updated status bitmap satisfies the second preset condition, and the slave control boards corresponding to each reference identifier in the updated status bitmap are determined as reference boards.

[0133] Step S352: Send a submit activation command to the reference board so that the reference board performs a firmware upgrade operation based on the firmware upgrade file after receiving the submit activation command.

[0134] For example, in this embodiment of the application, an activation submission command is sent to the reference board. The activation submission command carries activation conditions (such as an activation timestamp, synchronization count value, or activation window number). After receiving the activation submission command, the reference board waits locally until the activation conditions in the activation submission command are met, and then performs a firmware upgrade operation based on the firmware upgrade file, loading the firmware upgrade file to activate the new application corresponding to the firmware upgrade file.

[0135] In this embodiment, to prevent multiple slave control boards from switching to new applications at different times, this application embodiment submits an activation command so that multiple slave control boards wait locally until the activation conditions are met or reached before uniformly performing the firmware upgrade operation. In this way, multiple slave control boards activate the new application at the same time, avoiding the mixing of old and new versions of the application and improving upgrade security.

[0136] In one embodiment, the present application embodiment implements steps S3521 to S3523 to enable the reference board to perform a firmware upgrade operation based on the firmware upgrade file after receiving the submitted activation command.

[0137] Step S3521: The reference board parses the submitted activation command and extracts the activation trigger conditions.

[0138] Step S3522: When the response reaches the activation trigger condition, the reference board performs the upgrade pre-operation.

[0139] Step S3523: After the pre-upgrade operation is completed, the reference board loads the firmware upgrade file to jump to the application corresponding to the firmware upgrade file.

[0140] In this embodiment, the activation command submission includes activation trigger conditions (such as an activation timestamp, synchronization count value, or activation window number). For example, after receiving the activation command submission, the reference board parses the command and extracts the activation trigger conditions. When the activation trigger conditions are reached or met locally, the reference board performs upgrade pre-processing operations. These pre-processing operations include disabling SysTick (System Tick Timer), disabling and clearing interrupts, stopping communication peripherals or resetting peripheral states, resetting the main stack pointer (MSP), and relocating the interrupt vector table.

[0141] For example, after completing all pre-upgrade operations, the reference board loads the firmware upgrade file from the storage area to jump to the application corresponding to the firmware upgrade file, that is, to the new application entry point, and loads and launches the new application. After the new application starts successfully, the reference board sends an activation success flag to the main control board within a preset time to notify the main control board that the new application has been successfully activated.

[0142] In some embodiments, a submission activation command is sent to a reference board so that the reference board performs a firmware upgrade operation based on the firmware upgrade file after receiving the submission activation command. The firmware upgrade method for semiconductor devices provided in this application embodiment further includes step S353.

[0143] Step S353: In response to the presence of a reference identifier in the status bitmap and the failure to receive an activation success identifier transmitted by the reference board within a preset time, control the reference board to revert to the application corresponding to the previous version of the firmware upgrade file, or enter a safe waiting mode.

[0144] For example, this application embodiment monitors in real time whether an activation success flag transmitted by the reference board is received within a preset time. When a reference flag exists in the status bitmap and an activation success flag transmitted by the reference board is not received within the preset time, it indicates that after the reference board receives the activation submission command, it does not load the firmware upgrade file and perform the firmware upgrade operation according to the activation submission command, or it loads the firmware upgrade file and performs the firmware upgrade operation, but fails to successfully jump to activate the new application due to the influence of other factors (such as network, memory resources, controller failure, etc.). Therefore, no activation success flag is fed back to the main control board within the preset time. This application embodiment sends a version rollback command to the reference board, causing the reference board to roll back to the application corresponding to the previous version of the firmware upgrade file, that is, roll back to the old version of the application. Alternatively, this application embodiment sends a safety wait command to the reference board, causing the reference board to enter a safety wait mode, waiting for maintenance personnel or administrators to manually handle the upgrade failure. It is understood that engineers can customize the preset time based on experience data and experimental data, such as setting the preset time to 1s, 2s, or other any suitable time. This application embodiment does not make any specific limitation in this regard.

[0145] In this embodiment, by using the above method, it is ensured that even if a new application fails to jump to the control board after unified submission and activation during the firmware upgrade process, it will not cause the control board to fail. This effectively reduces the risk of control board failure and improves the security of control board upgrades.

[0146] In summary, the embodiments of this application utilize a state bitmap to monitor the stage status of each slave control board in real time and accurately. Thus, firmware upgrade files are transmitted to the slave control boards according to their stage status. The state bitmap is updated based on the received firmware upgrade files transmitted by the slave control boards. Based on the updated state bitmap, the slave control boards are controlled to perform firmware upgrade operations based on the firmware upgrade files. This efficiently and accurately upgrades the firmware of the slave control boards, improving firmware upgrade and maintenance efficiency, reducing or even avoiding firmware data loss or transmission errors, thereby ensuring the wafer etching effect.

[0147] This application provides a computer-readable storage medium storing processor-executable computer program instructions. When executed by a processor, the computer program instructions cause the processor to perform steps in any possible implementation of the firmware upgrade method for semiconductor devices provided in this application, or the firmware upgrade method for semiconductor devices provided in this application.

[0148] Those skilled in the art will understand that the embodiments provided in this application are merely illustrative. The order in which the steps in the methods of the embodiments are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The order can be adjusted, merged, and deleted according to actual needs. Modules or sub-modules, units or sub-units in the apparatus or system of the embodiments can be merged, divided, and deleted according to actual needs. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For another example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0149] Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, and of course, it can also be implemented using hardware. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. It should be understood that the storage medium can be flash memory, hard disk, optical disk, register, magnetic surface memory, removable disk, CD-ROM, random access memory (RAM), read-only memory (ROM), electrically programmable ROM, and electrically erasable programmable ROM, etc.

[0150] It should be noted that the above embodiments are for illustrating the technical concept and features of this application, and are intended to enable those skilled in the art to understand the content of this application and implement it accordingly. They should not be construed as limiting the scope of protection of this application. Those skilled in the art can understand that all or part of the processes of the above embodiments can be implemented, modified according to the technical solutions described in the embodiments of this application, or equivalent substitutions can be made to some of the technical features. It is understood that these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and should be considered as equivalent changes and modifications made based on the embodiments of this application, all of which should fall within the scope of the claims of this application.

Claims

1. A firmware upgrade method suitable for semiconductor devices, characterized in that, Applied to the main control board, the method includes: In response to a firmware upgrade task sent by the host computer, the firmware upgrade file is obtained and multiple slave control boards to be upgraded are identified based on the firmware upgrade task. Based on the stage state of the slave control board, a state bitmap is constructed. The state bitmap includes a state identifier that represents the stage state of the slave control board, and one state identifier corresponds to one slave control board. Based on the state bitmap, the firmware upgrade file is transmitted to the target board, where the target board is the slave control board corresponding to the target identifier in the state bitmap, and the target identifier is used to characterize the stage state of the slave control board as upgrade ready state; Based on the received result identifier transmitted by the target board, the status bitmap is updated to obtain an updated status bitmap, wherein the received result identifier represents the result of the target board receiving the firmware upgrade file; Based on the updated state bitmap, the control reference board performs a firmware upgrade operation based on the firmware upgrade file. The reference board is the slave control board corresponding to the reference identifier in the updated state bitmap. The reference identifier is used to characterize the stage state of the slave control board as the submission preparation state.

2. The firmware upgrade method for semiconductor devices according to claim 1, characterized in that, The step of transmitting the firmware upgrade file to the target board based on the state bitmap includes: In response to the state bitmap satisfying a first preset condition, the slave control board corresponding to the target identifier in the state bitmap is determined to be the target board. The first preset condition includes that all state identifiers in the state bitmap are the target identifiers, the ratio of the number of target identifiers to the number of state identifiers in the state bitmap is greater than or equal to a preset ratio and the failed boards among the multiple slave control boards are isolated, the state identifiers corresponding to the critical boards among the multiple slave control boards are the target identifiers, and the state identifiers corresponding to the active boards among the multiple slave control boards are any one of the target identifiers. The firmware upgrade file is divided into data packets to obtain multiple upgrade data packets; Multiple sets of window data are sequentially transmitted to the target board, and the window data includes at least one of the upgrade data packets.

3. The firmware upgrade method for semiconductor devices according to claim 2, characterized in that, The sequential transmission of multiple sets of window data to the target board includes: In response to the missing packet bitmap transmitted by the target board, the upgrade data packet corresponding to the missing packet identifier in the missing packet bitmap is retransmitted to the target board. One missing packet bitmap corresponds to a set of window data. The missing packet identifier is used to indicate that the target board has not successfully received the upgrade data packet. In response to the absence of the missing packet identifier in the missing packet bitmap, it is determined that the multiple sets of window data have been successfully transmitted to the target board.

4. The firmware upgrade method for semiconductor devices according to claim 3, characterized in that, The method further includes: In response to the fact that the number of retransmissions of the upgrade data packet corresponding to the missing packet identifier in the missing packet bitmap is greater than or equal to a preset retransmission number threshold, the target board is marked as the failed board.

5. The firmware upgrade method for semiconductor devices according to any one of claims 1 to 4, characterized in that, The step of updating the status bitmap based on the received result identifier transmitted by the target board to obtain the updated status bitmap includes: In response to the receiving result being identified as a first identifier, the target identifier in the status bitmap is updated to the reference identifier, where the first identifier indicates that the target board has successfully received the firmware upgrade file. In response to the receiving result being identified as the second identifier, the target identifier in the status bitmap is updated to the verification failure identifier. The second identifier indicates that the target board has not successfully received the firmware upgrade file, and the verification failure identifier indicates that the stage status of the slave control board is the verification failure state. In response to the fact that all target identifiers in the state bitmap have been updated, the updated state bitmap is obtained.

6. The firmware upgrade method for semiconductor devices according to any one of claims 1 to 4, characterized in that, The step of controlling the reference board to perform a firmware upgrade operation based on the firmware upgrade file, based on the updated state bitmap, includes: In response to the updated state bitmap satisfying a second preset condition, the slave control board corresponding to the reference identifier in the updated state bitmap is determined to be the reference board. The second preset condition includes that all state identifiers in the updated state bitmap are the reference identifiers, the ratio of the number of reference identifiers to the number of state identifiers in the updated state bitmap is greater than or equal to a preset ratio and the failed boards among the multiple slave control boards are isolated, the state identifiers corresponding to the critical boards among the multiple slave control boards are the reference identifiers, and the state identifiers corresponding to the active boards among the multiple slave control boards are any one of the reference identifiers. A submission activation command is sent to the reference board, so that the reference board performs a firmware upgrade operation based on the firmware upgrade file after receiving the submission activation command.

7. The firmware upgrade method for semiconductor devices according to claim 6, characterized in that, The activation submission command includes activation trigger conditions. After receiving the activation submission command, the reference board performs a firmware upgrade operation based on the firmware upgrade file, including: The reference board parses the submitted activation command and extracts the activation trigger conditions; Upon reaching the activation trigger condition, the reference board performs upgrade pre-operation. Upon completion of the pre-upgrade operation, the reference board loads the firmware upgrade file to jump to the application corresponding to the firmware upgrade file.

8. The firmware upgrade method for semiconductor devices according to claim 6, characterized in that, The method further includes sending an activation submission command to the reference board, so that the reference board performs a firmware upgrade operation based on the firmware upgrade file after receiving the activation submission command. In response to the presence of the reference identifier in the status bitmap and the failure to receive the activation success identifier transmitted by the reference board within a preset time, the reference board is controlled to revert to the application corresponding to the previous version of the firmware upgrade file, or enter a safe waiting mode.

9. A main control board, characterized in that, The device includes a processor and a memory, the memory being communicatively connected to the processor, the memory storing computer program instructions executable by the processor, the computer program instructions, when executed by the processor, causing the main control board to perform a firmware upgrade method applicable to semiconductor devices as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores processor-executable computer program instructions, which, when executed by the processor, cause the processor to perform a firmware upgrade method for a semiconductor device as described in any one of claims 1 to 8.

Images