Ssd and method for determining a start mode of the ssd

Abstract

The present disclosure relates generally to power-off duration determination for NVMe SSDs. An SSD includes a controller having a first non-volatile memory in which a power-off timestamp is stored and a hardware register accessible by a host. The SSD also includes a second non-volatile memory coupled to the controller, the second non-volatile memory storing instructions for at least one startup mode of the SSD. Upon power-up of the controller and prior to the controller executing the instructions for the at least one startup mode of the SSD, the controller receives a power-on timestamp from the host in the hardware register and determines a startup mode of the SSD based on the power-on timestamp and the stored power-off timestamp.

Description

Technical Field

[0001] The present invention generally relates to systems and methods for determining the duration of a power outage of a solid-state drive (“SSD”). Background Technology

[0002] SSDs and other devices coupled to flash memory store data and instructions as electrical charge within the flash memory. Over time, if the SSD remains idle, this charge can leak out, introducing errors into the stored data and instructions, and in some cases, rendering decoded data and instructions undecodeable. If the SSD attempts to power on based on code containing too many errors stored in the flash memory, power-on may fail, and the SSD may become unusable.

[0003] This is particularly problematic when SSD drives are not used regularly or immediately, such as when they are kept in the data center as replacement or backup drives. If the drive is powered off for extended periods, the NAND will be inactive, and data retention may be compromised. If the drive has been powered off for too long, reading data from memory when the drive is started may fail. The drive may fail to process instructions or metadata written to the NAND, rendering the drive invalid and unusable.

[0004] Although SSDs may contain additional instructions to enable the device to boot into factory mode as if it were first powered on, the device cannot determine whether it will need factory boot mode before booting.

[0005] Therefore, a mechanism needs to be developed to determine the duration of a power outage before the SSD is started. Summary of the Invention

[0006] In one aspect, an SSD includes a controller having a first non-volatile memory storing a power-down timestamp and a hardware register accessible by a host. The SSD also includes a second non-volatile memory coupled to the controller, the second non-volatile memory storing instructions for at least one boot mode of the SSD. Upon powering on the controller and before the controller executes the instructions for the at least one boot mode of the SSD, the controller receives a power-on timestamp from the host in the hardware register and determines the boot mode of the SSD based on the power-on timestamp and the stored power-down timestamp.

[0007] In another aspect, a method for determining the boot mode of an SSD includes: receiving a power-on timestamp from a host at a hardware register of the controller when the controller is powered on; and retrieving a power-off timestamp from a first non-volatile memory coupled to the controller. The method further includes comparing the power-on timestamp and the power-off timestamp to determine a differential time, and determining the boot mode of the SSD based on a comparison of the differential time with a threshold. Attached Figure Description

[0008] The foregoing and other objectives and advantages will become apparent when the following detailed description is taken in conjunction with the accompanying drawings, in which the same reference numerals refer to the same parts throughout the drawings, and in the drawings:

[0009] Figure 1 A block diagram of a solid-state drive (“SSD”) memory device system is shown, which supports determining the duration of a power outage of an SSD.

[0010] Figure 2 shows a flowchart of the typical boot process of an SSD;

[0011] Figure 3 A flowchart illustrating the startup process using an SSD for a determined power outage duration is shown.

[0012] Figure 4 A block diagram illustrating the process of determining the power outage duration of an SSD to determine its boot mode;

[0013] Figure 5 This diagram illustrates the process of receiving a power-on timestamp from the host at the SSD before executing instructions for the SSD's boot mode.

[0014] Figure 6 A decision graph is shown for determining the boot mode of an SSD based on the duration of a power outage; and

[0015] Figure 7 A flowchart illustrating the method for determining the boot mode of an SSD. Detailed Implementation

[0016] An SSD or other device coupled to flash memory can boot using microcode or instructions stored in non-volatile memory, and then boot using code and metadata (e.g., a logical-to-physical mapping table) stored in flash memory. When a device has booted from non-volatile memory and then proceeds to boot using code and / or data from flash memory, if the flash memory contains unrecoverable errors (e.g., because the flash memory was disconnected and hibernated for too long), the SSD may fail to execute instructions correctly and become unusable. Enabling the SSD controller to determine the power outage duration during controller initialization and before executing boot instructions using code and / or data in flash memory allows the SSD controller to determine whether unrecoverable errors may have been introduced into the boot mode instructions in flash memory, requiring the SSD to boot from the factory instructions stored in non-volatile controller memory. The SSD can then choose, based on the power outage duration, whether to boot normally from flash memory or restore to factory settings as if first powered on, to prevent the drive from becoming unusable.

[0017] Figure 1 A block diagram of an SSD memory device system 100 supporting the determination of the power-off duration of an SSD is shown. The SSD memory device system 100 includes a host 102 and an SSD 104. The SSD 104 has a controller 106 including read-only memory (ROM) 107 and registers 108. The controller 106 is coupled to non-volatile memory 110 via connection 114 and to flash memory 111 via connection 115. The host 102 is communicatively coupled to the controller 106 of the SSD 104 via bus 112.

[0018] Register 108 can be a hardware register, requiring no software configuration or system firmware. Before SSD 104 is powered on or accessing flash memory 111, host 102 can use register 108 as a valid register to which host 102 can write timestamps, once power is applied to SSD 104. Because register 108 is a basic hardware register, SSD controller 106 can access the timestamp at startup. SSD controller 106 can be a Non-Volatile Memory High Speed ​​(NVMe) controller 106, and the NVMe core in the controller chip relies on hardware registers and microcode to run and interpret commands. Host 102 can write a power-on timestamp to register 108 as soon as power is applied to SSD 104.

[0019] Controller 106 accesses the power-on timestamp from register 108 and the power-off timestamp stored in non-volatile memory 110 when SSD 104 was previously powered off. Controller 106 determines the power-off duration by calculating the difference between the power-on timestamp supplied by host 102 in register 108 and the power-off timestamp stored in non-volatile memory 110. Based on the calculated power-off duration, controller 106 determines the appropriate boot mode for SSD 104. The microcode and firmware used to boot the controller chip and SSD 104 can then be loaded into controller 106 from non-volatile memory 110 (e.g., serial NOR ROM or NOR flash memory), other non-volatile memory, or storage devices such as hardware registers of register 108. Non-volatile memory 110 or hard-decoded microcode and firmware do not suffer from data retention problems common to NAND flash memory, such as charge leakage over time. Figure 3 and 4 The process of receiving the power-on timestamp from the host 102 and determining the boot mode of the SSD 104 is described in detail.

[0020] Figure 2 illustrates a flowchart 200 of the typical SSD boot process. The process begins at step 202 when the SSD controller is powered on. The SSD controller then executes bootloader code in the on-chip read-only memory (“ROM”) at step 204. At step 206, the bootloader code attempts to load initial code stored in external non-volatile memory. If the bootloader code fails to load the initial code (step 208), execution stops and the SSD fails to boot correctly.

[0021] At step 210, code from external non-volatile memory is executed, and at step 212, the non-volatile memory checks whether factory reset is enabled. If factory reset is enabled (Yes), the process jumps to step 222, where the SSD controller performs factory reset settings including tests on the NAND flash memory. If factory reset is not enabled (No), the process continues to step 214, where the non-volatile memory code attempts to load additional code and metadata stored in the flash memory. If the non-volatile memory code fails here (step 216), normal execution stops and the SSD fails to boot correctly. If the non-volatile memory code successfully loads the additional code and metadata stored in the flash memory, the process continues to step 218, where the SSD controller executes code and metadata from external flash memory, thereby achieving a successful boot of the SSD for normal operation (step 220).

[0022] Figure 3A flowchart 300 illustrates the boot process utilizing an SSD for a determined power-off duration. The process begins at step 302 when the SSD controller is powered on. At step 304, the host writes a timestamp to the SSD controller register. At step 306, the SSD controller executes bootloader code from its internal ROM. At step 308, the bootloader code attempts to load initial code stored in external non-volatile memory. If the bootloader code fails to load the code, the SSD fails to boot properly (step 310). If the bootloader code successfully loads the initial code, the process continues to step 312 and the SSD controller executes the code loaded from the external non-volatile memory. At step 314, the non-volatile memory checks if factory reset is enabled. If factory reset is enabled, the process jumps to step 320, and the SSD controller performs a factory reset including tests on the NAND flash memory, and the process continues to step 322, achieving a successful boot for normal SSD operation.

[0023] If no factory reset is configured, at step 316, the SSD controller determines the time elapsed since the last power failure based on the timestamp written by the host in step 304 and the power failure timestamp stored in the controller. At step 318, the controller determines whether the time elapsed since the last power failure is greater than a limit or threshold. The threshold may be predetermined or a value calculated based on SSD operating parameters (including, but not limited to, the type of NAND flash memory 111, the number of program / erase cycles that NAND flash memory 111 has undergone, the temperature conditions of previous operations of NAND flash memory 111, and the current temperature). If the time elapsed since the last power failure is greater than the threshold, the process jumps to step 320 and the SSD controller performs a factory reset including testing of the NAND flash memory, and the process continues to step 322, achieving a successful boot for normal SSD operation. If the time elapsed since the last power failure is not greater than the limit (i.e., less than or equal to the limit), at step 324, the non-volatile memory code attempts to load code and / or metadata from external NAND flash memory. At step 326, the SSD controller executes the code and metadata loaded from the external NAND flash memory, and at step 322, it successfully starts up, enabling the SSD to operate normally.

[0024] Compared to the regular startup process, Figure 3The current timestamp from the host is used to determine the time since the SSD was last powered off (step 316). If the time mentioned in step 318 exceeds a limit, a jump to factory mode settings is performed, which includes testing the NAND flash memory to ensure it can be properly read and written. This use of timestamps to determine the SSD's power-off duration optimizes on-chip memory utilization. On-chip memory can be expensive, but it is immutable and cannot be changed once the chip is manufactured. This is an advantage for security functions such as those used to check whether externally stored code is legitimate and has not been attacked or otherwise tampered with. The use of external serial NOR non-volatile memory complements internal memory and reduces the cost required for internal or on-chip memory. Serial NOR non-volatile memory can be reprogrammed and modified to upgrade the code stored therein, or to allow different versions of code to be provided for different products. To reduce the cost of NOR, the code in NOR performs the minimum required functions before execution is transferred to the code stored in flash memory. However, if the SSD has been powered off for too long, the flash memory may fail because exceeding the specified hold-up period for the flash memory can cause unrecoverable errors when reading the flash to retrieve code and / or metadata during the boot process. Using timestamps to determine if the hold-up period has expired before accessing the flash memory reduces the risk of SSD failure during the boot process.

[0025] Figure 4 This diagram illustrates a process 400 for determining the power-off duration of an SSD to determine its boot mode. The SSD can be... Figure 1 The SSD storage device system 400 includes a host 402 (e.g., an SSD). Figure 1 Host 102) and SSD 404 (e.g.) Figure 1 SSD 404). SSD 404 has an on-chip ROM 407 (e.g., SSD 104). Figure 1 ROM 107) and register 408 (e.g. Figure 1 The controller 406 (e.g., register 108) Figure 1 Controller 406). Controller 406 is coupled to non-volatile memory 410 (e.g., controller 106). Figure 1 The non-volatile memory 110). The host 402 is communicatively coupled to the controller 406 of the SSD 404. The SSD 404 may also include flash memory and other components, but for clarity... Figure 4 These components have been omitted.

[0026] At step 1, as part of the initial setup of controller 406 during initialization by host 402, host 402 writes the current timestamp into register 408. This timestamp is a power-on timestamp reflecting the time when the controller was initialized to power on. The power-on timestamp may be in the form of the number of milliseconds that have elapsed since midnight on January 1, 1971 UTC. This step is illustrated by arrow 420 from host 402 to controller 406. Initializing the controller to begin executing commands may include a series of actions, including setting registers based on system configuration, informing the host that a previous reset has been completed, configuring queues such as management queues, and configuring controller settings. As part of the configuration of controller 406 during the initialization process, host 402 writes the power-on timestamp into register 408. At step 2, host 402 then enables the controller by writing 1 to the enable bit (“EN bit”) in the controller configuration register. This step is illustrated by arrow 422 from host to controller.

[0027] At step 3, controller 406 retrieves the power-down timestamp stored in non-volatile memory 410 of SSD 404. The power-down timestamp was stored before SSD 404 was powered off. Step 3 is illustrated by arrow 424 from controller 406 to non-volatile memory 410. At step 4, controller 406 calculates the difference between the retrieved power-down timestamp and the power-on timestamp written to register 408 by host 402. The difference between the retrieved power-down timestamp and the power-on timestamp is the power-down duration of SSD 404, or the length of time SSD 404 has been powered off. Based on the calculated power-down duration and a set threshold or limit (which may vary depending on the type of NAND flash memory 111, the number of program / erase cycles already performed by NAND flash memory 111, the temperature conditions of previous operation of NAND flash memory 111, and the current temperature), controller 406 performs the necessary operations of the boot process illustrated by arrow 426.

[0028] For example, regarding Figure 6 and 7 Further described, controller 406 determines the appropriate boot mode for SSD 404 by calculating the power-down duration, comparing the duration with a set threshold, and determining how to continue controller initialization based on the comparison. If the calculated power-down duration meets the threshold, controller 406 continues with the factory reset boot mode; if the calculated power-down duration fails to meet the threshold, controller 406 initializes controller 406 and SSD 404 as usual, including accessing boot instructions in flash memory.

[0029] Specifically, if the calculated power outage duration meets or exceeds the offline data retention time of SSD 404, controller 406 may choose not to attempt to retrieve the previous state of SSD 404 from NAND (not shown), because there is a risk that an unrecoverable error could render SSD 404 unusable. Alternatively, controller 406 may choose to boot SSD 404 using the factory boot mode, as if it were powered on for the first time. The offline data retention time of SSD 404 is determined by controller 406 by loading values ​​stored in non-volatile memory, which may be default preset values ​​or values ​​based on SSD operating parameters (including, but not limited to, the type of NAND flash memory 111, the number of program / erase cycles already performed by NAND flash memory 111, the temperature conditions of previous NAND flash memory operations, and the current temperature). These values ​​are programmed in controller 406 as thresholds to be compared with the power outage duration. The offline data retention time of SSD 404 may be approximately several weeks, months, or years. In some implementations, the SSD 404 has an offline data retention period of three months. In other implementations, the offline data retention period of the SSD 404 depends on temperature.

[0030] Knowing the exact duration of the power outage of SSD 404 allows controller 406 to accurately determine whether SSD 404 should boot in safe mode. If the long storage time period of SSD 404 exceeds its offline data retention time, charge leakage in the flash memory can cause unrecoverable errors in the instructions in the flash memory required for the drive's normal boot mode, thus preventing SSD 404 from booting normally.

[0031] In some implementations, additional thresholds can be predetermined and set within the controller 406 to allow the controller 406 to compare with the duration of the power outage to determine other aspects of the SSD 404's startup, such as the error correction process or whether partially written blocks have been flushed. These thresholds can be much shorter than the SSD 404's offline data retention time threshold, approximately several hours, days, or weeks.

[0032] The controller 406 can also use the calculated power outage duration of the SSD 404 to determine an error correction or debugging method for read errors encountered when accessing the flash memory. Information about recent power cycles and power outage durations allows the controller 406 to predict potential problems in the SSD 404 based on power outage durations compared to thresholds. The controller 406 can then select an appropriate error correction method to debug the anticipated problem based on the time elapsed since the SSD 404 was last powered down.

[0033] Additionally, the power outage duration information available to controller 406 allows controller 406 to determine the appropriate write pattern to the flash memory blocks. Flash memory is written sequentially to pages, and it is necessary to fill each block rather than leaving partially written blocks, so that the number of pages written is not a complete block. During each power cycle, SSD 404 flushes any open or partially filled blocks at startup by moving data from partially written blocks to new blocks and re-circulating the partially written blocks to avoid reliability issues. In a normal shutdown procedure signaled by the host, blocks will not be partially filled. However, in the event of an unexpected power outage, such as a power failure, blocks in flash memory may be partially filled during shutdown. If SSD 404 experiences a power outage for a considerable period, the data in partially written blocks may become unreliable and must be moved to the next block, and writing should continue with the next block. However, if the power outage duration is short enough, it is unnecessary to flush the block, and the controller 406 can allow writing to continue into the same partially filled block because the time delay between power cycles is insufficient to make the data written to the partially filled block unreliable. The controller 406 compares the calculated power outage duration with a threshold set based on the duration a block can be in an erased state during the power outage to determine whether a flush is needed, or whether writing can continue into the partially filled block. This improves the readiness time of the SSD 404 because it eliminates the need to flush open blocks and avoids unnecessary NAND wear. In such cases, the controller 406 can also use the power outage duration to determine an appropriate error correction method to correct errors in partially written blocks. Accurate power outage timestamps are required for the controller to use the power outage duration information for this purpose.

[0034] When controller 406 completes the startup process, it sets a host-accessible status bit to signal that it is ready to receive commands, such as storage commands, from host 402. Specifically, controller 406 sets the RDY status bit in the controller status register (not shown). The RDY status bit indicates readiness to accept NVMe I / O commands, but controller 406 may accept NVMe management commands before setting the status bit. Host 402 awaits this signal from controller 406, indicating that controller 406 has completed initialization and is ready to receive and process commands, such as NVMe I / O commands, from host 402.

[0035] At step 5, as illustrated by arrow 428 from host 402 to controller 406, host 402 transmits I / O commands to controller 406. At this time, host 402 may also provide the NVMe command timestamp as part of the "Set Feature Timestamp" command to SSD 404. In most cases, because the NVMe "Set Feature Timestamp" command arrives from host 402 after the instructions for booting SSD 404 have been executed, the power-on timestamp cannot be supplied based on the NVMe "Set Feature Timestamp" command; controller 406 will make a decision on selecting the boot mode for SSD 404 based on the power-on timestamp.

[0036] In some implementations, controller 406 may include instructions for a two-stage boot process. Initially, it uses boot code stored in SPI flash memory to enable controller 406 to receive an NVMe "set characteristic timestamp" command from the host, determine the power-down duration based on the received timestamp, and begin executing the main boot code accessed from non-volatile memory. In this case, the "set characteristic timestamp" command is not received as an I / O command; this necessitates setting up commit and completion queues in controller 406 to process the command, and controller 406 may access the timestamp before accessing the boot instructions from flash memory.

[0037] At step 6, as illustrated by arrow 430 from controller 406 to non-volatile memory 410, controller 406 records a power-off timestamp in the non-volatile memory. In some embodiments, the power-off timestamp is stored in non-volatile memory 410 immediately before the moment controller 406 loses power. In some embodiments, controller 406 periodically updates the power-off timestamp in non-volatile memory 410. For example, controller 406 may update the power-off timestamp hourly, every 24 hours, weekly, monthly, or at any other suitable period. To periodically update the timestamp, controller 406 internally tracks the time when SSD 404 has been powered on and adds the timestamp received from the host in step 1 to that time to obtain the current time.

[0038] For SSDs with a power outage protection (PLP) capacitor that supplies backup power after an unexpected power outage, controller 406 updates the power outage timestamp using the residual capacitor power as part of the PLP shutdown process in the event of an unexpected power outage. In other embodiments, for SSDs without a PLPP capacitor, controller 406 does not update the power outage timestamp upon an unexpected power outage and relies on the last power outage timestamp saved to non-volatile memory 410 during periodic timestamp updates.

[0039] Although Figure 4The controller 406 stores the power-down timestamp in non-volatile memory 410, but it can also store it in another persistent non-volatile memory of the SSD 404. For example, the power-down timestamp can be updated in ROM 407, an external NOR ROM, a controller register, or a power-down timestamp register. The power-down timestamp can be stored in any persistent memory of the controller 406 that can be accessed by the controller 406 before the drive is fully booted. The NOR ROM contains boot code and metadata that cannot be stored in NAND. The information in the NOR is sufficient to power on the drive and access flash memory, or to allow the drive to boot as if it were just installed at the factory. Typically, the NOR ROM is a separate external memory for the controller 406 itself, which can be used to update firmware. In some implementations, the controller 406 updates the power-down timestamp periodically and also updates it when the SSD 404 is powered off.

[0040] In another implementation, the timestamp is stored in a register of controller 406, such as a microcode-accessible PCIe / NVMe controller register. Regardless of how the microcode and firmware are loaded, the host can access the hard-decoded register upon power-up. Host 402 can use SSD 404 as a valid NVMe or PCIe device, and the host can access the register before NOR code or boot ROM code has been started. In some implementations, the power-down timestamp is stored separately from the power-on timestamp. In some implementations, the power-down timestamp is stored together with the power-on timestamp in register 408.

[0041] In some implementations, controller 406 maintains a history of power-on and power-off timestamps in non-volatile memory 410 and / or register 408 of SSD 404. Controller 406 can use this history to determine the cumulative power-off duration of SSD 404 for determining appropriate boot methods or other SSD processes, such as error correction procedures. In some implementations, controller 406 saves the history of power-on and power-off timestamps as a complete history of power-on and power-off timestamps, and / or as a complete history of power-off durations. In some implementations, the history is saved as a subset of power-on and power-off timestamps or power-off durations, for example, the last 10 timestamps or durations. In some implementations, controller 406 saves the history as a cumulative power-off time for determining power-on modes or other processes of SSD 404. By storing and considering the cumulative power-off time, controller 406 can determine whether multiple short power-off cycles, in aggregate, are equivalent to a longer power-off duration requiring flushing of partially written blocks or implementation of a specific error correction or debugging strategy.

[0042] In order to implement about in NVMe devices Figure 4The described process adds support for timestamp register 408 under the controller register set to the NVMe specification. The NVMe driver at the application layer will need to perform a memory write transaction that writes the timestamp register 408 to the current host system time, and the SSD controller 406 will need to update the timestamp over time in persistent memory across power cycles and reset commands. This is achieved by saving the power-off timestamp to the non-volatile memory 410 of the SSD 404, as described above.

[0043] although Figure 1 , 3 Sections 4 and 5 describe determining the power-down duration in the context of an SSD, but calculating the power-down duration for determining an appropriate boot mode or other processes can be used in various devices that use flash memory to store data necessary for a normal boot process. For example, the method of receiving power-on timestamps, retrieving stored power-down timestamps, and determining the power-down duration from these timestamps would be suitable for devices that typically use a PCIe high-speed bus that relies on data stored in NAND flash memory required during a normal boot process, such as a network interface controller (NIC), like an Ethernet NIC. If the Ethernet NIC attempts to read the NAND flash memory after a prolonged power-down, it may encounter an unrecoverable error while attempting to read the NAND flash memory. Ethernet NICs, PCIe devices, or any other similar devices that rely on NAND flash memory during a normal boot process can benefit from the methods described above. Figure 1 , 3 The method described in section 4 is used to determine this startup mode by receiving the power-on time from its control device and storing the power-off time.

[0044] Figure 5 Block diagram 500 illustrates the process of receiving a power-on timestamp from the host at device 504 before the SSD executes a boot mode instruction. Block diagram 500 includes a host 502 and a device 504. The host may be... Figure 1 Host 102, Figure 4 The host 402, or any device that controls the use of flash memory to store data necessary for the normal boot process. Device 504 may be... Figure 1 SSD 104 Figure 4 The SSD 404, or any device that uses flash memory to store data necessary for the normal boot process, such as an Ethernet NIC or PCIe device. The host 502 and the device 504 are communicatively coupled.

[0045] Host 502 performs PCIe Base Address Register (BAR) configuration 532 on device 504 to begin configuring device 504 by reading and writing its BAR register. During device enumeration following the configuration register, host 502 performs memory reads and memory writes to the memory-mapped device registers. Host 502 then transmits a memory write current timestamp command 534 to device 504 to write the current time as the power-on time into the timestamp register (i.e., the new register, as disclosed in this application). Host 502 continues initializing device 504 by transmitting a memory write CC.EN=1 command 536 to device 504 to set the enable bit to 1, thereby initiating the initialization and startup process. Device 504 initializes to use the timestamp to determine the power-off duration and, if necessary, use it for driver initialization 540. Device 504 uses the current timestamp information and the saved timestamp information from the last power-off of device 504 to determine the power-off time before power-on and determines the appropriate startup mode based on the power-off duration. Figure 4 Describe this process. Finally, host 502 performs a memory read 538 on device 504 to determine whether device 504 has been initialized and is ready to receive commands from host 502. Host 502 performs a memory read of CSTS.RDY=1 to determine whether device 504 has set the ready bit to 1, which indicates that the initialization and execution of the instructions for startup have been completed and device 504 is ready to receive I / O commands from host 502.

[0046] Figure 6A decision diagram 600 is shown for determining the boot mode of an SSD based on the duration of a power outage. The process begins, for example, at step 602 when power is supplied to the controller of the SSD. At step 604, the controller receives a power-on timestamp from the host into its register. At step 606, the controller retrieves the power-off timestamp stored in non-volatile memory at the time of the controller's last power outage. At step 608, the controller determines the duration of the SSD's power outage based on the power-on timestamp supplied by the host and the power-off timestamp stored in memory. At step 610, the controller determines whether the duration of the power outage meets a first threshold. The first threshold is a predetermined value or a value calculated and updated by the controller and set in non-volatile memory. Default initial values ​​can be predetermined and stored in ROM or non-volatile memory, and updated values ​​can then be calculated based on SSD operating condition parameters, including, but not limited to, the type of NAND flash memory in the SSD, the number of program / erase cycles already performed by the NAND flash memory, the temperature conditions under which the NAND flash memory previously operated during power-on, the current temperature, etc. In some implementations, in addition to writing a power-on timestamp to the SSD, the host may also write temperature distributions, such as the maximum / minimum / average ambient temperature occurring when the SSD is powered off, to additional registers so that the SSD can better estimate or calculate the retention time of the NAND flash memory in the SSD. A first threshold may be the offline data retention time of the NAND flash memory 111 of the SSD.

[0047] If the controller determines at step 610 that the power-off duration does indeed meet the first threshold (Yes) and the power-off duration is longer than the offline data retention time, making an unrecoverable error highly likely, the process continues to step 612, and the controller executes instructions for factory boot mode using microcode and instructions stored in non-volatile memory such as NOR ROM. The factory boot mode instructions start the controller and SSD as if powered on for the first time. If the controller determines at step 610 that the power-off duration does not meet the first threshold (No) because the power-off duration is equal to or less than the offline data retention time, the process continues to step 614, where the controller determines whether the power-off duration meets a second threshold. The second threshold may be the duration for which a block in the SSD memory can be in an erased state during the power-off period.

[0048] If the controller determines at step 614 that the power-down duration fails to meet the second threshold (No), such that the power-down duration is shorter than or equal to the maximum duration for which a block in the SSD memory can be erased during the power-down period, the controller proceeds to step 616 and performs a normal boot process based on instructions stored in the flash memory, continuing to write to the partially written block without refreshing. If the controller determines at step 614 that the power-down duration meets the second threshold (Yes) and the power-down duration is longer than the duration for which a block can be erased during the power-down period, the controller proceeds to step 616 and performs a normal boot process based on instructions stored in the flash memory, performing a refresh of the block by writing the data written to the partially written block to a new block and erasing the old block. The controller then continues writing to the new block. Having information about the SSD's power-down duration before starting the drive's boot process allows the controller to make a decision to ignore flash memory read errors and boot in factory mode, or to boot from flash memory normally using some error correction method. Furthermore, this information enables the controller to make additional decisions regarding the process utilized after successful execution of the boot mode instruction, such as whether to flush partially written blocks.

[0049] Figure 7 A flowchart illustrating method 700 for determining the boot mode of an SSD is shown. At step 702, the controller (e.g., Figure 1 Controller 106 or from Figure 4 When the controller (406) is powered on, it receives a power-on timestamp from the host at its hardware register. The host writes the timestamp to the hardware register during the controller initialization process and before the controller has fully booted up or accessed flash memory. At step 704, the controller retrieves the power-off timestamp from a first non-volatile memory coupled to the controller. The power-off timestamp was previously saved to the non-volatile memory by the controller prior to the last power-off of the SSD.

[0050] At step 706, the controller compares the power-on timestamp and the power-off timestamp to determine a differential time. The SSD subtracts the power-off timestamp retrieved from the first non-volatile memory from the power-on timestamp received from the host to determine the differential time. The differential time is the duration of the SSD's power-off. At step 708, the controller determines the SSD's boot mode based on a comparison of the differential time with a threshold. In some embodiments, the threshold may be a preset default threshold, or it may be a threshold calculated by the SSD controller and updated based on the SSD's operating conditions, indicating the SSD's offline data retention time. The threshold may be approximately several days, weeks, months, or years. In some embodiments, the threshold is three months. In some embodiments, the threshold depends on temperature. In some embodiments, the threshold depends on the number of program / erase cycles that the SSD's NAND flash memory has undergone.

[0051] If the differential time meets the threshold, the controller continues with the factory reset boot mode. If the calculated differential time fails to meet the threshold, the controller initializes the controller and SSD as usual, including boot instructions and metadata for accessing flash memory. If the calculated differential time meets or exceeds the SSD's preset offline data retention time, the controller chooses not to attempt to retrieve the SSD's previous state from the NAND, due to the high risk of unrecoverable errors rendering the SSD unusable. Instead, the controller boots the SSD using the factory boot mode as if it were being powered on for the first time.

[0052] By enabling the SSD controller to determine the duration of a power outage, drive failure can be avoided when booting after a long power outage period. The SSD can make boot mode decisions based on a comparison of the power outage duration with a set threshold, determining whether to boot normally using instructions stored in flash memory, or whether to boot in factory default mode if the power outage duration is too long and unrecoverable errors are likely. Providing the controller with the power outage duration further allows the controller to determine whether to flush partially written blocks or continue writing, which improves SSD readiness time and reduces unnecessary NAND wear. Furthermore, providing information about the power outage duration is useful for several devices that use flash memory to store boot mode instructions, such as Ethernet controllers and other PCIe devices. Providing information that allows the calculation of power outage duration improves the efficiency and lifespan of such devices.

[0053] Other objects, advantages, and embodiments of the various aspects of the invention will be apparent to those skilled in the art, and are within the scope of this description and the accompanying drawings. For example, but not limited to, structural or functional elements may be rearranged according to the invention. Similarly, the principles of the invention can be applied to other instances that are not specifically described in detail herein but are still within the scope of the invention.

Claims

1. A solid-state drive (SSD) comprising: The controller includes: A first non-volatile memory, configured to store a power-off timestamp; and Hardware registers, which the host can access; and A second non-volatile memory coupled to the controller is configured to store instructions for at least one boot mode of the SSD. When the controller is powered on and before it executes the instructions for at least one boot mode of the SSD, the controller is configured to receive a power-on timestamp from the host in the hardware register, and determine the boot mode of the SSD based on the power-on timestamp and a stored power-off timestamp. The controller is configured to receive the power-on timestamp from the host before setting a status bit that the host can access, the status bit indicating readiness to receive a storage command from the host.

2. The SSD of claim 1, wherein the controller is configured to determine the boot mode by determining the time difference between the power-on timestamp and the stored power-off timestamp, and comparing the time difference with a threshold.

3. The SSD according to claim 2, wherein If the differential time is greater than the threshold, the controller is configured to enter factory startup mode, and If the differential time is less than or equal to the threshold, the controller is configured to enter a normal startup mode by accessing the second non-volatile memory.

4. The SSD of claim 1, wherein the first non-volatile memory is configured to store a history of power-off and power-on timestamps.

5. The SSD of claim 4, wherein the controller is configured to determine the cumulative power outage duration based on the history of power outage and power-on timestamps.

6. The SSD of claim 1, wherein the controller is configured to determine an error correction mode based on the power-on timestamp and the stored power-off timestamp.

7. The SSD of claim 1, wherein the controller is configured to determine whether to refresh one or more blocks of the memory based on the power-on timestamp and the stored power-off timestamp.

8. The SSD of claim 1, wherein, upon power-off, the controller is configured to store a power-off timestamp in the first non-volatile memory.

9. The SSD according to claim 1, wherein the hardware register is a PCIe hardware register.

10. The SSD of claim 1, wherein the controller is configured to periodically update the current timestamp in the first non-volatile memory.

11. The SSD of claim 1, wherein the power-on timestamp received from the host is received as a memory write command having the current host system timestamp.

12. A method for determining the boot mode of a solid-state drive (SSD), the method comprising: When the controller is powered on, the power-on timestamp is received from the host in the controller's hardware register; Retrieve the power-off timestamp from the first non-volatile memory coupled to the controller; Compare the power-on timestamp with the power-off timestamp to determine the time difference; as well as The boot mode of the SSD is determined based on a comparison between the differential time and a threshold. Receiving the power-on timestamp further includes receiving the power-on timestamp from the host before setting a status bit that the host can access, the status bit indicating readiness to receive a storage command from the host.

13. The method of claim 12, further comprising: If the differential time is greater than the threshold, then enter the factory start-up mode; and If the differential time is less than or equal to the threshold, the system enters normal startup mode by accessing a startup instruction communicatively coupled to the controller's second non-volatile memory.

14. The method of claim 12, further comprising determining an error correction mode based on the comparison of the differential time with the threshold.

15. The method of claim 12, further comprising determining whether to refresh one or more blocks of the memory based on the power-on timestamp and the stored power-off timestamp.

16. The method of claim 12, further comprising periodically updating the current timestamp stored in the first non-volatile memory.

17. The method of claim 12, further comprising storing a history of power-on and power-off timestamps in the first non-volatile memory.

18. The method of claim 12, further comprising storing a power-off timestamp in the first non-volatile memory upon power failure.

Images