Defective blocks generated during the block erasure operation are processed.

Abstract

A memory component includes a plurality of fuses, a memory array having a plurality of blocks, and control logic operatively coupled to the memory array and the plurality of fuses. The control logic receives an erase command associated with the memory array and, in response to receiving the erase command, attempts to erase a block from the memory array. The control logic further detects that the block was not completely erased. The control logic further receives a fuse-blowing command in response to the failure to completely erase the block. The control logic blows a fuse among the plurality of fuses coupled to the block, such that the block is inaccessible by the control logic.

Description

Technical Field

[0001] Embodiments of this disclosure generally relate to memory subsystems, and more specifically, to processing poorly grown blocks generated during block erase operations. Background Technology

[0002] The memory subsystem may include one or more memory components for storing data. Memory components may be, for example, non-volatile memory components and volatile memory components. Generally, the host system can utilize the memory subsystem to store data at the memory components and retrieve data from the memory components. Attached Figure Description

[0003] This disclosure will be more fully understood from the detailed description provided below and the accompanying drawings of various embodiments thereof.

[0004] Figure 1A This describes an instance computing environment including a memory subsystem according to some embodiments of the present disclosure.

[0005] Figure 1B According to some embodiments of this disclosure Figure 1A A block diagram of the memory subsystem.

[0006] Figure 2 This is a flowchart of an example method for processing poorly grown blocks generated during a block erasure operation, according to some embodiments of the present disclosure.

[0007] Figure 3 This is a flowchart of an example method for processing poorly grown blocks generated during a block erasure operation, according to other embodiments of this disclosure.

[0008] Figure 4 Examples of determining whether to process poorly grown blocks generated during block erasure operations according to other embodiments of this disclosure are described.

[0009] Figure 5 This is a block diagram of an example computer system in which embodiments of the present disclosure may be operated. Detailed Implementation

[0010] This disclosure relates to handling defective blocks generated during block erase operations. The memory subsystem may be a storage device, a memory module, or a mixture of both. The following is combined with... Figure 1A Describe examples of storage devices and memory modules. Generally, a host system may utilize a memory subsystem that includes one or more memory components (e.g., memory devices for storing data). The host system can provide data to be stored in the memory subsystem and can request data to be retrieved from the memory subsystem.

[0011] The memory device may be a non-volatile memory device. A non-volatile memory device is a package of one or more dies. Each die may consist of one or more planes. For some types of non-volatile memory devices (e.g., NAND devices), each plane consists of a set of physical blocks. For some memory devices, a block is the smallest erasable area. Each block consists of a set of pages. Each page consists of a set of memory cells storing data bits. In the following text, a “bad block” refers to a block that is no longer reliably usable for storing or retrieving data, for example, due to defects (e.g., manufacturing defects) or wear. A “growth bad block” (GBB) refers to a bad block that is unreliable due to wear and can be identified based on a threshold (e.g., a bit error rate (BER) threshold). Data stored in one or more memory cells in a bad block may not be properly erased during an erase operation due to damage, defects, or normal wear of the memory cells over time. Examples of commands that perform this block erase operation include the clear block erase command and the secure erase command to erase the stored data from the memory subsystem. In this scenario, the memory subsystem may receive an error code indicating an error during the erasure of one or more blocks of a memory component contained within the memory subsystem. Failure to completely erase the memory subsystem poses a security risk, allowing an attacker to physically remove memory components containing faulty blocks to directly access data on the memory components, including any remaining data that cannot be completely erased. In one embodiment, an attacker may also use a diagnostic port to attempt to retrieve such data.

[0012] Normally, the memory subsystem will report this error to the host system when the memory components are completely erased, and this is considered an Annual Failure Rate (AFR) event. An AFR event means that the memory subsystem has been removed from service and is likely to be discarded or destroyed. Therefore, receiving an error only when performing certain types of erase operations on the memory subsystem can lead to an AFR event, the potential loss of the memory subsystem (or the memory device containing the memory subsystem), or the potential security risk of exposing residual data if the memory subsystem is not destroyed.

[0013] This disclosure addresses the above and other drawbacks by having a memory subsystem that prevents bad blocks from being physically and / or electrically accessed by any agent attempting to read the bad block at the level of the memory component. Due to the failure to access the bad block, no error is sent to the host system, and thus any AFR events are avoided.

[0014] Various methods can be used to prevent faulty blocks from being accessed at the memory component level. In one embodiment, multiple fuses are coupled between the control logic of the memory component (e.g., embedded within a local media controller) and corresponding blocks within the memory component. In response to detecting a fault (e.g., an error) while attempting to erase a block among the multiple blocks within the memory component, the memory subsystem can send a fuse-blowing command to the control logic. The control logic can then blow the fuse coupled to the block to make the block inaccessible by the memory subsystem (e.g., the control logic).

[0015] In various embodiments, read-only memory (ROM) blocks exist within the memory component to store logical-to-physical address mappings of multiple blocks of the memory component. Control logic can access these mappings to locate the correct block in response to a read request containing a logical address. Thus, in another embodiment, the memory subsystem may send an update ROM command to the control logic in response to detecting a fault (e.g., an error) during an attempt to erase a block. The control logic may then update the programming of the ROM blocks of the memory component in response to the update ROM command, thereby replacing the block's mapping information. In one embodiment, the programming causes the block to be remapped to a spare blank block among multiple blocks.

[0016] The advantages of this disclosure include (but are not limited to) the ability of the memory subsystem to fail to access a bad block rather than detecting a block that was not completely erased (which can lead to an AFR event). For example, if the memory subsystem sends a read request directed to a block, the control logic can detect that the corresponding fuse has blown or the corresponding field in the ROM block has been updated, making the block physically and / or electrically inaccessible. In one embodiment, the control logic can return an error to the memory subsystem, replacing any data stored in the block. However, because this is an error concerning inaccessible data and incorrectly erased data (e.g., associated with a bad block), the memory subsystem does not need to send associated errors to the host system that could cause an AFR event. Therefore, the memory subsystem can continue to operate, e.g., without being disabled or destroyed.

[0017] Figure 1AThis description describes an example computing environment 100 including a memory subsystem 110 according to some embodiments of the present disclosure. The memory subsystem 110 may include media, such as memory components 112A to 112N (hereinafter also referred to as "memory devices"). Memory components 112A to 112N may be volatile memory components, non-volatile memory components, or combinations of such components. The memory subsystem 110 may be a storage device, a memory module, or a hybrid of a storage device and a memory module. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash memory (UFS) drives, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small form factor DIMMs (SO-DIMMs), and non-volatile dual in-line memory modules (NVDIMMs).

[0018] Computing environment 100 may include a host system 120 coupled to one or more memory subsystems 110. In some embodiments, host system 120 is coupled to different types of memory subsystems 110. Figure 1 illustrates an example of a host system 120 coupled to a memory subsystem 110. Host system 120 uses memory subsystem 110, for example, to write data to and read data from memory subsystem 110. As used herein, “coupled to” generally refers to a connection between components, which may be an indirect communication connection or a direct communication connection (e.g., without intermediate components), whether wired or wireless, and includes, for example, electrical connections, optical connections, magnetic connections, etc.

[0019] The host system 120 may be a computing device, such as a desktop computer, laptop computer, network server, mobile device, embedded computer (e.g., a computer contained in a vehicle, industrial equipment, or networked business device), or a computing device that includes memory and processing. The host system 120 may include or be coupled to the memory subsystem 110 such that the host system 120 can read data from or write data to the memory subsystem 110. The host system 120 may be coupled to the memory subsystem 110 via a physical host interface. Examples of physical host interfaces include, but are not limited to, Serial Advanced Technology Attachment (SATA) interfaces, Peripheral Component Interconnect High Speed ​​(PCIe) interfaces, Universal Serial Bus (USB) interfaces, Fibre Channel, Serial Attached SCSI (SAS), etc. The physical host interface can be used to transfer data between the host system 120 and the memory subsystem 110. When the memory subsystem 110 is coupled to the host system 120 via a PCIe interface, the host system 120 may further utilize an NVM High Speed ​​(NVMe) interface to access memory components 112A to 112N. The physical host interface provides an interface for transmitting control, address, data and other signals between the memory subsystem 110 and the host system 120.

[0020] Memory components 112A to 112N may comprise any combination of different types of non-volatile memory components and / or volatile memory components. Examples of non-volatile memory components include negative-and (NAND) type flash memory. Each of memory components 112A to 112N may comprise one or more arrays of memory cells (e.g., NAND memory cells), such as single-level cell (SLC), multi-level cell (MLC), three-level cell (TLC), or four-level cell (QLC). In some embodiments, a particular memory component may comprise both an SLC portion and another type (e.g., MLC, TLC, QLC) portion of a memory cell. Each memory cell may store one or more data bits for use by the host system 120. While non-volatile memory components, such as NAND type flash memory, have been described, memory components 112A to 112N may be based on any other type of memory, such as volatile memory. In some embodiments, memory components 112A to 112N may be, but are not limited to, random access memory (RAM), read-only memory (ROM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), phase-change memory (PCM), magnetic random access memory (MRAM), NOR flash memory, electrically erasable programmable read-only memory (EEPROM), and a cross-point array of non-volatile memory cells. The cross-point array of non-volatile memory may combine with a stackable cross-grid data access array to perform bit storage based on changes in volume resistance. Additionally, compared to many flash-based memories, cross-point non-volatile memory can perform in-situ write operations, where non-volatile memory cells can be programmed without pre-erasing them. Furthermore, memory cells of memory components 112A to 112N may be grouped to form pages, where a page may refer to a cell of the memory component used to store data. For some types of memory (e.g., NAND), pages may be grouped to form blocks.

[0021] Memory system controller 115 (hereinafter referred to as the "memory controller" or simply the "controller") can communicate with memory components 112A to 112N to perform operations, such as reading, writing, or erasing data at memory components 112A to 112N, and other such operations. Controller 115 may include hardware such as one or more integrated circuits and / or discrete components, buffer memories, or combinations thereof. Controller 115 may be a microcontroller, application-specific logic circuitry (e.g., a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), etc.), or other suitable processor. Controller 115 may include a processor (processing device) 117 configured to execute instructions stored in local memory 119. In the illustrated example, the local memory 119 of controller 115 includes embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines that control the operation of memory subsystem 110 (including processing communication between memory subsystem 110 and host system 120). In some embodiments, local memory 119 may include memory registers storing memory pointers, retrieved data, etc. Local memory 119 may also include read-only memory (ROM) for storing microcode. Although the example memory subsystem 110 in FIG1 is illustrated to include controller 115, in another embodiment of this disclosure, memory subsystem 110 may not include controller 115 and may instead rely on external control (e.g., provided by an external host or by a processor or controller separate from the memory subsystem).

[0022] Generally, controller 115 can receive commands or operations from host system 120 and can translate these commands or operations into instructions or appropriate commands to enable desired access to memory components 112A to 112N. Controller 115 may handle other operations such as wear leveling, garbage collection, error detection and error correction (ECC) operations, encryption, caching, and address translation between logical addresses (e.g., logical block addresses (LBAs)) and physical addresses (e.g., physical block addresses) associated with memory components 112A to 112N. Controller 115 may further include host interface circuitry for communicating with host system 120 via a physical host interface. The host interface circuitry can translate commands received from the host system into command instructions to access memory components 112A to 112N, and translate responses associated with memory components 112A to 112N into information for host system 120.

[0023] The memory subsystem 110 may also include additional circuitry or components not described. In some embodiments, the memory subsystem 110 may include a cache or buffer (e.g., DRAM) and an address circuitry (e.g., row decoder and column decoder) that receives and decodes addresses from the controller 115 to access memory components 112A to 112N. Any of the memory components 112A to 112N may include a media controller (e.g., media controller 130A and media controller 130N, respectively) to manage the memory cells of the memory components 112A to 112N, communicate with the memory subsystem controller 115, and execute memory requests (e.g., reads or writes) received from the memory subsystem controller 115.

[0024] The memory subsystem 110 includes an error determination component 113, which can be used to detect errors associated with attempts to complete a block erase operation and access to faulty blocks that are not physically and / or electrically accessible. In some embodiments, the controller 115 includes at least a portion of the error determination component 113. For example, the controller 115 may include a processor 117 (processing means) configured to execute instructions stored in local memory 119 for performing the operations described herein. In some embodiments, the error determination component 113 is part of the host system 120, an application, or an operating system.

[0025] In some embodiments, memory components 112A to 112N may be managed memory devices (e.g., managed NAND) that are native memory devices combined with a local controller (e.g., media controller 130) for memory management within the same memory device package. Media controller 130N may also include error determination component 113.

[0026] Error determination component 113 may receive errors associated with memory components 112A to 112N of memory subsystem 110, and the errors may be at the granularity of one or more blocks. In response to sending a block erase command or operation to one of the memory components, error determination component 113 may detect an error indicating that at least one of a plurality of blocks on the memory component has not been completely erased. Error determination component 113 may then send a command to the microcontroller of the memory component in one of a variety of ways to make the block physically and / or inaccessible by the microcontroller in future access requests for the block. Further details regarding the operation of error determination component 113 are described below.

[0027] Figure 1B According to some embodiments of this disclosure Figure 1AA block diagram of the memory subsystem 110. In an embodiment, the memory subsystem 110 includes a controller 115 coupled to a memory component 112A, which is depicted as an exemplary memory component of any one of memory components 112A to 112N. The memory component 112A may include a local media controller 130, a memory array 140, a ROM block 150, and a plurality of fuses 160. The local media controller 130 may couple the controller 115, the ROM block 150, the memory array 140, and the plurality of fuses 160 together, as illustrated. In some embodiments, the ROM block 150 or one of the plurality of fuses 160 is missing, and therefore, Figure 1B The memory component 112A is illustrated in at least two possible embodiments that will be explained. If the ROM block 150 is missing, then the dashed arrow can be considered as having been removed, thus forcing access to the memory array 140 through multiple fuses 160.

[0028] In one embodiment, the local media controller 130 is coupled to the controller 115 via an Open NAND Flash Interface (ONFI) 125, which serves as a communication interface between the controller 115 and the memory component 112A when the controller 115 is an SSD controller and the memory component 112A is a NAND flash component of the memory. Furthermore, in some embodiments, the local media controller 130 is a microcontroller containing a hardware state machine that translates commands from the ONFI interface (e.g., sent by the controller 115) to access the memory array 140. For example, the local media controller 130 may contain control logic embodied in a state machine, which may generally be immutable and execute commands or operations as introduced by the controller 115. In this disclosure, the state machine of the local media controller 130 is further adapted to interface with one or both of the ROM block 150 and a plurality of fuses 160, further indicating its ability to access certain blocks of the plurality of blocks of the memory array 140.

[0029] For example, in various embodiments, memory array 140 is an array of multiple blocks (e.g., numbered zero to N) that can be indexed within ROM block 150. ROM block 150 may further contain a logical-to-physical address mapping from logical addresses (e.g., specified by controller 115 or host system 120) to physical addresses (e.g., index values ​​within memory array 140). As illustrated, local media controller 130 can update the mapping of blocks (among the multiple blocks) by programming fields of ROM block 150 with different values.

[0030] In some embodiments, the plurality of fuses 160 include hardware fuses corresponding to each block of the memory array 140. In an embodiment, the respective fuses of the plurality of fuses 160 are operatively coupled between the respective block and the local media controller 130. Thus, each fuse may be coupled between the local media controller 130 and the memory array 140 such that when a fuse is blown, data within the block previously coupled to the fuse is not physically and electrically accessible by the local media controller 130. The result of this embodiment is to electrically disconnect the block from the local media controller 130. In additional or alternative embodiments, the control logic of the local media controller 130 may be designed to check the state (e.g., fuse status) of the fuses for each block before accessing the data in the block. If a fuse is blown (e.g., if the fuse for the block is blown), the local media controller 130 will be electrically disconnected from the local media controller 130. Figure 1B If the fuse in block 1 is not found, then the local media controller 130 can block access to the data and return a read error to the controller 115.

[0031] Any one of the blocks in memory array 140 may become a bad block after its data has been completely erased in response to a block erase command (e.g., a secure or clear block erase operation). Figure 1B As described, the fuse for block 1 is pre-blown in response to a fault in the block erase command (e.g., a NAND erase command) during a clear block erase operation. More specifically, the local media controller 130 blows the fuse in response to a sequence of commands issued via ONFI 125 through controller 115, in response to a fault detected in the block erase operation at block 1, thus blowing the fuse coupled to block 1. When a read request is issued to memory component 112A in the future, the local media controller 130 can check the fuse status to determine whether the target block is accessible. Therefore, future memory access to block 1 can be blocked, thereby preventing bad block errors from occurring to the host system 120.

[0032] For further reference Figure 1B In one embodiment, ROM block 150 may be part of a memory component reserved for use as ROM by the system. In additional or alternative embodiments, ROM block 150 may contain a fixed data structure of configuration parameters for NAND device operation. These parameters may include, for example, specifications of blocks marked as “bad” by the factory, and whether the local media controller 130 will allow access to a specified block in a mapping within a field of the ROM block. Thus, as illustrated in Table 1 (Exemplary Logical to Physical Address Mapping Table), ROM block 150 may contain multiple fields (e.g., mapping fields), each corresponding to a specific block among the multiple blocks of memory array 140. It should be noted that the “Block Identifier (ID)” field may not actually be included in ROM block 150, but is included here for clarity of explanation.

[0033] In additional or alternative embodiments, the local media controller 130 receives an update ROM command (or other command sequence) from the controller 115 in response to the controller 115 detecting an error code or other error indicating that a block of the memory array (e.g., block 1) failed to be erased during a block erase operation. In one embodiment, in response to the update ROM command, the local media controller 130 may update the programming of the ROM block 150 to replace mapping information, such as the value of the physical address field.

[0034] Block ID Logical address physical address Factory / Instruction 0 MXCA 0000 1 MXCI 00001 Poor (or GBB) 2 MCXO 0010 3 NWRT 0011 4 JQWR 0100 5 CVGY 0101 6 NXCA 00001 bad 7 NXIC 0111 … KLWE … … N ASFD 1111

[0035] Table 1

[0036] In some embodiments, the remapped value may reach a limit value, for example, by writing a fixed data pattern to a field in multiple fields (e.g., to the block 1 physical address field). A fixed data pattern (e.g., "00001" or other fixed patterns) may indicate that the block is not accessible, thus blocking access to the block (e.g., block 1). In another embodiment, remapping may be replacing the physical address mapping to remap the logical address to a spare blank block in multiple blocks. In this case, the local media controller 130 may read ROM block 150 to determine an unmapped physical address indicating that the corresponding block is blank, and perform remapping using the physical address value. The net effect of this remapping is to remap the logical address to a spare blank block in multiple blocks, making the data in block (block 1) inaccessible, and read requests will return empty or blank data.

[0037] In various embodiments, the local media controller 130 is adapted such that any update to the programming of the physical address field caused by a bad block error is a one-way update, meaning that any subsequent request to change the physical address field will be masked or rejected by the local media controller 130. This can be imposed by the local media controller 130 checking for a fixed bit pattern or the reason for a previous update (e.g., in the factory / indicator field) and preventing subsequent updates. In this way, the data associated with the bad block remains inaccessible. Furthermore, subsequent read requests directed to the block can enable the detection of a fixed data pattern in a field of the ROM block associated with the block. The local media controller 130 can then return the read error to the processing apparatus, replacing any data stored in the block.

[0038] Furthermore, in additional or alternative embodiments, controller 115 further generates a hash-based message authentication code (HMAC) associated with an error code for the block, receiving the error code in response to a failure of a block erase operation on the block. The HMAC may be generated as, for example, a keyed one-way hash of a combination of a physical address (or a cryptographic version of a physical address) and a logical address. Local media controller 130 may further store the HMAC in the physical address field of the ROM as a fixed data pattern or in another field indexed to the block (e.g., block 1). Using HMAC can be an additional or alternative way to prevent the system agent from rolling back ROM block updates when attempting to access unerased data from a failed block erase operation.

[0039] Figure 2 This is a flowchart of an example method 200 for processing poorly grown blocks generated during a block erasure operation, according to some embodiments of the present disclosure. Method 200 may be executed by processing logic, which may include hardware (e.g., processing means, circuitry, dedicated logic, programmable logic, microcode, device hardware, integrated circuits, etc.), software (e.g., instructions that run or execute on a processing means) or a combination thereof. In some embodiments, method 200 is performed by… Figures 1A to 1B The process is executed by controller 115 (e.g., error determination component 113) and / or local media controller 130. While shown in a specific order or sequence, the order of the processes may be modified unless otherwise specified. Therefore, it should be understood that the illustrated embodiments are merely examples, and the illustrated processes may be executed in different orders, and some processes may be executed in parallel. Additionally, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0040] At operation 210, the processing logic performs an erase of at least a portion of the memory component of the memory array containing multiple blocks. As discussed, this erase can be a secure or clear block erase operation, such as one initiated by the controller 115 of the memory subsystem 110 (e.g., initiated with an erase command). At operation 220, the processing logic detects an error code in response to a failure to erase blocks among the multiple blocks. For example, the control logic of the local media controller 130 may send an error code (or other flag) to notify the controller 115 that all blocks could not be erased. Failure to completely erase blocks can be extended to failure to completely erase additional blocks, but reference to blocks is used for simplicity.

[0041] For further reference Figure 2At operation 230, in response to an error code, the processing logic sends a blocking command to the control logic coupled to the memory array 140, preventing access to the block via the data interface that couples the processing device (e.g., controller 115) to the control logic. This blocking command (e.g., a second command different from the erase command) can prevent the reference... Figure 3 (Fuse blow command) and Figure 4 (Update ROM command) One of at least two commands discussed in more detail. The Fuse Blow command causes the control logic to blow the fuse that couples controller 115 to the block. The Update ROM command causes the control logic to update the programming of the ROM to replace the mapping information from logical addresses to physical blocks, such as mapping logical addresses to blank blocks or programming the mapping to a fixed data pattern that indicates no access to the block.

[0042] At operation 240, processing logic (e.g., control logic of local media controller 130) blocks access to the block relative to future memory operations directed to the block. For example, the control logic may blow a fuse coupled to the block, as referenced... Figure 3 The discussion may involve updating the programming of ROM blocks to replace the block's mapping information, as described in the reference. Figure 4 As discussed above. At operation 250, the processing logic may report to the host system 120 that the erase command has been completed after successfully completing the blocking command (and any other related blocking commands associated with different memory blocks that were not completely erased). In this way, the host system 120 knows that the erase command has been successfully completed, rather than receiving bad block-related errors that could otherwise generate AFR events.

[0043] Figure 3 This is a flowchart of an example method 300 for processing poorly grown blocks generated during a block erasure operation, according to some embodiments of the present disclosure. Method 300 may be performed by processing logic, which may include hardware (e.g., processing device, circuit system, dedicated logic, programmable logic, microcode, device hardware, integrated circuit, etc.), software (e.g., instructions that run or execute on the processing device), or a combination thereof. In some embodiments, method 300 is performed by… Figures 1A to 1B The process is executed by controller 115 (e.g., error determination component 113) and / or local media controller 130. While shown in a specific order or sequence, the order of the processes may be modified unless otherwise specified. Therefore, it should be understood that the illustrated embodiments are merely examples, and the illustrated processes may be executed in different orders, and some processes may be executed in parallel. Additionally, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0044] At operation 310, the processing logic receives an erase command associated with a memory array of multiple blocks. As discussed, this erase command may be a secure or clear block erase operation, such as one initiated by controller 115. At operation 320, in response to receiving the erase command, the processing logic attempts to erase blocks from the memory array. If the block is completely erased, the local media controller 130 may report a success code to controller 115 to indicate that the block has been successfully erased. However, if the block is not completely erased, the local media controller 130 may detect an error (e.g., using an error code or other indication that the erase operation failed) and report the error to controller 115. Therefore, at operation 330, the processing logic may detect and report that the block was not completely erased (e.g., by means of an error code). Failure to erase a block can extend to failure to completely erase additional blocks, but reference to a block is used for simplicity.

[0045] For further reference Figure 3 At operation 340, the processing logic receives a fuse-blowing command in response to a failure to erase the block. In one embodiment, controller 115 sends a fuse-blowing command to local media controller 130, wherein the fuse-blowing command may contain a specific fuse (e.g., with...). Figure 1B The instruction is given for the fuse coupled to block 1 in the memory controller. At operation 350, the processing logic can blow the fuse coupled to block 1 among a plurality of fuses 160, so that the block cannot be accessed by, for example, local media controller 130 and therefore also cannot be accessed by controller 115 (or another coupled device attempting to access via ONFI 125). For example, the control logic of local media controller 130 can blow the fuse coupled to block 1 so that the block cannot be physically and / or electrically accessed by the memory controller (e.g., controller 115). Thus, any future access attempts to the block (e.g., block 1) can be blocked by the blown fuse, and an error code regarding the inaccessibility of the block is sent from local media controller 130 to controller 115.

[0046] Figure 4 This describes an example method 400 for determining whether to process poorly grown blocks generated during a block erasure operation, according to other embodiments of the present disclosure. Method 400 may be executed by processing logic, which may include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, device hardware, integrated circuits, etc.), software (e.g., instructions that run or execute on the processing device), or a combination thereof. In some embodiments, method 400 is performed by… Figures 1A to 1BThe process is executed by controller 115 (e.g., error determination component 113) and / or local media controller 130. While shown in a specific order or sequence, the order of the processes may be modified unless otherwise specified. Therefore, it should be understood that the illustrated embodiments are merely examples, and the illustrated processes may be executed in different orders, and some processes may be executed in parallel. Additionally, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are possible.

[0047] At operation 410, the processing logic receives an erase command associated with a memory array of multiple blocks. As discussed, this erase command may be a secure or erase block erase operation, such as one initiated by controller 115. At operation 420, in response to receiving the erase command, the processing logic attempts to erase blocks from the memory array. If the block is completely erased, the local media controller 130 may report a success code to controller 115 to indicate that the block has been successfully erased. However, if the block is not completely erased, the local media controller 130 may detect an error (e.g., using an error code or other indication that the erase operation failed) and report the error to controller 115. Therefore, at operation 430, the processing logic may detect and report that the block was not completely erased (e.g., by means of an error code). Failure to erase a block can extend to failure to completely erase additional blocks, but reference to blocks is used for simplicity.

[0048] At operation 440, the processing logic receives an update ROM command in response to a failure to erase the block. In one embodiment, controller 115 sends the update ROM command to local media controller 130, wherein the update ROM command may contain instructions on which block mapping will be reprogrammed and how to reprogram it, as will be described. At operation 450, in response to the update ROM command, the processing logic updates the programming of the ROM block to replace the block's mapping information, making the block inaccessible (e.g.) by local media controller 130 and therefore also inaccessible by controller 115 (or other coupled devices attempting to access it via ONFI 125). For example, in one embodiment, the mapping information is updated to remap a logical address instead of a spare blank block. In another embodiment, the mapping information is replaced with a fixed data pattern within a field of the ROM associated with the block, wherein the fixed data pattern indicates that the block should not be accessed (see Table 1 and associated description). Thus, any future access attempts to the block can be blocked by referring to the mapping information in the ROM, and an error code regarding the inaccessibility of the block can be sent from local media controller 130 to controller 115.

[0049] Figure 5An example machine is described as representing computer system 500, within which a set of instructions is executable to cause the machine to perform any one or more of the methods discussed herein. In some embodiments, computer system 500 may correspond to a host system (e.g., Figure 1A The host system 120 includes, is coupled to, or utilizes a memory subsystem (e.g., Figures 1A to 1B The memory subsystem 110) or can be used to perform operations of the controller 115 (e.g., to execute an operating system to perform operations corresponding to...). Figure 1A (Operation of error determination component 113). In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, intranet, extranet, and / or the Internet. The machine may operate as a peer machine in a peer-to-peer (or distributed) network environment or as a server or client machine in a cloud computing infrastructure or environment, operating at the capacity of a server or client machine in a client-server network environment.

[0050] The machine may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, web application, server, network router, switch, or bridge, or any machine capable of executing (sequentially or otherwise) a set of instructions specifying actions to be taken by said machine. Furthermore, although a single machine is described, the term "machine" should also be considered to include any collection of machines that individually or collectively execute a set (or more) of instructions to perform any or more of the methods discussed herein.

[0051] The example computer system 500 includes a processing device 502, a main memory 504 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM)), a static memory 506 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 518, which communicate with each other via a bus 530.

[0052] Processing device 502 represents one or more general-purpose processing devices, such as microprocessors, central processing units, etc. More specifically, the processing device may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets, or a combination of instruction sets. Processing device 502 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 502 is configured to execute instructions 526 for performing the operations and steps discussed herein. Computer system 500 may further include a network interface device 508 for communication via network 520.

[0053] Data storage system 518 may include machine-readable storage medium 524 (also referred to as computer-readable medium) on which one or more sets of instructions 526 or software embodying any one or more of the methods or functions described herein are stored. The instructions 526 may also reside wholly or at least partially within main memory 504 and / or processing device 502 during execution by computer system 500, the main memory 504 and processing device 502 also constituting machine-readable storage medium. Machine-readable storage medium 524, data storage system 518 and / or main memory 504 may correspond to... Figures 1A to 1B The memory subsystem 110.

[0054] In one embodiment, instruction 526 includes implementing a component corresponding to the error determination component (e.g., Figure 1A The error determination component 113) or the firmware of the local media controller 130 contains functional instructions. Although the machine-readable storage medium 524 is shown as a single medium in the exemplary embodiment, the term "machine-readable storage medium" should be considered to include a single medium or multiple media storing one or more sets of instructions. The term "machine-readable storage medium" should also be considered to include any medium capable of storing or encoding a set of instructions executable by a machine and causing the machine to perform any one or more of the methods of this disclosure. Therefore, the term "machine-readable storage medium" should be considered to include, but is not limited to, solid-state memory, optical media, and magnetic media.

[0055] Some parts of the previously described algorithms and symbolic representations of operations on data bits within computer memory have been presented. These algorithmic descriptions and representations are the means by which those skilled in the art of data processing most effectively communicate the essence of their work to others skilled in the art. In this document, and generally in general, an algorithm is conceived as a self-consistent sequence of operations that produce a desired result. An operation is an operation that requires physical manipulation of a physical quantity. Typically (but not always), these quantities take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. It has been shown that it is sometimes convenient to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc., primarily for common use.

[0056] However, it should be remembered that all these and similar terms will be associated with appropriate physical quantities and are merely convenient notations for application to those quantities. This disclosure may refer to the actions and processes of a computer system or similar electronic computing device that manipulate and transform data represented as physical (electronic) quantities in the registers and memories of the computer system into other data similarly represented as physical quantities in the computer system's memory or registers or other such information storage systems.

[0057] This disclosure also relates to apparatus for performing the operations described herein. Such apparatus may be specifically constructed for the desired purpose, or may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. This computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards or optical cards, or any type of media suitable for storing electronic instructions, each connected to a computer system bus.

[0058] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used with the programs taught herein, or it may prove convenient to construct more specialized devices to perform the methods described herein. The structures of various such systems will be presented as illustrated in the description below. Furthermore, this disclosure is described without reference to any particular programming language. It should be understood that the teachings of this disclosure as described herein can be implemented using various programming languages.

[0059] This disclosure may be provided as a computer program product or software, which may include machine-readable media on which instructions are stored for programming a computer system (or other electronic device) to perform processes according to this disclosure. Machine-readable media includes any means for storing information in a machine-readable (e.g., computer-readable) form. In some embodiments, machine-readable (e.g., computer-readable) media includes machine-readable (e.g., computer-readable) storage media, such as read-only memory (“ROM”), random access memory (“RAM”), disk storage media, optical storage media, flash memory components, etc.

[0060] In the foregoing description, embodiments of this disclosure have been described with reference to specific example embodiments thereof. It will be apparent that various modifications may be made to this disclosure without departing from the broader spirit and scope of the embodiments set forth in the appended claims. Therefore, the description and drawings should be viewed in an illustrative rather than restrictive sense.

Claims

1. A memory component comprising: a plurality of fuses; a memory array comprising a plurality of blocks; and control logic operatively coupled with the memory array and the plurality of fuses to: receive a wipe command associated with the memory array; in response to receiving the wipe command, attempt to wipe a block of the plurality of blocks from the memory array; detect a failure to completely wipe the block; receive a blow fuse command in response to the failure to completely wipe the block; and in response to receiving the blow fuse command, blow a fuse of the plurality of fuses coupled with the block to render the block electrically inaccessible by the control logic.

2. The memory component of claim 1, wherein the plurality of blocks each comprise one or more NAND memory cells.

3. The memory component of claim 1, further comprising an open NAND flash interface (ONFI) coupled between a processing device and the control logic, wherein the control logic comprises a hardware state machine that translates commands from the ONFI to accesses of the memory array, and wherein the blown fuse renders the block electrically inaccessible via the ONFI.

4. The memory component of claim 1, wherein a respective fuse of the plurality of fuses is operatively coupled between a respective block of the plurality of blocks and the control logic, and wherein blowing the fuse electrically disconnects the block from the control logic.

5. The memory component of claim 1, wherein the control logic further: receives a read request directed to the block from a processing device; detects that the fuse has been blown; and returns a read error to the processing device in place of any data stored in the block.

6. A memory component comprising: a memory array comprising a plurality of blocks; a read-only memory (ROM) block storing a logical-to-physical address map of the plurality of blocks of the memory array; and control logic operatively coupled with the memory array and the ROM block, the control logic to: receive a wipe command associated with the memory array; in response to receiving the wipe command, attempt to wipe a block of the plurality of blocks from the memory array; detect a failure to completely wipe the block; receive an update ROM command in response to the failure to completely wipe the block; and update programming of the ROM block to replace mapping information of the block that renders a physical address of the block inaccessible by the control logic.

7. The memory component of claim 6, wherein replacing the mapping information of the block is to remap the block to a spare blank block of the plurality of blocks. ​ ​ ​ ​ 8. The memory component of claim 6, further comprising an open NAND flash interface (ONFI) coupled between a processing device and the control logic, wherein the control logic comprises a hardware state machine that translates commands from the ONFI into accesses to the memory array, and wherein updating the programming of the ROM block makes the block inaccessible via the ONFI.

9. The memory component of claim 6, wherein the ROM block comprises a plurality of fields each corresponding to a respective block of the plurality of blocks, and wherein to update the programming of the ROM block, the control logic writes a fixed data pattern to a first field of the plurality of fields corresponding to the block, wherein the fixed data pattern indicates that the block is not to be accessed.

10. The memory component of claim 9, wherein the control logic further denies a request from the control logic to update the first field of the ROM block in response to the request, and prevents the first field from being further updated based on the fixed data pattern.

11. The memory component of claim 9, wherein a processing device coupled to the control logic further generates a hash-based message authentication code (HMAC) associated with an error code of the block, and wherein the control logic further stores the HMAC in the first field of the ROM as the fixed data pattern.

12. The memory component of claim 9, wherein the control logic further: receives a read request from a processing device directed to the block; detects that the fixed data pattern is stored in the first field of the plurality of fields of the ROM block; and returns a read error to the processing device in place of any data stored in the block.

13. A method for operating a memory, comprising: receiving, by control logic of a memory component, an erase command to erase at least a portion of the memory component comprising a memory array having a plurality of blocks; attempting, by the control logic, to erase a block of the plurality of blocks in response to receiving the erase command; detecting, by the control logic, a failure to completely erase the block; receiving, by the control logic, a blow fuse command in response to the failure to completely erase the block to make the block inaccessible via a data interface coupling a processing device to the control logic; and blowing, in response to receiving the blow fuse command, a fuse of a plurality of fuses coupled with the block to make the block electrically inaccessible by the control logic.

14. The method of claim 13, wherein respective fuses of the plurality of fuses are operatively coupled between respective blocks of the plurality of blocks and the control logic, and wherein blowing the fuse comprises electrically disconnecting the block of the plurality of blocks from the control logic.

15. The method of claim 13, further comprising: receiving, from the processing device, a read request directed to the block; ​ detecting that the fuse has blown; and returning a read error to the processing device in place of any data stored in the block.

16. A method for operating a memory, comprising: receiving, by control logic of a memory component, an erase command to erase at least a portion of the memory component including a memory array having a plurality of blocks; attempting, by the control logic, to erase a block of the plurality of blocks in response to receiving the erase command; detecting, by the control logic, a failure to completely erase the block; receiving, by the control logic, an update read-only memory (ROM) command in response to the failure to completely erase the block; and updating, by the control logic, a programming of a ROM block that stores a logical-to-physical address mapping of the plurality of blocks of the memory array on the memory component, wherein updating includes replacing mapping information of the block such that a physical address of the block is inaccessible by the control logic.

17. The method of claim 16, wherein the ROM block includes a plurality of fields each corresponding to a respective block of the plurality of blocks, and wherein updating the programming of the ROM block includes writing a fixed data pattern to a first field of the plurality of fields corresponding to the block, wherein the fixed data pattern indicates that the block is not to be accessed.

18. The method of claim 17, wherein the method further comprises denying a request to update the first field in response to the request, and preventing further updates to the first field based on the fixed data pattern.

19. The method of claim 17, further comprising: receiving, from a processing device coupled with the memory component, a read request directed at the block; detecting that the fixed data pattern is stored in the first field of the plurality of fields of the ROM block; and returning a read error to the processing device in place of any data stored in the block. ​

Images