Method and storage device for backing up firmware in the field by microcontroller

Abstract

This application provides a method and storage device for backing up firmware state via a microcontroller, relating to the field of integrated circuit design. The method is applied to a microcontroller connected to a control unit. The method includes: in response to identifying a control unit malfunction based on a running flag in shared memory, reading the firmware state from the shared memory and writing the firmware state to non-volatile memory; the shared memory is a storage space shared by the control unit and the microcontroller, and the firmware state in the shared memory represents the running state when the control unit malfunctions, wherein the running flag is updated by the control unit.

Description

Technical Field

[0001] This application relates to the field of integrated circuit design, and more particularly to a method and storage device for backing up firmware in the field using a microcontroller. Background Technology

[0002] Figure 1 A block diagram of a solid-state storage device (SSD) is shown. The SSD 102 is coupled to a host computer to provide storage capabilities. The host computer and the SSD 102 can be coupled in various ways, including but not limited to connections via SATA (Serial Advanced Technology Attachment), SCSI (Small Computer System Interface), SAS (Serial Attached SCSI), IDE (Integrated Drive Electronics), USB (Universal Serial Bus), PCIe (Peripheral Component Interconnect Express), NVMe (NVM Express), Ethernet, Fibre Channel, and wireless communication networks. The host computer can be an information processing device capable of communicating with the storage device via the above methods, such as a personal computer, tablet computer, server, laptop computer, network switch, router, cellular phone, or personal digital assistant. Solid-state storage device 102 (hereinafter referred to as storage device) includes interface 103, control unit 104, one or more NVM chips 105 and DRAM (Dynamic Random Access Memory) 110.

[0003] The aforementioned NVM chip 105 includes NAND flash memory, phase-change memory, FeRAM (Ferroelectric RAM), MRAM (Magnetic Random Access Memory), RRAM (Resistive Random Access Memory), etc., which are common storage media.

[0004] The aforementioned interface 103 can be adapted to exchange data with the host via methods such as SATA, IDE, USB, PCIe, NVMe, SAS, Ethernet, and Fibre Channel.

[0005] The aforementioned control unit 104 is used to control data transmission between interface 103, NVM chip 105, and DRAM 110, and is also used for memory management, host logical address to flash physical address mapping, erase leveling, bad block management, etc. Control unit 104 can be implemented in various ways, including software, hardware, firmware, or combinations thereof. For example, control unit 104 can be in the form of an FPGA (Field-programmable gate array), ASIC (Application Specific Integrated Circuit), or a combination thereof. Control unit 104 may also include a processor or controller, in which software is executed to manipulate the hardware of control unit 104 to process I / O (Input / Output) commands. Control unit 104 can also be coupled to DRAM 110 and can access data in DRAM 110. FTL tables and / or cached I / O command data can be stored in DRAM.

[0006] The control unit 104 includes a flash interface controller (or media interface controller, flash channel controller), which is coupled to the NVM chip 105 and issues commands to the NVM chip 105 in accordance with the interface protocol of the NVM chip 105 to operate the NVM chip 105, and receives the command execution results output from the NVM chip 105. Known NVM chip interface protocols include "Toggle", "ONFI", etc.

[0007] The host accesses storage device 102 using I / O commands that conform to the storage protocol. The control unit 104 generates one or more media interface commands based on the I / O commands from the host and provides them to the media interface controller. The media interface controller generates storage media access commands (e.g., programming commands, read commands, erase commands) that conform to the interface protocol of the NVM chip based on the media interface commands. The control unit also tracks the completion of all media interface commands generated from an I / O command and indicates the processing results of the I / O commands to the host.

[0008] In some implementation scenarios, storage devices require out-of-band management capabilities for diversified management. Out-of-band management needs to provide a second communication link, in addition to the storage device's main interface protocol, as well as a means of operating, monitoring, managing, and debugging the storage device. Out-of-band management requires interaction with the control unit using commands different from NVMe commands (sent by the host to the storage device through the host interface). These out-of-band management commands can be proprietary and defined and implemented by the control unit's vendor or user. The vendor or user can send these out-of-band management commands to the control unit via a host or peripheral device to instruct the control unit to perform specified operations, such as reading specified memory data, releasing NOR flash memory, resetting, or restarting. Optionally, out-of-band management functions may also include updating the firmware used by the control unit, collecting data from one or more sensors on the storage device, and saving the control unit's firmware runtime state in case of control unit malfunction.

[0009] Currently, a complete out-of-band management protocol, namely the NVMe-MI (Management Interface) protocol, has been defined based on the Multi-Channel Transmission Platform (MCTP). The NVMe-MI protocol defines a set of management interface commands similar to the NVMe command set. The NVMe-MI protocol reuses some pins of the host interface, and at the physical layer, it can use the I2C (Inter-Integrated Circuit) interface communication mode. While the I2C interface is simple and easy to use, some hosts or peripheral devices do not have an I2C interface, and implementing NVMe-MI is limited by relevant standards, making it inconvenient to implement out-of-band management functions. Summary of the Invention

[0010] The control unit includes one or more serial ports such as UART (Universal Asynchronous Receiver / Transmitter) interfaces. The control unit can receive out-of-band management commands through the UART interface and provide the command processing results. However, some host or peripheral devices do not have a UART interface or only have one UART interface, making it impossible or inconvenient to implement out-of-band management functions.

[0011] The USB (Universal Serial Bus) interface is a widely used interface for connecting peripheral devices; almost all host and peripheral devices have a USB interface.

[0012] In view of this, embodiments of this application aim to enable the host to manage the out-of-band management capabilities of the storage device by operating the serial port of the control unit through a single USB interface, eliminating the need for the host to have multiple serial ports (such as UART interfaces). A virtual serial port is implemented using the USB interface, allowing the host or peripheral devices to access the control unit through this virtual serial port, for example, sending commands for out-of-band management to the control unit, thereby achieving out-of-band management functionality. Furthermore, embodiments of this application also aim to utilize out-of-band management functionality through the physical layer interface provided by the NVMe-MI protocol in scenarios where the USB interface is unavailable. For example, the storage device may have been deployed in a data center, preventing the host from connecting to the storage device's USB interface.

[0013] Firmware context refers to various state information during the operation of the control unit. This mainly includes: register status, stack information, NVMe queue, memory management information, other processor status information, hardware accelerator status information, cache contents, inter-core communication queue, and inter-core shared memory. Obtaining firmware context helps analyze the operation of the control unit and the cause of failures. The system in this application acquires the firmware context when the control unit malfunctions via a microcontroller to facilitate fault analysis.

[0014] In a first aspect, embodiments of this application provide a method for processing the firmware context of a control component, applied to a microcontroller connected to the control component; the method includes:

[0015] In response to identifying an operational anomaly of the control unit based on the running flag in the shared memory, the firmware context in the shared memory is read and written to non-volatile memory; the shared memory is a storage space shared by the control unit and the microcontroller, the firmware context in the shared memory is the running context when the control unit is abnormal, and the running flag is updated by the control unit.

[0016] Optionally, the control component and the microcontroller are two independent chips.

[0017] Optionally, in response to identifying an abnormal operation of the control unit based on the running flags in the shared memory, it is further determined whether the microcontroller has acquired the firmware context in the shared memory;

[0018] In response to the microcontroller not acquiring the firmware context in the shared memory, the firmware context in the shared memory is read and written to the non-volatile memory.

[0019] Optionally, the method further includes: in response to identifying that the control unit is operating normally based on the running flag in the shared memory, further determining whether the microcontroller has acquired the firmware context in the shared memory; in response to the microcontroller having acquired the firmware context in the shared memory, acquiring the firmware context from the non-volatile memory and writing it into the shared memory.

[0020] Optionally, the method further includes: in response to the control unit having completed acquiring the firmware context in the shared memory, deleting the firmware context stored in the non-volatile memory.

[0021] Optionally, the method further includes: in response to the control unit having received the firmware context in the shared memory, setting the firmware context write-back flag in the shared memory to a first specified value; the firmware context write-back flag being the first specified value indicates that the control unit has experienced an anomaly, and the microcontroller has written the firmware context stored in the non-volatile memory back to the shared memory.

[0022] Optionally, the method further includes: in response to detecting that the firmware context write-back flag changes from the first specified value to the second specified value, identifying that the control unit has completed acquiring the firmware context in the shared memory, and updating the firmware context write-back flag from the second specified value to the third specified value.

[0023] Optionally, the method further includes: in response to identifying that the control unit is starting up based on the running flag, neither acquiring the firmware context in the shared memory nor writing the firmware context stored in the non-volatile memory back to the shared memory.

[0024] Optionally, the method further includes: determining that the control unit is starting up in response to the value of the running flag being a fourth specified value.

[0025] Optionally, the method further includes: identifying whether the control component is malfunctioning based on the changes in the running marker; wherein, if the increment of the value of the running marker relative to the value of the last read running marker is a specified value or within a specified range, the control component is identified as operating normally; otherwise, the control component is identified as malfunctioning.

[0026] Optionally, the method is executed cyclically.

[0027] Optionally, the control unit includes at least one UART interface, and the microcontroller includes a USB interface and at least one UART interface. The USB interface is used to connect to a host, and at least one UART interface of the control unit is coupled to at least one UART interface of the microcontroller. The microcontroller presents at least one virtual UART interface to the host using the USB interface.

[0028] Optionally, the method further includes: receiving a first access request sent by the host through accessing the virtual UART interface, the first access request indicating whether the microcontroller has obtained the firmware context in the shared memory; in response to receiving the first access request, querying whether the firmware context in the shared memory has been obtained, and sending the query result to the host through the virtual UART interface.

[0029] Optionally, the method further includes: receiving a second access request sent by the host through accessing the virtual UART interface, the second access request instructing the microcontroller to provide its stored firmware context to the control unit; and in response to receiving the second access request, sending the firmware context to the shared memory to provide the firmware context to the control unit.

[0030] Optionally, the method further includes: receiving a third access request sent by the host through the virtual UART interface, the third access request indicating whether the control unit has obtained the firmware context in the shared memory; and in response to receiving the third access request, sending the result of whether the control unit has obtained the firmware context in the shared memory to the host through the virtual UART interface.

[0031] Optionally, the method further includes: receiving a fourth access request sent by the host through the virtual UART interface, the fourth access request instructing the control unit to analyze the firmware context obtained from the shared memory; in response to receiving the fourth access request, sending the fourth access request to the control unit through the UART interface coupled to the control unit; and in response to receiving the analysis result sent by the control unit, sending the analysis result to the host through the virtual UART interface.

[0032] Optionally, the method further includes: receiving a power-down command sent by the host through accessing the virtual UART interface; in response to receiving the power-down command, cutting off the power supply to the control component; receiving a power-on command sent by the host through accessing the virtual UART interface; in response to receiving the power-on command, restoring the power supply to the control component; in response to identifying that the control component is operating normally based on the running flag in the shared memory, further determining whether the microcontroller has acquired the firmware context in the shared memory; in response to the microcontroller having acquired the firmware context in the shared memory, acquiring the firmware context from the non-volatile memory and writing it into the shared memory.

[0033] Optionally, the method further includes: the power-down command is issued by the host after the host receives the query result corresponding to the first access request through the virtual UART interface and the query result indicates that the microcontroller has obtained the firmware context in the shared memory.

[0034] Secondly, embodiments of this application provide a method for processing the firmware context of a control component, wherein the control component is connected to a shared memory and a microcontroller, and the shared memory is a storage space shared by the control component and the microcontroller, the method comprising:

[0035] When the control component is operating normally, the firmware of the control component is updated to the shared memory, and the running flag in the shared memory is updated periodically; the firmware contains various status information during the operation of the control component.

[0036] In the event of a malfunction in the control unit, the firmware context and the running flags in the shared memory cannot be updated.

[0037] Optionally, the method further includes: in response to startup completion, identifying whether it is necessary to read the firmware context in the shared memory; in response to identifying that it is not necessary to read the firmware context in the shared memory, updating the firmware context of the control unit during continuous operation to the shared memory; and in response to identifying that it is necessary to read the firmware context in the shared memory, reading the firmware context from the shared memory.

[0038] Optionally, the step of identifying whether it is necessary to read the firmware context in the shared memory in response to startup completion includes: reading the firmware context write-back flag in the shared memory in response to startup completion; identifying that it is necessary to read the firmware context in the shared memory in response to the value of the firmware context write-back flag being a first specified value; and identifying that it is not necessary to read the firmware context in the shared memory in response to the value of the firmware context write-back flag being a third specified value.

[0039] Optionally, the method further includes: in response to reading the firmware context from the shared memory, updating the value of the firmware context write-back marker from a first specified value to a second specified value.

[0040] Optionally, periodically updating the running flag in the shared memory includes periodically incrementing the value of the running flag in the shared memory.

[0041] Optionally: When the control unit is powered on, the running flag is set to a fourth specified value.

[0042] Thirdly, embodiments of this application provide a method for processing the firmware environment of an electronic device, the electronic device including a control component and a microcontroller, the method being applied to the microcontroller; the method includes:

[0043] The running flag in the shared memory is read, and the control unit is identified as operating normally based on the running flag; the running flag is updated by the control unit, and the shared memory is the storage space within the control unit that can be accessed by the microcontroller;

[0044] In response to the identification that the control component is operating normally based on the operation flag, it is determined whether there is firmware context in the microcontroller;

[0045] If a firmware context exists in the microcontroller, the firmware context is written into the shared memory to provide the firmware context to the control unit;

[0046] In response to the control unit completing the acquisition of the firmware context in the shared memory, the firmware context in the microcontroller is deleted.

[0047] Optionally, the method further includes: in response to the completion of writing the firmware context to the shared memory, setting the firmware context write-back flag in the shared memory to a first specified value; the firmware context write-back flag being the first specified value indicates that the control unit has experienced an anomaly, and the microcontroller has written the firmware context at the time of the anomaly to the shared memory.

[0048] Optionally, the method further includes: in response to detecting that the firmware context write-back flag changes from the first specified value to the second specified value, identifying that the control unit has completed acquiring the firmware context in the shared memory, and updating the firmware context write-back flag from the second specified value to the third specified value.

[0049] Optionally, the method further includes: in response to identifying an abnormal operation of the control unit based on the operation flag, reading the firmware context in the shared memory and writing the firmware context into the flash memory of the microcontroller.

[0050] Fourthly, embodiments of this application provide a method for processing the firmware field of an electronic device, the electronic device including a control unit and a microcontroller, the method comprising:

[0051] When the control unit is operating normally, it updates the firmware state to the shared memory and periodically updates the running flag in the shared memory; the firmware state contains various status information during the operation of the control unit.

[0052] In the event of a malfunction in the control unit, the control unit is unable to update the firmware context and the running flags in the shared memory;

[0053] The microcontroller reads the running flag from the shared memory and identifies whether the control unit is operating normally based on the running flag;

[0054] In response to identifying an operational anomaly in the control unit based on the running flags in the shared memory, the microcontroller reads the firmware context from the shared memory and writes the firmware context into the non-volatile memory.

[0055] Optionally, in response to identifying an operational anomaly in the control unit based on operational flags in the shared memory, the microcontroller reads the firmware context from the shared memory and writes the firmware context into non-volatile memory, including:

[0056] In response to identifying an abnormal operation of the control unit based on the running flags in the shared memory, the microcontroller determines whether it has acquired the firmware context in the shared memory;

[0057] In response to the microcontroller not acquiring the firmware context in the shared memory, the microcontroller reads the firmware context in the shared memory and writes the read firmware context into non-volatile memory.

[0058] Optionally, the method further includes: in response to identifying that the control unit is operating normally based on the running flag in the shared memory, further determining whether the microcontroller has acquired the firmware context in the shared memory; in response to the microcontroller having acquired the firmware context in the shared memory, acquiring the firmware context from the non-volatile memory and writing it into the shared memory.

[0059] Optionally, the method further includes: in response to the firmware context stored in the non-volatile memory being written back to the shared memory, the microcontroller deletes the firmware context stored in the non-volatile memory.

[0060] Optionally, the method further includes: in response to the firmware context stored in the non-volatile memory being written back to the shared memory, the microcontroller sets a firmware context write-back flag in the shared memory to a first specified value; the firmware context write-back flag being the first specified value indicates that the control unit has experienced an anomaly, and the microcontroller has written the firmware context stored in the non-volatile memory back to the shared memory; in response to startup completion, the control unit reads the firmware context write-back flag in the shared memory; in response to the value of the firmware context write-back flag being the first specified value, the control unit reads the firmware context in the shared memory.

[0061] Optionally, the method further includes: the control unit, in response to the value of the firmware context write-back flag being a third specified value, not reading the firmware context in the shared memory.

[0062] Optionally, the method further includes: the control unit updating the firmware context write-back flag from a first specified value to a second specified value in response to the completion of reading the firmware context from the shared memory; and the microcontroller, in response to detecting that the firmware context write-back flag has changed from the first specified value to the second specified value, recognizing that the control unit has completed reading the firmware context from the shared memory, updating the firmware context write-back flag from the second specified value to a third specified value.

[0063] Optionally, the method further includes: the control unit periodically incrementing the value of the running flag in the shared memory; and the microcontroller identifying whether the control unit is malfunctioning based on the changes in the running flag.

[0064] Optionally, the method further includes: when the control unit is powered on, setting the running flag to a fourth specified value; and in response to recognizing that the running flag is the fourth specified value, the microcontroller neither acquires the firmware context in the shared memory nor writes the firmware context stored in the non-volatile memory back to the shared memory.

[0065] Fifthly, embodiments of this application provide a storage device, including a control component and a microcontroller; the microcontroller includes a processor and a memory; the memory of the microcontroller stores a program, and when the processor of the microcontroller executes the program, it implements the method for processing the firmware environment of an electronic device provided in any embodiment of this application;

[0066] The control component includes a processor and a memory; the memory of the control component stores firmware, and when the processor of the control component executes the firmware, it implements the method for processing the firmware environment of the control component provided in any embodiment of this application. Attached Figure Description

[0067] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0068] Figure 1 This diagram illustrates the structure of a storage device in the prior art.

[0069] Figure 2 A schematic diagram of the structure of the storage device provided in an embodiment of this application is shown;

[0070] Figure 3 A schematic diagram illustrating the process by which a microcontroller, according to an embodiment of this application, processes a request from a host to access a virtual UART;

[0071] Figure 4A , Figure 4B and Figure 4C The following are schematic diagrams illustrating the process of a microcontroller sending data to a host via a virtual UART according to embodiments of this application;

[0072] Figure 5A , Figure 5B , Figure 5C and Figure 5D The following are schematic diagrams illustrating the structure of a storage device provided in one embodiment of this application;

[0073] Figure 6 This illustration shows a schematic diagram of the process of a host writing firmware to NOR flash memory according to an embodiment of this application;

[0074] Figure 7 A flowchart illustrating the process of a microcontroller identifying control of a DMA unit is shown.

[0075] Figure 8 This illustration shows a schematic diagram of the firmware processing flow of the control component during the operation of the storage device according to an embodiment of this application;

[0076] Figure 9 This illustration shows a schematic diagram of the firmware processing flow of the control component during the operation of the storage device according to an embodiment of this application;

[0077] Figure 10This diagram illustrates the process by which a user operates a microcontroller via a USB interface to analyze the firmware in the field. Detailed Implementation

[0078] 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 some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0079] Figure 2 A schematic diagram of the structure of a storage device provided in an embodiment of this application is shown. Figure 2 As shown, the storage device 200 includes an interface 201, a control unit 202, DRAM 203, multiple NVM chips 204, a microcontroller unit (MCU) 205, and NOR flash memory 206. Among them, Figure 2 The interface 201, control unit 202, DRAM 203, and multiple NVM chips 204 shown are... Figure 1 The embodiments shown have the same function, and will not be described again here to avoid repetition.

[0080] like Figure 2 As shown, the microcontroller 205 includes a USB interface, an I2C_0 interface, an I2C_1 interface, a UART_0 interface, and a UART_2 interface. The I2C_0 interface is coupled to the storage device interface 201. The I2C_1 interface is coupled to the control unit and the NOR flash memory. The UART_0 interface is connected to the serial port of the control unit, such as UART_A (…). Figure 2 (Not shown) Coupling. The UART_2 interface is coupled to the serial port of the control unit, such as UART_B (…). Figure 2 (Not shown) Coupling. The NOR flash memory is coupled to the control unit and the I2C_1 interface, respectively. In an optional embodiment, the I2C_0 and I2C_1 interfaces in the microcontroller can be replaced with SPI interfaces.

[0081] Optionally, the host accesses the storage device via a USB interface. If the host or peripheral device (such as a test device) has a USB interface, it can connect to the microcontroller's USB interface, thereby accessing the storage device via USB. The microcontroller uses this USB interface to implement a virtual serial port, such as a virtual UART interface, presented to the host or peripheral device. The host or peripheral device accesses the virtual UART interface through the USB interface to achieve out-of-band management of the storage device via USB. Figure 2As shown, the microcontroller uses the USB interface to implement virtual serial ports presented to the host or peripheral devices, including virtual UART_0, virtual UART_1, and virtual UART_2.

[0082] Optionally, the virtual UART provided by the microcontroller corresponds to the UART interface provided by the control unit. The host or peripheral device uses this correspondence to access the control unit's UART interface via the virtual UART. For example, virtual UART_0 corresponds to the microcontroller's UART_0 interface. In response to receiving an access request (e.g., an out-of-band management command) from the host or peripheral device via the USB interface to access virtual UART_0, the microcontroller forwards the request to the UART_0 interface via virtual UART_0. Since the UART_0 interface is coupled to the control unit's serial port (e.g., UART_A), the request is forwarded to the control unit's UART_A interface, allowing the host or peripheral device to access the control unit's UART_A interface via the USB interface through virtual UART_0. The microcontroller also sends data from the control unit to the host or peripheral device via virtual UART_0.

[0083] For example, virtual UART_2 corresponds to the microcontroller's UART_2 interface (the UART_2 interface is coupled to the control unit's serial port, such as UART_B). The host or peripheral device accesses the UART_2 interface via virtual UART_2, and subsequently accesses the control unit's UART_B interface. In response to receiving an access request for virtual UART_2 from the host or peripheral device via the USB interface, the microcontroller forwards the request to the UART_2 interface through virtual UART_2. Since the UART_2 interface is coupled to the control unit's serial port, such as UART_B, the request is forwarded to the control unit's UART_B interface via the UART_2 interface. The microcontroller also sends data from the control unit to the host or peripheral device via virtual UART_2.

[0084] Optionally, the host or peripheral device can send commands to the microcontroller for processing by accessing the virtual UART. For example, a command to access virtual UART_1 will be processed by the microcontroller itself. The host or peripheral device can access virtual UART_1 via a USB interface to send commands to the microcontroller for processing. In response to receiving a command sent by the host or peripheral device via the USB interface, if the command accesses virtual UART_1, the microcontroller processes the command itself without forwarding it to the control unit.

[0085] The host or peripheral device accesses the control unit's UART_A and / or UART_B interfaces via virtual UART_0 and / or virtual UART_2 through the USB interface, thereby enabling the host or peripheral device to access multiple UART interfaces of the control unit through a single USB interface. The host or peripheral device issues commands to be processed by the microcontroller by accessing virtual UART_1. As optional examples, commands processed by the microcontroller include, for example, powering on the control unit, powering off the control unit, writing firmware to NOR flash memory, and reading sensor data from the storage device.

[0086] Optional, such as Figure 2 As shown, the microcontroller provides three endpoints (denoted as Ep0, Ep1, and Ep2) in the ACM subclass of the CDC (Communication Device Class) of the USB interface to implement three virtual serial ports (virtual UART_0, virtual UART_1, and virtual UART_2) presented to the host or peripheral device. The host or peripheral device accesses the three virtual serial ports by accessing the three endpoints (Ep0, Ep1, and Ep2) of the USB interface. For example, the host or peripheral device accesses virtual UART_0 by accessing endpoint Ep0, virtual UART_1 by accessing endpoint Ep1, and virtual UART_2 by accessing endpoint Ep2. CDC is a USB subclass defined by the USB organization specifically for various communication devices (telecommunications devices and medium-speed network communication devices). ACM (Abstract Control Model) allows any communication device to provide a serial communication interface (e.g., a modem device that sends and receives AT commands). The microcontroller uses three endpoints provided by the USB interface to receive data from the host accessing the virtual serial port and to send data on behalf of the virtual serial port to the host to realize the function of the virtual serial port.

[0087] The microcontroller receives access requests from the host to virtual UART_0, virtual UART_1, and virtual UART_2 via USB endpoints (Ep0, Ep1, and Ep2). For each access request received from the host or peripheral device via the USB interface, the microcontroller identifies the UART interface accessed by the request based on the endpoint being accessed. In response to identifying Ep0 as the access request endpoint, the microcontroller determines that the access request accesses virtual UART_0. Virtual UART_0 corresponds to the microcontroller's UART_0 interface, which is coupled to the control unit's UART_A interface. Therefore, access requests to virtual UART_0 can be forwarded from the microcontroller's UART_0 interface to the control unit's UART_A interface. In response to identifying the endpoint of the access request as Ep2, the microcontroller determines that the access request accesses virtual UART_2. Virtual UART_2 corresponds to the microcontroller's UART_2 interface, which is coupled to the control unit's UART_B. Therefore, access requests to virtual UART_2 can be forwarded to the control unit's UART_B interface through the microcontroller's UART_2 interface. Conversely, in response to identifying the endpoint of the access request as Ep1, the microcontroller determines that the access request accesses itself. The microcontroller processes the access request itself without forwarding it to the control unit. After processing the access request, the microcontroller sends data representing the access request processing result to the host through endpoint Ep1, enabling the host to receive data from virtual UART_1.

[0088] The microcontroller also sends data from virtual UART_0, virtual UART_1, and virtual UART_2 to the host via USB endpoints (Ep0, Ep1, and Ep2). In response to receiving data from the controller's UART_A interface via UART_0, the microcontroller sends that data to the host via endpoint Ep0. Similarly, in response to receiving data from the controller's UART_B interface via UART_2, the microcontroller sends that data to the host via endpoint Ep2. From the host's perspective, it receives data from the controller's UART_A interface via endpoint Ep0 and data from the controller's UART_B interface via endpoint Ep2, enabling the host to access multiple UART interfaces of the controller via the microcontroller's USB interface.

[0089] like Figure 2As shown, the microcontroller also includes command pool 0, command pool 1, and command pool 2. Command pool 0 corresponds to virtual UART_0 and is used to cache access requests from the host or external device to virtual UART_0. Command pool 1 corresponds to virtual UART_1 and is used to cache access requests from the host or external device to virtual UART_1. Command pool 2 corresponds to virtual UART_2 and is used to cache access requests from the host or external device to virtual UART_2. Optionally, the microcontroller, based on the USB endpoint accessed by the access request, fills the data carried by the access request into command pool 0, command pool 1, and command pool 2 respectively. Still optional, command pool 0, command pool 1, and command pool 2 may be caches allocated in SRAM space, for example.

[0090] Optionally, the microcontroller sends data (such as access requests) from the command pool to the control unit's UART interface via its own UART interface. For example, the microcontroller sends data from command pool 0 to the control unit's UART_A via UART_0; the microcontroller sends data from command pool 2 to the control unit's UART_B via UART_2. Data from command pool 1 is processed by the microcontroller itself and is not sent to the control unit.

[0091] Figure 3 A schematic diagram illustrating the flow of a microcontroller processing a host's request to access a virtual UART, according to an embodiment of this application, is shown. Figure 3 As shown, the process by which the microcontroller handles a host's request to access the virtual UART includes:

[0092] Step S301: Receive the access request sent by the host through the USB interface (denoted as access request 1).

[0093] Step S302: Identify the USB endpoint accessed by Access Request 1. If the USB endpoint accessed by Access Request 1 is identified as Ep0, proceed to steps S303a-S304a. If the USB endpoint accessed by Access Request 1 is identified as Ep1, proceed to steps S303b-S304b. If the USB endpoint accessed by Access Request 1 is identified as Ep2, proceed to steps S303c-S304c.

[0094] Step S303a: Fill the data carried by access request 1 into command pool 0.

[0095] Step S304a: Send the data in command pool 0 to the control unit's UART_A via UART_0.

[0096] Step S303b: Fill the command pool 1 with the data carried by access request 1.

[0097] Step S304b: The microcontroller processes the data in command pool 1 itself without forwarding it to the control unit.

[0098] Step S303c: Fill the command pool 2 with the data carried by access request 1.

[0099] Step S304c: Send the data in command pool 2 to the control unit's UART_B via UART_2.

[0100] Figure 4A , Figure 4B and Figure 4C The following are schematic diagrams illustrating the process of a microcontroller sending data to a host via a virtual UART according to embodiments of this application.

[0101] like Figure 4A As shown, the process of the microcontroller sending data to the host through virtual UART_0 includes:

[0102] Step S401a: Receive data from the control unit (denoted as data 1) from the UART_0 interface.

[0103] Step S402a: Send data 1 to the host via the USB endpoint Ep0 corresponding to virtual UART_0.

[0104] like Figure 4B As shown, the process of the microcontroller sending data to the host via virtual UART_2 includes:

[0105] Step S401b: Receive data from the control unit (denoted as data 2) from the UART_2 interface.

[0106] Step S402b: Send data 2 to the host via the USB endpoint Ep2 corresponding to virtual UART_2.

[0107] like Figure 4C As shown, the process of the microcontroller sending data to the host through virtual UART_1 includes:

[0108] Step S401c: Obtain commands from the host from command pool 1.

[0109] Step S402c: Process the command automatically and obtain the processing result.

[0110] Step S403c: Send the processing result to the host via the USB endpoint Ep1 corresponding to the virtual UART_1.

[0111] Optionally, the host accesses the storage device via the NVMe-MI signal lines in interface 201. For example, in the event of a USB interface malfunction or the absence of a USB interface on the host, an access request can be sent to the control unit via the two NVMe-MI signal lines in interface 201, or it can be sent to the microcontroller via the same two signal lines. Therefore, when the host accesses the storage device, the access request can be processed by either the control unit or the microcontroller according to the NVMe-MI protocol.

[0112] like Figure 2 As shown, the microcontroller also includes an I2C_0 interface and an I2C_1 interface. The I2C_0 interface is coupled to the storage device's interface 201, for example, to the signal line in interface 201 used for NVMe-MI. The I2C_0 interface is used to receive commands issued by the host based on the NVMe-MI protocol, so as to implement out-of-band management functions through the I2C_0 interface in the event of a USB interface failure or the absence of a USB interface on the host.

[0113] For cases where the microprocessor processes access requests sent by the host via the two signal lines for NVMe-MI in interface 201, this embodiment provides out-of-band management extension commands, which are distinguished from commands conforming to the NVMe-MI protocol in terms of data format. The host instructs the microcontroller to process the data transmitted on the two signal lines for NVMe-MI via the out-of-band management extension command. Optionally, the out-of-band management extension command can indicate access to different virtual serial ports of the microcontroller (such as virtual UART_0, virtual UART_1, and virtual UART_2) by carrying different addresses or identifiers. The microcontroller distinguishes between virtual UART_0, virtual UART_1, and virtual UART_2 based on the address or identifier carried by the received out-of-band management extension command, and adds them to command pool 0, command pool 1, and command pool 2 respectively. For out-of-band management extension commands in command pool 0 or command pool 2, the microcontroller sends them to the UART_A or UART_B interface of the control unit via the UART_0 or UART_2 interface. Out-of-band management extension commands in command pool 1 are processed by the microcontroller's processor core. For data sent from the control unit to the host via the UART_A or UART_B interface, the microcontroller sends the data to the host via two signal lines coupled to the I2C_0 interface for NVMe-MI.

[0114] The I2C_1 interface is coupled to both the NOR flash memory and the I2C interface of the control unit. The microcontroller can interact with the control unit via the I2C_1 interface and can also write data to the NOR flash memory via the I2C_1 interface. The NOR flash memory can be used to store the firmware (the program that runs when the control unit is operating normally). The microcontroller writes firmware to the NOR flash memory via the I2C_1 interface. The control unit can read the firmware stored in the NOR flash memory via the I2C_1 interface.

[0115] Optionally, the host writes data (e.g., firmware for control components) to the NOR flash memory via the microcontroller. For example, the host sends an access request (referred to as access request 2) to virtual UART_1 via endpoint Ep1 of the USB interface, carrying data representing the firmware and an address for storing the firmware in the NOR flash memory. In response to recognizing that the USB endpoint accessed by access request 2 is Ep1, the microcontroller writes access request 2 to command pool 1. The microcontroller retrieves access request 2 from command pool 1 and executes it, writing the data representing the firmware carried in access request 2 to the specified address in the NOR flash memory via the I2C_1 interface. Optionally, if the data representing the firmware is large, the microcontroller may also use additional memory to cache the data representing the firmware.

[0116] The USB protocol has a handshake mechanism. After the sender sends a data packet to the receiver, the receiver needs to reply with a handshake packet to indicate the status of data transmission, such as whether data has been received or cannot be received.

[0117] Optionally, the microcontroller sends data (uplink data) to the host via I2C_0 using the two signal lines used for NVMe-MI. It is also necessary to prevent this data from being sent to the host via USB endpoints EP0, EP1, or EP2. This is because the microcontroller's USB interface is not properly connected to the host at this time; sending data via USB endpoints EP0, EP1, or EP2 will result in an error due to the inability to receive handshake packets.

[0118] Optionally, users can access virtual UART_0, virtual UART_1, and virtual UART_2 through software such as Console and Terminal on the host computer that access the UART interface.

[0119] In this embodiment, after the host sends a data packet to the microcontroller via the USB interface, the microcontroller replies with a handshake packet. After the microcontroller sends a data packet (e.g., the result of the microcontroller's processing of commands in command pool 1) to the host via the USB interface, a handshake packet is required from the host. However, the software on the host used to access the UART interface, such as the Console, may not be running or may have been closed by the user (the microcontroller cannot control the user's behavior when operating the Console and cannot inform the user to run the Console). In this case, the host cannot reply with a handshake packet, and the microcontroller malfunctions due to not receiving the handshake packet. Figure 2 In the illustrated embodiment, the microcontroller directly sends data from the UART_A or UART_B interface to the host. However, the microcontroller cannot control the behavior of the control unit, nor can it instruct the control unit not to send data through the UART_A or UART_B interface. The microcontroller also cannot control the host user's console operation, nor can it instruct the user to run the console. Therefore, if the host console is not running but the control unit is sending data through the UART_A or UART_B interface, the microcontroller will malfunction.

[0120] To address the aforementioned technical problems, embodiments of this application monitor the status (denoted as status 1) of virtual UART_0, virtual UART_1, and virtual UART_2 using a microcontroller, such as an enabled or disabled state. An enabled state indicates that the host has performed an enable operation on the virtual UART (and has not performed a disable operation afterward). A disabled state indicates that the host has performed a disable operation on the virtual UART (and has not performed an enable operation afterward).

[0121] Before the host accesses virtual UART_0 / virtual UART_1 / virtual UART_2 via USB interface endpoints Ep0 / Ep1 / Ep2, the operating system performs an "open" operation on virtual UART_0 / virtual UART_1 / virtual UART_2, putting them in an "enabled" state. Conversely, after the host finishes accessing virtual UART_0 / virtual UART_1 / virtual UART_2, it performs a "close" operation on them, putting them in a "closed" state.

[0122] The microcontroller monitors the data received from the host at the USB interface endpoints Ep0 / Ep1 / Ep2 to identify whether the host has performed an open or close operation on the virtual UART_0 / virtual UART_1 / virtual UART_2.

[0123] The microcontroller records the status of virtual UART_0 / virtual UART_1 / virtual UART_2 based on the operations performed by the host on virtual UART_0 / virtual UART_1 / virtual UART_2. In response to recognizing that the host performed an open operation on virtual UART_0 / virtual UART_1 / virtual UART_2 (and did not perform a close operation afterward), the microcontroller records status 1 of virtual UART_0 / virtual UART_1 / virtual UART_2 as "enabled". In response to recognizing that the host performed a close operation on virtual UART_0 / virtual UART_1 / virtual UART_2 (and did not perform an open operation afterward), the microcontroller records status 1 of virtual UART_0 / virtual UART_1 / virtual UART_2 as "disabled".

[0124] With virtual UART_0 / virtual UART_1 / virtual UART_2 enabled, the microcontroller opens the corresponding endpoints Ep0 / Ep1 / Ep2 of virtual UART_0 / virtual UART_1 / virtual UART_2, according to... Figure 3 , Figure 4A , Figure 4B and Figure 4C The illustrated embodiment works.

[0125] When the virtual UART is off, the microcontroller closes the endpoint corresponding to the virtual UART, and access to that endpoint is not processed. For example, if virtual UART_0 is off, even if the control unit sends data through the UART_A interface and the UART_0 interface receives the data, the microcontroller will not process the data received from the UART_0 interface and will discard it because the endpoint Ep0 corresponding to virtual UART_0 is off. Therefore, no data packets will be generated from endpoint Ep0 to the host, and the microcontroller will not malfunction due to the host not providing a handshake packet. Similarly, if the host sends data to endpoint Ep0, the microcontroller will not process the data, or the microcontroller will indicate to the host that Ep0 cannot currently process it by returning a handshake packet.

[0126] In an optional embodiment, a DMA unit is added to the microcontroller to improve data transfer performance. For example, the DMA unit is coupled to the USB interface in the microcontroller. Data received by the microcontroller from the UART_0 and / or UART_2 interfaces (uplink data, data sent from the microcontroller to the host) is directly sent to the host via the USB interface through the DMA unit, thus eliminating the need for the processor core in the microcontroller to participate in the data transfer process to the host. The DMA unit processes the data received from the microcontroller's UART_0 and / or UART_2 interfaces (data sent from the microcontroller to the host), but does not process data sent from the host to the control unit via the USB interface, such as data sent from the host to the control unit's UART_A and / or UART_B interfaces.

[0127] Figure 5A A schematic diagram of the structure of a storage device according to an embodiment of this application is shown. Figure 5A As shown, in Figure 2 Based on the storage device shown, this embodiment adds a DMA unit to the microcontroller of the storage device. The DMA unit corresponds to the UART_2 interface and is used to directly send data in command pool 2 (data received by the microcontroller from the UART_2 interface) to the host via the USB interface, thereby eliminating the need for the processor core in the microcontroller to participate in the data transfer process to the host.

[0128] In an optional embodiment, the DMA unit can correspond to the UART_1 interface, used to directly send data from command pool 0 (data received by the microcontroller from the UART_0 interface) to the host via the USB interface, thus eliminating the need for the processor core in the microcontroller to participate in the data transfer process to the host. Alternatively, the microcontroller can provide DMA units corresponding to the UART_1 and UART_2 interfaces respectively, to directly send data from command pool 0 and command pool 2 to the host via the USB interface, enabling the use of corresponding DMA units to transfer data to the host for the UART_1 and UART_2 interfaces respectively.

[0129] Figure 5B A schematic diagram of the structure of a storage device according to another embodiment of this application is shown. Figure 5B As shown, the DMA unit provided in this embodiment is coupled to the I2C_1 interface. When the host writes data (such as firmware data) to the NOR flash memory through the I2C1 interface, the DMA unit performs the data transfer to the NOR flash memory, thereby improving the data writing rate to the NOR flash memory.

[0130] Figure 5C A schematic diagram of the structure of a storage device according to another embodiment of this application is shown. Figure 5CAs shown, in this embodiment, the UART_2 interface and the I2C_1 interface share a DMA unit. This DMA unit can directly send data from command pool 2 (data received by the microcontroller from the UART_2 interface) to the host via the USB interface, and can also move data written by the host to the NOR flash memory via the I2C_ interface (such as data representing firmware).

[0131] Figure 5D A schematic diagram of the structure of a storage device according to another embodiment of this application is shown. Figure 5D As shown, in this embodiment, the microcontroller includes two DMA units, namely DMA unit 1 and DMA unit 2. DMA unit 1 corresponds to the UART_1 interface and is used to directly send data in command pool 0 (data received by the microcontroller from the UART_0 interface) to the host via the USB interface, thus eliminating the need for the processor core in the microcontroller to participate in the data transfer process to the host. The UART_2 interface shares a DMA unit 2 with the I2C_1 interface. This DMA unit can directly send data in command pool 2 (data received by the microcontroller from the UART_2 interface) to the host via the USB interface, and can also transfer data written by the host to the NOR flash memory via the I2C_ interface (such as data representing firmware).

[0132] refer to Figure 5C and Figure 5D Since both the UART_2 interface and the I2C_1 interface are coupled to the DMA unit, the microcontroller needs to resolve the conflict in the use of the DMA unit to prevent the UART_2 interface and the I2C_1 interface from using the DMA unit to move data at the same time.

[0133] Because firmware itself is large (e.g., several MB), and incomplete firmware writing will cause the control unit to malfunction, writing firmware to NOR flash memory is an important and time-consuming operation. For example, the I2C_1 interface has a higher priority for occupying the DMA unit than the UART_2 interface. When the I2C_1 interface occupies the DMA unit, preemption of the UART_2 interface is prevented. When the UART_2 interface occupies the DMA unit, if writing to NOR flash memory is needed, the UART_2 interface's control over the DMA unit is revoked, and the I2C_1 interface takes over the DMA unit. However, for microcontrollers, the states of "I2C_1 interface occupying the DMA unit" and "UART_2 interface occupying the DMA unit" are difficult to distinguish. Furthermore, in this embodiment, the I2C_1 interface, NOR flash memory, and control unit are connected via an I2C bus, and the control unit occupies the NOR flash memory for extended periods to run the firmware, meaning the I2C_1 interface only needs to transfer data to the NOR flash memory a very limited number of times. In this situation, the microcontroller's frequent detection of I2C_1 interface usage of DMA units will also lead to a waste of microcontroller processor core performance.

[0134] In view of this, embodiments of this application use a host to access the virtual UART_1 command to assist the microcontroller in identifying the occupancy of the DMA unit by the I2C_1 interface.

[0135] Figure 6 This illustration shows a schematic diagram of the process of a host writing firmware to NOR flash memory according to an embodiment of this application. Figure 6 As shown, the process of the host writing firmware to NOR flash memory includes:

[0136] Step S601: The host sends a command (referred to as command 1) to the microcontroller's virtual UART_1 via endpoint Ep1 of the USB interface, instructing the control unit to power down. For command 1, the microcontroller cuts off the power supply to the control unit. Since the power supply to the control unit is cut off, the control unit no longer occupies the NOR flash memory, allowing the I2C_1 interface to access the NOR flash memory. The microcontroller also assigns control of the DMA unit to the I2C_1 interface, which then occupies the DMA unit.

[0137] Optionally, the microcontroller records the state of the I2C_1 interface, such as whether it is occupied or released. When the I2C_1 interface is in the occupied state, it indicates that the I2C_1 interface is using the DMA unit; when the I2C_1 interface is in the released state, it indicates that the I2C_1 interface is not using the DMA unit. Similarly, the microcontroller records the state of UART_2 (denoted as state 2), such as whether it is occupied or released (different from the previously mentioned enabled or disabled states of virtual UART_2). When UART_2 is in the occupied state, it indicates that the UART_2 interface is using the DMA unit, and the host is interacting with virtual UART_2; when UART_2 is in the released state, it indicates that the UART_2 interface is not using the DMA unit, and the host is not interacting with virtual UART_2.

[0138] Step S602: The host sends a command (referred to as command 2) to the virtual UART_1 via endpoint Ep1 of the USB interface, instructing the firmware to be written to the NOR flash memory. For command 2, the microcontroller's DMA unit writes the data representing the firmware to the NOR flash memory via the I2C_1 interface. At this time, the microcontroller must ensure that the I2C_1 interface has control of the DMA unit.

[0139] Step S603: The host sends a command (referred to as command 3) to the virtual UART_1 via endpoint Ep1 of the USB interface to instruct the control unit to power on. For command 3, the microcontroller restores power to the control unit, releases control of the DMA unit by the I2C_1 interface, and sets the state of the I2C_1 interface to released.

[0140] Figure 7 A flowchart illustrating the process by which a microcontroller identifies control of a DMA unit is shown. Figure 7 As shown, the process by which the microcontroller identifies control of the DMA unit includes:

[0141] Step S701: The microcontroller receives and recognizes the command (referred to as command 4) sent by the host through the USB interface.

[0142] Step S702a: If it is recognized that the command 4 accesses the endpoint Ep1 of the USB interface, and the command 4 is a command that instructs the control unit to power down (i.e., command 1), the microcontroller cuts off the power supply to the control unit.

[0143] Step S703a: Set the control of the DMA unit to the I2C_1 interface, and the I2C_1 interface occupies the DMA unit.

[0144] Step S704a: Set the state of the I2C_1 interface to occupied.

[0145] Step S705a: Determine whether the state 2 of the UART_2 interface is occupied.

[0146] Step S706a: If the state 2 of the UART_2 interface is occupied, it indicates that the host is currently interacting with the storage device through the virtual UART_2. Communication with the host is temporarily stopped, the endpoint Ep2 corresponding to the virtual UART_2 is closed, the state 1 of the virtual UART_2 is recorded as closed, and the state 2 of the UART_2 interface remains unchanged (the state 2 of the UART_2 interface is still occupied). Maintaining the state 2 of the UART_2 interface unchanged means that the UART_2 has the ability to continuously receive logs from the control unit. Since the UART_2 interface remains in the occupied DMA unit state, after the control unit is powered on, the UART_2 interface continuously receives log data from the control unit, and there is continuous output data on the virtual UART_2 corresponding to the UART_2 interface. Therefore, when the microcontroller opens the endpoint Ep2, it can continue to interact with the host, and the data on the virtual UART_2 can also be received by the host, preventing the user from experiencing an unexpected interruption of communication with the virtual UART_2.

[0147] Step S702b: If it is identified that command 4 accesses the endpoint Ep1 of the USB interface, and command 4 is a command (i.e. command 2) that indicates writing firmware to NOR flash memory.

[0148] Step S703b: The DMA unit writes data representing the firmware to the NOR flash memory via the I2C_1 interface.

[0149] Step S702c: Identify that the endpoint Ep1 of the USB interface is accessed by command 4, and that command 4 is a command that instructs the control unit to be powered on (i.e., command 3), and restore power supply to the control unit.

[0150] Step S703c: Release the DMA unit via the I2C_1 interface.

[0151] Step S704c: Set the state of the I2C_1 interface to released.

[0152] Step S705c: Determine whether the state 2 of the UART_2 interface is occupied.

[0153] Step S706c: If the state 2 of the UART_2 interface is occupied, it indicates that the previous firmware writing operation to the NOR interrupted the ongoing communication on the UART_2 interface. The microcontroller enables endpoint Ep2, records the state 1 of the virtual UART_2 as enabled, and makes the UART_2 interface occupy the DMA unit to resume communication with the host.

[0154] Step S702d: The endpoint Ep1 of the USB interface is identified as being accessed by command 4, and command 4 indicates that virtual UART_2 is enabled.

[0155] Step S703d: Identify the status of the I2C_1 interface.

[0156] Step S704d: If the I2C_1 interface is in an occupied state, it means that the process of writing firmware to the NOR flash memory may not have been completed yet. Accordingly, the command to open virtual UART_2 is refused, endpoint Ep2 is not enabled, and the state 1 of virtual UART_2 and the state 2 of UART_2 interface are not changed.

[0157] Step S705d: If the state of the I2C_1 interface is released, it means that the firmware writing to the NOR flash memory has been completed. At this time, execute the command to open the virtual UART_2: enable endpoint Ep2, record the state 1 of the virtual UART_2 as open, and the state 2 of the UART_2 interface as occupied.

[0158] Step S702e: The endpoint Ep1 of the USB interface accessed by command 4 is identified, and command 4 indicates that virtual UART_2 is turned off.

[0159] Step S703e: Close endpoint Ep2, record the state 1 of virtual UART_2 as closed and the state 2 of UART_2 interface as released, so that UART_2 interface releases DMA unit.

[0160] refer to Figure 6 and Figure 7 As shown in the flowchart, this embodiment of the application controls the DMA unit usage of the I2C_1 and UART_2 interfaces by controlling the host's access to the virtual UART_1 command. When the I2C_1 interface occupies the DMA unit, it prevents the UART_2 interface from preempting the DMA unit, thus avoiding interrupting the firmware writing process to the NOR flash memory and ensuring that the firmware can be completely written to the NOR flash memory.

[0161] In optional embodiments, abnormalities may occur during the operation of the control unit. To analyze the cause of these abnormalities, it is necessary to save the operating state of the control unit (hereinafter referred to as the firmware state) when an abnormality occurs. Obtaining the firmware state helps in analyzing the operation of the control unit and the cause of failures. The firmware state refers to various state information during the operation of the control unit, mainly including: memory information, register states, stack information, NVMe queue, memory management information, other processor state information, hardware accelerator state information, cache contents, inter-core communication queue, inter-core shared memory, etc. Memory information reflects the memory usage of the firmware, including the stack, code segment, data segment, and heap. Register states include the values ​​of the processor core's architecture registers, such as the program pointer and stack pointer. Stack information includes the stack pointer and function call stack information, which helps in locating the function call chain at the time of firmware crash. Memory management information involves the program's memory allocation and usage, which helps in checking for problems such as memory leaks.

[0162] A portion of the control unit's storage space is accessible to the microcontroller. The control unit saves the firmware state to this microcontroller-accessible storage space so that the microcontroller can retrieve the firmware state. For example, the microcontroller-accessible storage space may be mapped to an SPI bus, and the microcontroller accesses this storage space via the SPI bus to retrieve the firmware state. Alternatively, the microcontroller-accessible storage space may be implemented using shared memory (e.g., NOR flash memory providing the shared memory space), and the microcontroller accesses this storage space via shared memory. Optionally, the microcontroller includes flash memory. The firmware state retrieved by the microcontroller is stored in flash memory.

[0163] When using storage devices, microcontrollers have two ways to obtain firmware context: (1) During the operation of the control unit, some firmware contexts are updated in real time. These contexts are located in an address space that can be accessed by the microcontroller (e.g., via SPI bus or shared memory). The microcontroller reads the current memory context of the control unit from these address spaces. (2) After the control unit malfunctions, the control unit exports some firmware contexts to an address space that the microcontroller can access. Method (1) is simpler, but the firmware context obtained by the microcontroller may not be closely related to the malfunction of the control unit, thus affecting the effectiveness of subsequent analysis of the cause of the fault using the firmware context. Method (2) can selectively export firmware contexts related to the fault of the control unit, which helps in subsequent analysis of the cause of the fault. However, when the control unit malfunctions, its function of exporting firmware contexts may also fail, thus making it impossible to export the firmware contexts.

[0164] In an optional embodiment, taking the microcontroller obtaining the firmware context from shared memory as an example, in addition to recording the firmware context, the shared memory also records the running flag and the firmware context write-back flag.

[0165] The operation markers are maintained by the control unit. The operating status of the control unit is indicated by the operation markers or their changes. For example, if the changes in the operation markers conform to a specified pattern, it indicates that the control unit is operating normally. If the changes in the operation markers do not conform to the specified pattern, it indicates that the control unit is operating abnormally.

[0166] Optionally, when the control unit starts up, it sets the run flag to a specified value. The microcontroller reads this specified value and knows that the control unit is starting up; at this time, the microcontroller does not need to perform any additional processing. After the control unit completes startup, it updates the run flag according to a preset update rule. Optionally, the control unit updates the run flag to the current timestamp, or controls the run flag to increment automatically. Again, optionally, the control unit can update the run flag periodically, updating it at certain time intervals. A normal update of the run flag indicates that the control unit is working normally. During normal operation of the control unit, the firmware is updated continuously. The firmware content is extensive; optionally, the control unit writes a portion of the firmware data to shared memory. Optionally, the portion of the firmware located in shared memory has a specified size, such as 4KB. Optionally, the control unit also sets an address in shared memory to indicate the location and / or size of the firmware in shared memory.

[0167] The microcontroller periodically reads the operation flag and identifies whether the control unit is functioning correctly based on whether the changes in the operation flag follow a pattern. When a control unit malfunctions and cannot function properly, it cannot update the operation flag. The microcontroller detects that the operation flag has not been updated correctly, determines that the control unit is malfunctioning, and retrieves the firmware context from the shared controller.

[0168] The firmware write-back flag is maintained by the microcontroller. This flag indicates whether the microcontroller has written firmware to shared memory, and further indicates whether the control unit has failed. For example, a firmware write-back flag of the specified value 'x' indicates that the microcontroller has written the firmware it acquired to shared memory (which the control unit now needs to read), and further indicates that the control unit has failed. A firmware write-back flag of the specified value 'y' indicates that the microcontroller has not written firmware to shared memory, and further indicates that the control unit has not failed, the firmware in shared memory has been updated by the control unit, or that the control unit has successfully read the firmware written by the microcontroller from shared memory, and the control unit can update the firmware in shared memory (see reference). Figure 9(See step S909). After each startup, the control unit checks the firmware field write-back flag and performs corresponding processing based on the value of the firmware field write-back flag.

[0169] Figure 8 This illustration shows a schematic diagram of the firmware processing flow of the control unit during the operation of the storage device according to an embodiment of this application. Figure 8 As shown, the firmware on-site processing flow of the control unit during storage device operation includes:

[0170] Step S801: In response to the start of the control unit, the control unit sets the running flag to the specified value w. The running flag being set to the specified value w indicates that the control unit is starting up. After the control unit has finished starting up, steps S802-1 and S802-2 are executed.

[0171] After the control unit starts up, it needs to identify whether any abnormalities have occurred previously. If no abnormalities have occurred, the control unit can operate normally and update the firmware state to the shared memory, as well as update the running flag according to preset update rules. If the control unit has experienced an abnormality and restarted after the abnormality, the control unit not only needs to read the firmware state written by the microcontroller at the time of the abnormality from the shared memory, but also needs to update the running flag according to preset update rules (the process of the control unit reading the firmware state from the shared memory is the process of normal operation of the control unit, and the running flag needs to be updated so that the microcontroller can recognize that the control unit is operating normally).

[0172] Step S802-1: Read the firmware field write-back flag in the shared memory.

[0173] Step S803: Determine the firmware write-back flag.

[0174] Step S804a: If the firmware write-back flag is the specified value y, and the control unit has not experienced any abnormalities before (e.g., no abnormalities occurred during the last control unit startup), this startup is a normal startup rather than a restart after an abnormality. The firmware can be updated at any time during the operation of the control unit. The control unit writes all or part of the firmware data to the shared memory.

[0175] Step S804b: If the firmware context is written back with the specified value x, it indicates that a previous anomaly occurred in the control unit. For example, an anomaly occurred during the last startup of the control unit, and this startup is a restart after the anomaly. The control unit reads the firmware context written by the microcontroller at the time of the control unit anomaly from the shared memory to analyze the previous fault based on the firmware context.

[0176] Step S805: In response to the completion of firmware context reading, the control unit sets the firmware context write-back flag from x to the specified z to inform the microcontroller that it has obtained the firmware context in the shared memory.

[0177] During operation after startup, the control unit may run normally continuously or may malfunction. If the control unit runs normally continuously, steps S802-2 and 805b will be executed; if the control unit malfunctions during operation, step S807 will be executed.

[0178] Step S802-2: The control unit determines whether to update the running flag. For example, the control unit determines whether the time interval for updating the running flag has been reached. If the time interval for updating the running flag has been reached, step S806 is executed. If the time interval for updating the running flag has not been reached, the running flag is not updated.

[0179] Step S805b: Update the run flag.

[0180] Step S807: A control unit malfunctions. When a control unit malfunctions, it will not perform the operation to update the running flag (steps S802-2 and 805b will not be executed).

[0181] Figure 9 This illustration shows a schematic diagram of the firmware processing flow of the control unit during the operation of the storage device according to an embodiment of this application. Figure 9 As shown, after the microcontroller starts up, it periodically processes the firmware context (periodically executing steps S901 to S909 below). The microcontroller's firmware context processing flow includes:

[0182] Step S901: Periodically read the running flags in the shared memory.

[0183] Step S902: Determine whether the control component is operating normally based on the change in the operation flag. If an abnormal operation of the control component is detected, proceed to step S903. If the control component is detected to be operating normally, proceed to step S905.

[0184] Step S903: Determine whether the firmware context has been obtained from the shared memory. If yes, return to step S902. If no, proceed to step S904. If the microcontroller continuously executes steps S902 and S903, it indicates that the control unit is currently in an abnormal operating state and has already obtained the current firmware context.

[0185] Step S904: Obtain the firmware context from the shared controller and write the obtained firmware context to the flash memory. After step S904 is completed, return to step S902.

[0186] Step S905: If the control unit is found to be operating normally, determine whether the firmware context has been obtained from the shared memory (determine whether the firmware context exists in the flash memory). If not, it means that the control unit did not experience any abnormalities before, and return to step S902 to continue monitoring whether the control unit is working normally. If yes, it means that the control unit previously experienced an abnormality, has now recovered to normal, and the control unit has not yet obtained the firmware context from the time of the previous abnormality, then execute steps S906-S907 to provide the control unit with the firmware context from the time of the previous abnormality. It should be understood that the control unit in this embodiment has the ability to restart; for example, if the control unit experiences an abnormality, the control unit can be restarted through user intervention. For example, the user can send a power-down command to the virtual URAT_1 through the host to control the control unit to power down, and then send a power-on command to the virtual URAT_1 through the host to control the control unit to power on. The control unit restarts by powering down and then powering on, thereby realizing the change of the control unit from abnormal to normal.

[0187] Step S906: Obtain the backup firmware context from the flash memory. It should be understood that this firmware context is the firmware context stored in step S903 when the control component malfunctions.

[0188] Step S907: Write the backed-up firmware context to the shared memory to provide the firmware context when the control unit malfunctions to the control unit. Set the firmware context write-back flag to a specified value x. The firmware context write-back flag being set to a specified value x indicates that there is a firmware context in the shared memory that needs to be read by the control unit (this firmware context is the firmware context when the control unit malfunctions, stored in step S903).

[0189] Step S908: Determine whether the control unit has acquired the firmware context from the shared memory. If yes, proceed to step S909. If no, proceed to step S908 until it is determined that the control unit has successfully acquired the firmware context from the shared memory.

[0190] For example, the value of the firmware write-back flag is used to determine whether the control unit has acquired the firmware context in the shared memory. If the firmware write-back flag is a specified value z (set in step S805c), it indicates that the control unit has completed acquiring the firmware context in the shared memory (such as the firmware context when the control unit malfunctions). If the firmware write-back flag is a specified value x, it indicates that the control unit has not yet completed acquiring the firmware context in the shared memory.

[0191] Step S909: Erase the firmware context backed up in the flash memory. Set the firmware context write-back flag to the specified value y. Setting the firmware context write-back flag to the specified value y instructs the control unit to update the firmware context in the shared memory.

[0192] In an optional embodiment, the user can operate the microcontroller via a USB interface to analyze the firmware in the field. For example... Figure 10 As shown, the process for users to operate the microcontroller via the USB interface to analyze the firmware in the field includes:

[0193] Step S1001: By accessing endpoint Ep1 of the USB interface, a command (denoted as command 5) is sent to virtual UART_1 to query whether the microcontroller has backed up the firmware context. The microcontroller receives command 5 and recognizes that the endpoint accessed by command 5 is Ep1, and that it is a command used to query whether the microcontroller has backed up the firmware context. The microcontroller queries whether the firmware context exists in the flash memory. If it exists, proceed to step S1002. If it does not exist, proceed to step S1005.

[0194] Step S1002: Send a control unit power-down command (denoted as command 6) to virtual UART_1 by accessing endpoint Ep1 of the USB interface. (See reference) Figure 7 In steps S702a-S706a, the microcontroller receives command 6 and identifies the endpoint accessed by command 6 as Ep1, which is a command used to instruct the control unit to power down. The microcontroller cuts off the power supply to the control unit, assigns control of the DMA unit to the I2C_1 interface, and the I2C_1 interface occupies the DMA unit. Furthermore, the state of the I2C_1 interface is set to occupied. The microcontroller writes a backup firmware context to the shared memory through the I2C_1 interface.

[0195] Step S1003: Send a power-on command (referred to as command 7) to the virtual UART_1 by accessing the endpoint Ep1 of the USB interface.

[0196] Step S1004: By accessing the endpoint Ep0 of the USB interface, send a command to the virtual UART_0 to query whether the control unit has obtained the firmware context in the shared memory (denoted as command 9). If yes, proceed to step S1005; otherwise, proceed to steps S1002-S1003 to write the firmware context to the shared memory.

[0197] Step S1005: By accessing the endpoint Ep0 of the USB interface, an instruction is sent to the virtual UART_0. The control unit uses the acquired firmware to perform on-site fault analysis.

[0198] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application. Clearly, those skilled in the art can make various alterations and variations to this application without departing from its spirit and scope. Thus, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method of handling a field of firmware of a control component, characterized in that, The method is applied to a microcontroller, wherein the microcontroller is connected to the control component; the method includes: In response to identifying an operational anomaly of the control unit based on the running flag in the shared memory, the firmware context in the shared memory is read and written to non-volatile memory; the shared memory is a storage space shared by the control unit and the microcontroller, the firmware context in the shared memory is the running context when the control unit is abnormal, and the running flag is updated by the control unit.

2. The method according to claim 1, characterized in that, In response to identifying an abnormal operation of the control unit based on the running flags in the shared memory, it is further determined whether the microcontroller has acquired the firmware context in the shared memory; In response to the microcontroller not acquiring the firmware context in the shared memory, the firmware context in the shared memory is read and written to the non-volatile memory.

3. The method according to claim 1 or 2, characterized in that, The method further includes: In response to identifying that the control unit is operating normally based on the running flags in the shared memory, it is further determined whether the microcontroller has acquired the firmware context in the shared memory; In response to the microcontroller having acquired the firmware context in the shared memory, the firmware context is acquired from the non-volatile memory and written to the shared memory.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: In response to the detection that the control unit is starting up based on the running flag, neither the firmware context in the shared memory is acquired nor the firmware context stored in the non-volatile memory is written back to the shared memory.

5. The method according to any one of claims 1 to 4, characterized in that, The control unit includes at least one UART interface, and the microcontroller includes a USB interface and at least one UART interface. The USB interface is used to connect to a host computer, and at least one UART interface of the control unit is coupled to at least one UART interface of the microcontroller. The microcontroller presents at least one virtual UART interface to the host computer using the USB interface.

6. The method of claim 5, wherein, The method further includes: Receive the power-down command sent by the host through accessing the virtual UART interface; In response to receiving the power-down command, the power supply to the control component is cut off; Receive the power-on command sent by the host through accessing the virtual UART interface; In response to receiving the power-on command, power supply to the control component is restored; In response to identifying that the control unit is operating normally based on the running flags in the shared memory, it is further determined whether the microcontroller has acquired the firmware context in the shared memory; In response to the microcontroller having acquired the firmware context in the shared memory, the firmware context is acquired from the non-volatile memory and written to the shared memory.

7. A method of handling a field of firmware of a control component, characterized in that, The control unit is connected to a shared memory and a microcontroller, the shared memory being a storage space shared by the control unit and the microcontroller, and the method includes: When the control component is operating normally, the firmware of the control component is updated to the shared memory, and the running flag in the shared memory is updated periodically; the firmware contains various status information during the operation of the control component. In the event of a malfunction in the control unit, the firmware context and the running flags in the shared memory cannot be updated.

8. A method of handling a firmware field of an electronic device, characterized by, The electronic device includes a control component and a microcontroller, and the method is applied to the microcontroller; the method includes: The running flag in the shared memory is read, and the control unit is identified as operating normally based on the running flag; the running flag is updated by the control unit, and the shared memory is the storage space within the control unit that can be accessed by the microcontroller; In response to the identification that the control component is operating normally based on the operation flag, it is determined whether there is firmware context in the microcontroller; If a firmware context exists in the microcontroller, the firmware context is written into the shared memory to provide the firmware context to the control unit; In response to the control unit completing the acquisition of the firmware context in the shared memory, the firmware context in the microcontroller is deleted.

9. A method of handling a firmware field of an electronic device, the method comprising: The electronic device includes a control component and a microcontroller, and the method includes: When the control unit is operating normally, it updates the firmware state to the shared memory and periodically updates the running flag in the shared memory; the firmware state contains various status information during the operation of the control unit. In the event of a malfunction in the control unit, the control unit is unable to update the firmware context and the running flags in the shared memory; The microcontroller reads the running flag from the shared memory and identifies whether the control unit is operating normally based on the running flag; In response to identifying an operational anomaly in the control unit based on the running flags in the shared memory, the microcontroller reads the firmware context from the shared memory and writes the firmware context into the non-volatile memory.

10. A storage device, comprising: Includes control components and microcontrollers; The microcontroller includes a processor and memory; The microcontroller's memory stores a program, and when the microcontroller's processor executes the program, it implements the method according to any one of claims 1-6 and 8; The control unit includes a processor and a memory; The memory of the control unit stores firmware, and when the processor of the control unit executes the firmware, it implements the method according to claim 7 or 9.

Images