Method for testing solid state drives

Abstract

This application discloses a testing method for solid-state drives (SSDs), relating to the field of electronic digital data processing technology. It separates the business context of a test task from the hardware command execution logic into two independent firmware process control units. The task-level context is independently maintained by the task-level firmware process control unit, and the lifecycles of the two types of units are isolated. Upon completion of hardware testing, only the command-level units are recycled without destroying the upper-level task objects, thus avoiding entanglement between task logic and hardware scheduling logic. This solves the technical problems in related technologies where multiple logics of test task management and hardware command scheduling are coupled during SSD testing, leading to task context loss, chaotic task management, poor test recycling and reuse logic, and poor execution stability of SSD test tasks. It achieves decoupling of test task management and hardware command scheduling, ensuring that the task context is not interfered with by the hardware execution process, and improving the overall execution stability of SSD test tasks.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing technology, and in particular to testing methods for solid-state drives. Background Technology

[0002] In related technologies, solid-state drive (SSD) reliability testing solutions often involve inter-coupling of test task management and hardware command scheduling. The lifecycles of test tasks and underlying hardware commands cannot be decoupled, resulting in complex test process state switching logic. Task scheduling, state transitions, and hardware action execution become entangled, which can easily lead to problems such as task context loss, chaotic task management, poor test recycling and reuse logic, and poor SSD test task execution stability. These issues urgently need improvement. Summary of the Invention

[0003] This application provides a testing method for solid-state drives (SSDs) to at least address the technical problems in related technologies, such as the coupling of multiple logics between test task management and hardware command scheduling during SSD testing, leading to task context loss, chaotic task management, poor test recycling and reuse logic, and poor execution stability of SSD test tasks.

[0004] This application provides a testing method for solid-state drives (SSDs), applied to a two-level state machine constructed by a task-level firmware process controller and a command-level firmware process controller. The method includes: responding to a SSD test task; extracting any target task-level firmware process control unit from the free list of the task-level firmware process controller; determining corresponding target task data in the target task-level firmware process control unit based on the channel identifier of the test task and the target task-level firmware process control unit; extracting any target command-level firmware process control unit from the free list of the command-level firmware process controller; writing the identifier of the target command-level firmware process control unit to the sub-firmware process control list of the target task-level firmware process control unit; writing a predecessor state, a successor state, a callback function, and a process control function into the target command-level firmware process control unit; based on the predecessor state, successor state, callback function, process control function, and the test mode of the test task, guiding the target command-level firmware process control unit and the hardware corresponding to the test task to execute corresponding test actions on test blocks that meet preset valid conditions until the test actions are completed; and controlling the target command-level firmware process control unit to execute corresponding release and recycling actions to generate the SSD test results.

[0005] This application also provides a solid-state drive (SSD) testing apparatus applied to a two-level state machine constructed from a task-level firmware flow controller and a command-level firmware flow controller. The apparatus includes: a first extraction module, configured to, in response to a SSD testing task, extract any target task-level firmware flow control unit from the free list of the task-level firmware flow controller, and determine the corresponding target task data in the target task-level firmware flow control unit based on the channel identifier of the testing task and the target task-level firmware flow control unit; and a second extraction module, configured to, extract any target command-level firmware flow control unit from the free list of the command-level firmware flow controller, and set the target command-level firmware flow control unit as the target command-level firmware flow control unit. The identifier of the target command-level firmware process control unit is written to the sub-firmware process control chain list of the target task-level firmware process control unit; the test module is used to write the predecessor state, successor state, callback function and process control function into the target command-level firmware process control unit. Based on the predecessor state, successor state, callback function, process control function and test mode of the test task, the module guides the target command-level firmware process control unit and the corresponding hardware of the test task to perform corresponding test actions on the test blocks that meet the preset valid conditions until the test actions are completed. The module also controls the target command-level firmware process control unit to perform corresponding release and recycling actions to generate the test results of the solid-state drive.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described solid-state drive testing methods.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described solid-state drive testing methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described solid-state drive testing methods.

[0009] This application allows for the separation of the business context and hardware command execution logic of test tasks into two independent firmware process control units. The task-level context is maintained independently by the task-level firmware process control unit, while state transitions, callbacks, and hardware interaction logic are centralized in the command-level firmware process control unit. The two types of units are associated only through a reference list, and their lifecycles are isolated from each other. When hardware testing ends, only the command-level units are recycled without destroying the upper-level task objects. At the same time, the units are managed using a pooled idle list to avoid entanglement between task logic and hardware scheduling logic. Therefore, it can solve the technical problems in related technologies where multiple logics of test task management and hardware command scheduling are coupled during solid-state drive testing, leading to task context loss, chaotic task management, poor test recycling and reuse logic, and poor execution stability of solid-state drive test tasks. It achieves decoupling of test task management and hardware command scheduling, isolates the task business context from the hardware state transition logic, ensures that the task context is not interfered with by the hardware execution process, enables the recycling and reuse of execution units, and improves the overall execution stability of solid-state drive test tasks. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic diagram illustrating the principle of a solid-state drive testing method provided in one embodiment of this application; Figure 2 A flowchart illustrating a testing method for a solid-state drive provided in an embodiment of this application; Figure 3 A flowchart of a testing method for a solid-state drive provided in one embodiment of this application; Figure 4 This is a schematic diagram of a solid-state drive testing device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] In the mass production process of solid-state drives (SSDs), the reliability demonstration test (RDT) is an essential step.

[0016] During the production phase, stress tests need to be performed on all NAND (non-volatile flash memory) flash memory, and bad blocks found during the tests need to be screened and recycled to improve product quality.

[0017] RDT (Reliable Detection and Testing) is one of the most critical testing stages in mass production. The main purpose of RDT is to screen out unqualified solid-state drives (SSDs), covering multiple dimensions such as soldering issues, flash memory issues, dynamic random access memory (DRAM) issues, and controller issues. Through RDT testing, the stability and reliability of SSDs during use can be guaranteed.

[0018] In related technologies, during RDT testing, a single task control block structure can manage both the "large state" of the test (e.g., which block is currently being tested, how many rounds have been completed) and the "small state" (e.g., whether the current erase command has been completed). This approach was adequate in the early days when there were fewer NAND types and a single test mode. However, now NAND has evolved from SLC (Single-Level Cell) to TLC (Triple-Level Cell) and then to QLC (Quad-Level Cell), with completely different programming sequences; the test modes have also changed from a single sequential erase-write-read approach to a combination of full-block mode and single-block sequential mode. The original task control block has become increasingly bloated, with state transition logic crammed with various conditional branches, leading to increased software complexity and poor scalability.

[0019] Therefore, this leads to many problems in the related technologies. For example, the task state and command state are too tightly coupled. A single structure is responsible for both the progress of the entire test task and the state of a single command. After erasing the command, the fields related to the test progress also need to be modified. The extensibility is poor. Adding a new test mode often requires major changes to the core scheduling logic, resulting in low code reuse. Debugging is difficult. State information of different granularities is mixed together, making it difficult to quickly locate whether the error is at the command execution level or the task scheduling level. Resource management is chaotic. Long-lifecycle test resources and short-lifecycle command resources use the same allocation and reclamation mechanism, which can easily lead to resource leaks or contention.

[0020] To address the aforementioned issues, embodiments of this application provide a testing method for solid-state drives (SSDs) that can separate the state of the test task and the state of the NAND command, placing them into two data structures of different granularities.

[0021] The task-level firmware flow controller (MainFFC) stores long-lifecycle test contexts, while the command-level firmware flow controller (SubFFC) stores short-lifecycle command execution states. Both the task-level firmware flow controller (MainFFC) and the command-level firmware flow controller (SubFFC) have unit pools, which include multiple task-level firmware flow control units and multiple command-level firmware flow control units. The two pools are managed independently and linked by a one-way pointer, facilitating expansion and rapid fault location.

[0022] Before describing the testing method for the solid-state drive in the embodiments of this application, the two-level state machine consisting of the task-level firmware flow controller (MainFFC) and the command-level firmware flow controller (SubFFC) in the embodiments of this application will be described first.

[0023] like Figure 1 As shown, state machine A in this embodiment includes multiple task-level firmware process control units (a1-a2). n The task-level firmware process controller (MainFFC) A1 unit pool is equipped with multiple command-level firmware process control units (b1-b). n The cell pool of the command-level firmware process controller (SubFFC) B1.

[0024] Each task-level firmware process control unit stores information needed for a test task from start to finish, i.e., task data, including: the physical block number currently being tested, the channel and chip select on which it is on, the page currently being written to, the page currently being read from, and the data buffer address. This information remains largely unchanged throughout the test or changes regularly (e.g., the program number increments), and does not need to be rebuilt for every command.

[0025] Each command-level firmware process control unit stores information about a single command within its lifecycle, including: the current stage (preparing to execute an erase command, erase completed and waiting for programming, programming completed and waiting to be read), which callback is invoked after the command is completed, the next state to proceed to, and a pointer to the corresponding task-level firmware process control unit.

[0026] The cell pools of the task-level firmware flow controller (MainFFC) A1 and the command-level firmware flow controller (SubFFC) B1 are separate. Dozens of cells are pre-allocated in MainFFC A1, and more are pre-allocated in SubFFC B1. The allocation and recycling interfaces are independent, and their locks are also independent. When running the RDT in parallel on multiple cores, the allocation of task-level firmware flow control units and the allocation of command-level firmware flow control units will not compete for the same lock.

[0027] The task-level firmware process control unit does not have explicit status enumeration values; the current stage of the task is implicitly indicated by a combination of its field values. For example, to determine whether it is currently erasing or reading, you can first confirm whether it has started programming.

[0028] The command-level firmware process control unit has explicit status fields, such as "erase status", "programming status", and "read status", and the status transitions are clear.

[0029] The flow control function first checks the current state of the command-level firmware flow control unit, then retrieves the necessary context from its associated task-level firmware flow control unit, combines it into command parameters, and sends it to the NAND controller. Simultaneously, the ID (identifier) ​​of the command-level firmware flow control unit is written into the command header. This way, when the command completes, the completion message will include this ID, allowing the firmware to identify which command was completed.

[0030] After receiving the message, the message processing function locates the command-level firmware process control unit based on the ID in the message. It first calls the completion callback function stored in the command-level firmware process control unit (to perform status parsing, record faults, and potentially update the bad block bitmap), and then calls the process control function. The process control function checks the "next step status" configured in the command-level firmware process control unit. If it indicates erase complete, it sends the programming command; if programming complete, it sends the read command; and if reading complete, it terminates and releases resources. If the command queue is full and cannot be sent temporarily, the command-level firmware process control unit is added to a Pending queue, and retrying when the queue becomes available.

[0031] Throughout the process, the task-level firmware process control unit only handles "what," while the command-level firmware process control unit only handles "how." The two layers are linked unidirectionally via pointers—the command-level firmware process control unit can read data from the task-level firmware process control unit, without needing to know which command-level firmware process control units are currently using it. This way, when errors in the command layer need to be corrected, there's no need to consult the task-level firmware process control unit's code; and when the scheduling strategy for test tasks needs to be changed, there's no concern about affecting command execution.

[0032] The global control structure stores whether the current mode is full-scale test mode or single-unit test mode. Event handlers, based on the mode flag, select and call different command-level firmware process control unit entry functions when starting a new task. Both modes use the same unit pool of the task-level firmware process controller (MainFFC) A1. Information such as block numbers and channel numbers in the task-level firmware process control unit is naturally inherited during mode switching and does not need to be re-entered. Adding a new mode only requires writing the corresponding entry function and command-level firmware process control unit configuration; the framework layer remains unchanged.

[0033] like Figure 2 As shown, the solid-state drive testing method of this application embodiment is applied to a two-level state machine constructed by a task-level firmware flow controller and a command-level firmware flow controller, wherein the method includes: In step S201, in response to the solid-state drive test task, any target task-level firmware process control unit is extracted from the idle list of the task-level firmware process controller, and the corresponding target task data is determined in the target task-level firmware process control unit based on the channel identifier of the test task and the target task-level firmware process control unit.

[0034] In actual execution, the embodiments of this application can, after receiving the test task, first take a target task-level firmware process control unit from the free list of the task-level firmware process controller (MainFFC), fill in the task data, including block number, channel, chip select, etc., calculate the offset of the data buffer address according to the channel number (channel identifier) ​​to avoid overlap, and then determine the target task data, set the program number to 1, and set the page number to 0.

[0035] The task-level firmware process control unit header contains a unique ID, a task type identifier, and pointers to the previous and next nodes in a linked list (addresses). Following the header is a dedicated RDT information block: physical address information (block number, channel, chip select, block type), a data buffer address array (at least 3 bytes in size, as one TLC wordline corresponds to 3 pages), progress information (current programming number, current page number to be written, current page number to be read), and programming parameters (coarse / fine programming flags, number of pages to be written).

[0036] Optionally, in one embodiment of this application, before responding to a test task, the method further includes: determining the initial memory requirement of the task-level firmware process control unit based on a pre-set storage form of the task-level firmware process control unit; aligning the initial memory requirement up to the cache line of the central processing unit to obtain the actual memory requirement of the task-level firmware process control unit; determining the total memory requirement of the task-level firmware process controller in conjunction with a preset allocation quantity; segmenting the task-level firmware process controller, allocating the segmented task-level firmware process control units, setting an identifier for each task-level firmware process control unit, and adding the task-level firmware process control unit to the free list of the task-level firmware process controller.

[0037] Before conducting a test task, embodiments of this application may initialize the cell pool of the task-level firmware flow controller (MainFFC) and the cell pool of the command-level firmware flow controller (SubFFC).

[0038] When initializing the cell pool of the task-level firmware flow controller (MainFFC), the memory size required for each task-level firmware flow control unit can be determined first, and aligned upwards to the CPU cache line (usually 64 bytes). Then, a contiguous block of memory is allocated, the size of which is equal to the aligned cell size multiplied by the pre-allocated number. During allocation, a global offset is used to record the progress. Each allocation involves locking, acquiring memory from the current offset, updating the offset, and releasing the lock, ensuring no conflict across multiple cores. After acquiring the contiguous memory, it is divided into task-level firmware flow control units, and each is assigned an ID and pushed onto the free list.

[0039] The initialization of the cell pool for the command-level firmware process controller (SubFFC) is similar, using a separate memory region, a separate offset, and a separate lock.

[0040] In this embodiment, the memory of the task-level firmware process control unit is aligned with the central processing unit cache line, which can improve firmware memory access efficiency and reduce cache jitter. By constructing a free linked list, it can provide a basis for quickly extracting units for subsequent test tasks.

[0041] In step S202, any target command-level firmware process control unit is extracted from the free list of the command-level firmware process controller, and the identifier of the target command-level firmware process control unit is written to the sub-firmware process control list of the target task-level firmware process control unit.

[0042] Take a target command-level firmware process control unit from the free list of the unit pool of the command-level firmware process controller (SubFFC), and add the ID (identifier) ​​of the target command-level firmware process control unit to the subFFC (firmware process control) list of the target task-level firmware process control unit for binding. Leave a record in the target task-level firmware process control unit so that the record can be cleared when the target command-level firmware process control unit finishes processing the task, making it easy to determine which target command-level firmware process control units have completed the task and which have not.

[0043] The header of the target command-level firmware process control unit includes a unique ID, task type identifier, predecessor status, successor status, completion callback function pointer, process control function pointer, and a pointer to the associated target task-level firmware process control unit. Following the header is command-specific content, such as a counter recording how many times this target command-level firmware process control unit has been used (some commands generate two completion notifications).

[0044] In step S203, the predecessor state, successor state, callback function, and flow control function are written into the target command-level firmware flow control unit. Based on the predecessor state, successor state, callback function, flow control function, and test mode of the test task, the target command-level firmware flow control unit and the hardware corresponding to the test task are guided to perform corresponding test actions on the test blocks that meet the preset valid conditions until the test actions are completed. The target command-level firmware flow control unit is then controlled to perform corresponding release and recycling actions to generate the test results of the solid-state drive.

[0045] As one possible implementation method, the target command-level firmware process control unit can be configured. For example, before the target command-level firmware process control unit performs a test action, the predecessor state is set to "initial" and the successor state is set to "erase". The completion callback points to the erase processing function and the process control function points to the programming entry point (programming will begin after erasure is complete. At this time, the predecessor can be changed to erase and the successor can be changed to programming).

[0046] The process control function is invoked to obtain the block number, channel, and chip select from the target command-level firmware process control unit. The bad block bitmap is then queried. If the bad block is identified as bad based on the bitmap, the block number is incremented by 1 and the search is repeated. If the block is good, the command submission interface is invoked. If the command queue is full, the block is added to the pending queue. If there is space, the command is sent and the ID (identifier) ​​of the target command-level firmware process control unit is filled into the command header.

[0047] After each target command-level firmware process control unit completes its task, it can determine whether to execute the next test action, suspend, or release and reclaim the system based on the test mode.

[0048] After all tests are completed, the embodiments of this application can determine the test results of the solid-state drive and identify valid blocks and bad blocks.

[0049] Optionally, in one embodiment of this application, before writing the predecessor state, successor state, callback function, and flow control function, the method further includes: storing the address of the target task-level firmware flow control unit in the associated field of the target command-level firmware flow control unit; generating a callback function based on the address of the target task-level firmware flow control unit, so as to use the callback function to reply to the target task-level firmware flow control unit with the result of the test action after the target task-level firmware flow control unit completes the test action.

[0050] In some embodiments, the address (pointer) of the target task-level firmware process control unit can be stored in the associated field of the target command-level firmware process control unit, and a callback function can be generated. This allows the target command-level firmware process control unit to accurately match the corresponding upper-level test task based on the saved address of the task-level firmware process control unit after the test action is completed. The execution status and test result of this test block test are then called back to the corresponding target task-level firmware process control unit, achieving accurate binding between hardware execution results and upper-level test tasks. This avoids callback errors and task context mismatches in scenarios with multiple concurrent test tasks, ensuring the reliability of asynchronous interaction between the two levels of firmware process control units.

[0051] Optionally, in one embodiment of this application, before guiding the target command-level firmware process control unit and the hardware corresponding to the test task to perform corresponding test actions on the test blocks that meet the preset valid conditions based on the test mode of the predecessor state, successor state, callback function, flow control function and test task, the method further includes: obtaining the test bitmap of the test task; determining the test mode based on the test bitmap, wherein the test mode includes a single test mode for testing any test block and a full test mode for testing all test blocks.

[0052] This application embodiment can maintain test configuration information through a global control structure. This global control structure is configured with a test bitmap and a mode configuration array. Each bit in the test bitmap corresponds to the enable state of a test mode, and the mode configuration array is used to store configuration parameters such as the number of loop executions corresponding to each test mode. Before the solid-state drive test starts, the test bitmap is initialized and filled according to the preset test configuration switch, and the test bitmap is traversed and scanned. The test mode corresponding to the first valid bit obtained by scanning is determined as the execution mode of the current test task, thereby realizing automatic matching of single-unit test mode or full-scale test mode based on bitmap configuration, providing a mode basis for the subsequent differentiated scheduling command-level firmware process control unit to execute test block test tasks.

[0053] Optionally, in one embodiment of this application, the method further includes: when switching between single-unit test mode and full-scale test mode, maintaining the task parameters and test progress of the target task-level firmware process control unit; and continuing to execute the test task of the next test block based on the task parameters and test progress until the subtask count added according to the target command-level firmware process control unit is cleared to zero, thereby completing the test task.

[0054] In the embodiments of this application, the block progress in the target task-level firmware process control unit is not lost when switching between full test mode and single unit test mode.

[0055] For example, during initialization, if the test state was previously saved (e.g., after a power outage recovery), the previous block progress is used; a completely new start uses the configured starting block number. After the current mode's loop count is reached, the corresponding bit is cleared, the next valid bit is scanned, and the current mode identifier is updated. However, the information in the target task-level firmware process control unit is not cleared, and the block number is retained because the next mode may need to continue testing the remaining blocks. When allocating the target command-level firmware process control unit, different entry function pointers are selected based on the current mode identifier. The target task-level firmware process control unit itself does not need any changes.

[0056] After all commands in a test block have been executed, check how many unfinished rounds remain. If there are unfinished rounds, the target command-level firmware process control unit is reassigned to continue testing the next block. If not, the block enters the next mode or terminates the RDT.

[0057] Furthermore, in this embodiment of the application, the completion of the test can be determined by the subtask count in the subFFC (Firmware Flow Control) chain list of the target task-level firmware flow control unit.

[0058] In this embodiment, after extracting the target command-level firmware process control unit, the address (pointer) of the target task-level firmware process control unit is stored in its own associated field, and the identifier of the target command-level firmware process control unit is added to the sub-FFC (firmware process control) linked list of the target task-level firmware process control unit. This increments the subtask count in the sub-FFC (firmware process control) linked list by 1. When the target command-level firmware process control unit completes the test action and returns to the target task-level firmware process control unit through the callback function, the target command-level firmware process control unit can be released, and the subtask count is decremented by 1. The test is considered complete when the subtask count is cleared to zero.

[0059] In this embodiment, when dynamically switching between single-unit test mode and full-scale test mode, the test progress and task parameters of the task-level firmware process control unit can be retained. The test block number and test progress will not be reset due to the test mode switch. It supports cross-mode continuous testing and power-off recovery testing, avoiding repeated testing. Through the bidirectional association and counting increment / decrement mechanism of the two process control units, the number of unfinished subtasks of the current task can be counted. The clearing of the subtask count is used as the sole criterion for the end of the test, avoiding abnormalities such as premature test termination, task residue, and unrecovered resources, and greatly improving the reliability of test task execution.

[0060] Optionally, in one embodiment of this application, controlling the target command-level firmware process control unit to perform a corresponding release and recycling action includes: in single-unit test mode, scheduling the corresponding target command-level firmware process control unit to execute the test task of a single test block through the target task-level firmware process control unit, and controlling the target command-level firmware process control unit to release and recycle after the execution of the single test block; in full-scale test mode, scheduling the corresponding target command-level firmware process control unit to continuously execute the test tasks of multiple test blocks through the target task-level firmware process control unit, and controlling the target command-level firmware process control unit to release and recycle after all multiple test blocks have been executed, and releasing the target task-level firmware process control unit.

[0061] When releasing and recycling the target command-level firmware process control unit, embodiments of this application may perform different actions depending on the test mode.

[0062] In single-unit test mode, the target command-level firmware process control unit is scheduled to perform all test actions of erasure, programming, and reading in sequence for a single test block. After all test actions of the test block are completed, the current target command-level firmware process control unit is released and recycled, and then a new target command-level firmware process control unit is allocated to switch to execute the test task of the next test block.

[0063] In full-scale testing mode, the target task-level firmware process control unit saves the task context such as block number, channel, and chip select of each test block, and schedules the target command-level firmware process control unit to complete the erase, programming, and read operations of all test blocks in stages. Within each stage, the target command-level firmware process control unit can be reclaimed after the corresponding operation of a single test block is completed, but the target task-level firmware process control unit is not released. It is reassigned when entering the next test stage, until all test stages of all test blocks are completed, and then the target task-level firmware process control unit is released.

[0064] The embodiments of this application can configure different callback schemes for command-level firmware process control units for two test modes, thereby achieving targeted test process configuration. For the full test mode, it avoids duplicate allocation and improves test efficiency. For the single-unit test mode, it can realize the isolation of tests between blocks, which facilitates single-block debugging and fault location.

[0065] Optionally, in one embodiment of this application, controlling the release and recycling of the target command-level firmware process control unit includes: removing the target command-level firmware process control unit from the sub-firmware process control chain of the target task-level firmware process control unit; clearing the address of the callback function in the target command-level firmware process control unit; resetting the internal state of the target command-level firmware process control unit; and putting the target command-level firmware process control unit back into the free chain of the command-level firmware process controller.

[0066] In this embodiment, during release, the target command-level firmware process control unit can first be removed from the sub-FFC linked list of the target task-level firmware process control unit, its callback function pointer cleared, its state reset, and returned to the free linked list of the target command-level firmware process controller. The subtask count of the target task-level firmware process control unit is decremented by 1, and when it reaches 0, it is returned to the free linked list of the target task-level firmware process controller.

[0067] In this embodiment, the target command-level firmware process control unit can be removed from the sub-FFC linked list of the target task-level firmware process control unit during release, preventing abnormal calls to the target command-level firmware process control unit. Furthermore, the target command-level firmware process control unit can be reused through multiple allocations and reclamations, reducing resource consumption.

[0068] Optionally, in one embodiment of this application, based on the test mode of the predecessor state, successor state, callback function, flow control function, and test task, the target command-level firmware flow control unit and the corresponding hardware of the test task are guided to perform corresponding test actions on test blocks that meet preset valid conditions. This includes: controlling the target command-level firmware flow control unit to issue an erase command to the corresponding hardware for test blocks that meet preset valid conditions, so as to control the corresponding hardware to perform corresponding erase actions; controlling the target task-level firmware flow control unit to obtain the first state data returned by the corresponding hardware, so as to determine the success of the erase action based on the first state data; in the case of erase action failure, marking the test blocks that meet the preset valid conditions as not meeting the preset valid conditions, so as to add them to the bad block bitmap of the target task-level firmware flow control unit; in the case of erase action success, based on the test mode, guiding the target command-level firmware flow control unit and the corresponding hardware of the test task to perform corresponding test actions on test blocks that meet the preset valid conditions.

[0069] In actual implementation, the embodiments of this application can update the bad block bitmap based on the results of each test, thereby determining the actual test results after all test actions have been performed.

[0070] For example, after the hardware executes the erase command, it writes a message to the completion queue. In this embodiment, the completion queue can be polled. When a message is detected in the queue, the message identifier is read from the message header and used as an array index to locate the corresponding target command-level firmware process control unit. The message status is further checked. If it is "early completion" (DMA (Direct Memory Access) has ended, but NAND is still running), it returns to continue waiting for the hardware status; if it is normal completion, the completion callback of the target command-level firmware process control unit is called. Inside the callback function, the erase failure status of each plane of the test block is parsed, the bad block bitmap and global failure count are updated, and it is determined whether all planes of the test block are damaged. If there are still normal planes, the test block is retained for subsequent tests; if all planes are damaged, the block number recorded inside the target task-level firmware process control unit is incremented by 1, and the currently damaged test block is skipped.

[0071] This application embodiment can identify the result of the erasure action through the status information returned by the hardware, promptly record the test blocks that failed to erase into the bad block bitmap, screen out abnormal test blocks in advance, avoid performing invalid subsequent test processes on the failed medium, and save test costs.

[0072] Optionally, in one embodiment of this application, based on a test mode, the target command-level firmware process control unit and the hardware corresponding to the test task are guided to perform corresponding test actions on the test block that meets the preset valid conditions. This includes: in full test mode, extracting the corresponding target task data from the target task-level firmware process control unit based on the process control function, and reusing the target task-level firmware process control unit to perform programming actions corresponding to the test task on the test block; in single-unit test mode, extracting a new target command-level firmware process control unit from the free list of the command-level firmware process controller, and using the new target command-level firmware process control unit and the corresponding hardware to perform programming actions corresponding to the test task on the test block based on the target task data.

[0073] After erasure is completed, embodiments of this application can control the target task-level firmware process control unit to perform different actions according to the test mode.

[0074] In the full-scale testing mode, this application embodiment adopts a phased batch processing method to perform testing: In the first phase, all test blocks to be tested are erased sequentially. Each test block is assigned a target task-level firmware process control unit and a target command-level firmware process control unit. After erasure, the target command-level firmware process control unit is released, but the target task data such as the block number, channel, chip select, and program number recorded in the target task-level firmware process control unit are retained throughout the process. When entering the second phase of programming, the flow control function extracts the corresponding target task data from the retained target task-level firmware process control unit, reassigns the target command-level firmware process control unit to each test block, and reuses the context of the target task-level firmware process control unit to perform programming actions corresponding to the test task on the test block. After all programming is completed, the third phase of reading is entered. Similarly, reading and verification are performed sequentially based on the retained target task-level firmware process control unit context. After all three phases are completed, all target task-level firmware process control units are released uniformly.

[0075] In the unit test mode, this embodiment of the application sequentially performs erase, program, and read all test actions on the current test block. When entering the programming stage after successful erase, a new target command-level firmware process control unit is extracted from the free list of the command-level firmware process controller. Using the new target command-level firmware process control unit and the corresponding hardware, the programming action corresponding to the test task is performed on the current test block based on the target task data in the target task-level firmware process control unit. After all test actions of the current test block are completed, the target command-level firmware process control unit is released, and then it is determined whether to continue testing the next test block.

[0076] The embodiments of this application can process in stages and batches in full-scale testing mode while retaining the context of the task-level firmware process control unit throughout the process, thereby improving the execution efficiency of testing large batches of test blocks; in single-unit testing mode, the command-level firmware process control unit can be recycled in a timely manner, supporting block-by-block debugging, breakpoint resumption testing, etc., thereby improving stability and testing efficiency.

[0077] Optionally, in one embodiment of this application, performing programming actions corresponding to the test task on the test block based on target task data includes: controlling the corresponding hardware to perform programming actions on the first page of the test block that meets preset valid conditions; obtaining second status data returned by the corresponding hardware using the target task-level firmware process control unit; and, based on the second status data, determining that the programming action on the first page has failed, then performing programming actions on the second page of the test block that meets preset valid conditions, until the programming action on any page of the test block that meets preset valid conditions is successful, or, if the programming actions on all pages of the test block that meets preset valid conditions have failed, then adding the test block that meets preset valid conditions to the bad block bitmap.

[0078] After the callback function returns, this embodiment of the application can call the flow control function. At this time, the flow control function points to the programming entry point. The programming entry point identifies the subsequent state as the programming state, reads the current program number from the target task-level firmware flow control unit, queries the programming sequence table to obtain the page number and page number to be operated, and submits the programming command to the hardware. After programming is completed, the corresponding callback processing is triggered. If the programming of a single page fails, the entire test block is not directly determined to be invalid. If not all pages of the test block are damaged, the programming operation of the next page continues. If all pages of the test block fail to program, the test block is skipped. After all pages of the test block are programmed, the subsequent state is set to the reading state, and the flow control function is switched to the reading entry point. The callback is triggered after the reading stage is completed. If an uncorrectable error is detected during the reading process, the corresponding test block is marked to the bad block bitmap. After all pages are read and verified, the subsequent state is changed to the release state, and the release and recycling process of the target command-level firmware flow control unit is entered.

[0079] The embodiments of this application can distinguish between single-page failures and whole-block flash memory failures, and only mark them as bad blocks when all pages fail to be programmed. This can effectively identify the degradation of the flash memory medium and make use of the still usable storage pages in the test block.

[0080] like Figure 3 As shown, the working principle of the solid-state drive testing method of this application embodiment is explained with an example.

[0081] like Figure 3 As shown in the embodiments of this application, the target task-level firmware process control unit can provide target task data, such as context, according to the test task. The target command-level firmware process control unit can execute the corresponding test actions, and after completing the test actions, return to the target task-level firmware process control unit through a callback function, update the results, and then perform state transition to the next business stage of the test.

[0082] The timing sequence may include the following steps: Step S1: Allocate a target command-level firmware process control unit. In this embodiment, an idle target command-level firmware process control unit can be retrieved from the idle list of the command-level firmware process controller, an association relationship can be established with the target task-level firmware process control unit, and the predecessor state, successor state, and corresponding callback function can be configured.

[0083] Step S2, submit command. This application embodiment can utilize the target command-level firmware process control unit to issue hardware operation commands for erasing, programming, or reading to the hardware.

[0084] Step S3, wait for completion. Wait for the hardware to finish executing the operation command.

[0085] Step S4, callback processing. Based on the hardware completion status, a callback function is executed to obtain the test results and update the bad block bitmap, etc.

[0086] Step S5, Next State. Execute the flow control function and, based on the currently configured subsequent state, switch the test business process, jumping to subsequent processes such as erasure, programming, reading, or release and recycling.

[0087] This application embodiment can also perform multi-channel parallel testing, with each channel-chip select combination having a corresponding task-level firmware process control unit. When concurrent testing is required, all channel and chip select combinations are traversed, and one task-level firmware process control unit and one command-level firmware process control unit are assigned each time. The channel and chip select are set, and the erase command is submitted. Commands for different channels are independent, and the NAND controller can process them in parallel, with each channel operating independently in a pipeline. The completion message contains channel information, plus a message ID, which uniquely identifies which channel, which chip select, and which test task was completed. The bad block bitmap is also indexed by channel and chip select, and bad block updates for different channels do not conflict.

[0088] Specifically, depending on the different test modes, the complete test process of this application embodiment can be as follows.

[0089] Unit test mode Step S1: Retrieve the target task-level firmware process control unit from the unit pool of the task-level firmware process controller, and fill in the block number, channel, and chip select.

[0090] Step S2: Retrieve the target command-level firmware process control unit from the unit pool of the command-level firmware process controller, associate it with the target task-level firmware process control unit, configure the state as "initial → erase", and point the callback to the erase processing function.

[0091] Step S3: Call the process control function (erase entry point), submit the erase command, and the target command-level firmware process control unit enters the waiting state.

[0092] Step S4: Erasure complete, completion queue triggered, erase callback invoked: parsing status, marking bad block bitmap if failure occurs; then calling flow control function (programming entry point) to submit programming command.

[0093] Step S5, the programming process may be called multiple times (TLC block multi-round programming). Each time programming is completed, the program number of the target task-level firmware process control unit is updated in the callback until it reaches the maximum value.

[0094] Step S6: After all programming is completed, the flow control function switches to the read entry point and submits the read command.

[0095] Step S7: Read the callback verification data. If it fails, mark the bad block bitmap. After reading all pages, set the status to "Release".

[0096] Step S8: Release the target command-level firmware process control unit. Decrement the subtask count of the target task-level firmware process control unit by 1. If the count reaches 0, release the target task-level firmware process control unit. Then determine whether to continue testing the next block or enter the next round.

[0097] Full test mode Phase 1: Erase each block sequentially. Traverse all test blocks, assign a target task-level firmware process control unit and a target command-level firmware process control unit to each block, erase them, and release the target command-level firmware process control unit after completion, but retain the target task-level firmware process control unit.

[0098] Phase Two: Programming each block sequentially. A target command-level firmware process control unit is reassigned to each block, the context within the target task-level firmware process control unit is read, and programming commands are submitted.

[0099] The third stage involves reading each block sequentially. Similar to allocating the target command-level firmware process control unit, a read command is submitted, and bad blocks are marked after reading.

[0100] After the three phases are completed, release all target task-level firmware process control units.

[0101] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0102] like Figure 4 As shown, embodiments of this application also provide a solid-state drive testing apparatus 10, applied to a two-level state machine constructed from a task-level firmware process controller and a command-level firmware process controller, wherein the apparatus 10 includes: Specifically, the first extraction module 100 is used to extract any target task-level firmware process control unit from the free list of the task-level firmware process control unit in response to the test task of the solid-state drive, and determine the corresponding target task data in the target task-level firmware process control unit based on the channel identifier of the test task and the target task-level firmware process control unit.

[0103] The second extraction module 200 is used to extract any target command-level firmware process control unit from the free list of the command-level firmware process controller, and write the identifier of the target command-level firmware process control unit to the sub-firmware process control list of the target task-level firmware process control unit.

[0104] The test module 300 is used to write the predecessor state, successor state, callback function and flow control function into the target command-level firmware flow control unit. Based on the predecessor state, successor state, callback function, flow control function and test mode of the test task, it guides the target command-level firmware flow control unit and the corresponding hardware of the test task to perform corresponding test actions on the test blocks that meet the preset valid conditions until the test actions are completed. It also controls the target command-level firmware flow control unit to perform corresponding release and recycling actions to generate the test results of the solid-state drive.

[0105] Optionally, in one embodiment of this application, the solid-state drive testing apparatus 10 further includes: The storage module is used to store the address of the target task-level firmware process control unit into the associated field of the target command-level firmware process control unit.

[0106] The generation module is used to generate a callback function based on the address of the target task-level firmware process control unit. After the target task-level firmware process control unit completes the test action, the result of the test action is returned to the target task-level firmware process control unit based on the callback function.

[0107] Optionally, in one embodiment of this application, the solid-state drive testing apparatus 10 further includes: The first acquisition module is used to acquire the test bitmap of the test task.

[0108] The first determining module is used to determine the test mode based on the test bitmap, wherein the test mode includes a single-unit test mode that tests any test block and a full-scale test mode that tests all test blocks.

[0109] Optionally, in one embodiment of this application, the test module 300 includes: The first test unit is used to schedule the corresponding target command-level firmware process control unit to execute the test task of a single test block through the target task-level firmware process control unit in the single test mode, and to control the target command-level firmware process control unit to release and reclaim after the execution of a single test block.

[0110] The second test unit is used to schedule the corresponding target command-level firmware process control unit to continuously execute the test tasks of multiple test blocks through the target task-level firmware process control unit in the full test mode, and after all the test blocks have been executed, control the target command-level firmware process control unit to release and reclaim, and release the target task-level firmware process control unit.

[0111] Optionally, in one embodiment of this application, the second test unit includes: The first control subunit is used to remove the target command-level firmware process control unit from the sub-firmware process control chain of the target task-level firmware process control unit.

[0112] The clear subunit is used to clear the addresses of callback functions in the target command-level firmware process control unit.

[0113] The reset subunit is used to reset the internal state of the target command-level firmware process control unit and put the target command-level firmware process control unit back into the free list of the command-level firmware process controller.

[0114] Optionally, in one embodiment of this application, the solid-state drive testing apparatus 10 further includes: The first control module is used to maintain the task parameters and test progress of the target task-level firmware process control unit when switching between single-unit test mode and full-scale test mode.

[0115] The second control module is used to continue executing the test task of the next test block based on the task parameters and test progress, until the sub-task count added by the target command-level firmware process control unit is cleared to zero, thus completing the test task.

[0116] Optionally, in one embodiment of this application, the test module 300 includes: The first control unit is used to control the target command-level firmware process control unit to issue an erase command to the corresponding hardware that meets the preset valid conditions for the test block, so as to control the corresponding hardware to perform the corresponding erase action.

[0117] The second control unit is used to control the target task-level firmware process control unit to obtain the first status data returned by the corresponding hardware, so as to determine the success of the erasure action based on the first status data.

[0118] The marking unit is used to mark test blocks that meet preset valid conditions as not meeting preset valid conditions in the event of a failed erasure operation, so as to add them to the bad block bitmap of the target task-level firmware process control unit.

[0119] The third control unit is used to guide the target command-level firmware process control unit and the hardware corresponding to the test task to perform corresponding test actions on the test blocks that meet the preset valid conditions, based on the test mode, when the erasure action is successful.

[0120] Optionally, in one embodiment of this application, the test module 300 includes: The fourth control unit is used to extract the corresponding target task data from the target task-level firmware process control unit based on the process control function in the full test mode, and reuse the target task-level firmware process control unit to perform the programming actions corresponding to the test task on the test block.

[0121] The fifth control unit is used to extract a new target command-level firmware process control unit from the free list of the command-level firmware process controller in single-unit test mode, and use the new target command-level firmware process control unit and corresponding hardware to perform programming actions corresponding to the test task on the test block based on the target task data.

[0122] Optionally, in one embodiment of this application, the fifth control unit includes: The second control subunit is used to control the corresponding hardware to perform programming actions on the first page of the test block that meets the preset valid conditions.

[0123] The acquisition subunit is used to obtain the corresponding hardware return second status data using the target task-level firmware process control unit.

[0124] The third control subunit is used to determine, based on the second state data, that after the programming action of the first page fails, to execute the programming action on the second page of the test block that meets the preset valid conditions, until the programming action of any page in the test block that meets the preset valid conditions succeeds, or, if the programming actions of all pages in the test block that meets the preset valid conditions fail, then the test block that meets the preset valid conditions is added to the bad block bitmap.

[0125] Optionally, in one embodiment of this application, the solid-state drive testing apparatus 10 further includes: The second determining module is used to determine the initial memory requirement capacity of the task-level firmware process control unit based on the pre-set storage form of the task-level firmware process control unit.

[0126] The second acquisition module is used to align the initial memory requirement up to the cache line of the central processing unit to obtain the actual memory requirement of the task-level firmware process control unit.

[0127] The third determining module is used to determine the total memory requirement of the task-level firmware process controller by combining the preset allocation quantity.

[0128] The allocation module is used to segment the task-level firmware process controller, allocate the segmented task-level firmware process control units, set the identifier of each task-level firmware process control unit, and add the task-level firmware process control units to the free list of the task-level firmware process controller.

[0129] For a description of the features in the embodiment corresponding to the solid-state drive testing device, please refer to the relevant description in the embodiment corresponding to the solid-state drive testing method, which will not be repeated here.

[0130] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described solid-state drive testing method embodiments.

[0131] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described solid-state drive testing method embodiments when run.

[0132] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0133] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described solid-state drive testing method embodiments.

[0134] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described solid-state drive testing method embodiments.

[0135] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0136] The above provides a detailed description of a testing method for a solid-state drive (SSD) provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A testing method for a solid-state drive, characterized in that, Applied to a two-level state machine constructed from a task-level firmware flow controller and a command-level firmware flow controller, the method includes: In response to a solid-state drive test task, any target task-level firmware process control unit is extracted from the idle list of the task-level firmware process control unit. Based on the test task and the channel identifier of the target task-level firmware process control unit, the corresponding target task data is determined in the target task-level firmware process control unit. Extract any target command-level firmware process control unit from the free list of the command-level firmware process control unit, and write the identifier of the target command-level firmware process control unit into the sub-firmware process control list of the target task-level firmware process control unit. The predecessor state, successor state, callback function, and flow control function are written into the target command-level firmware process control unit. Based on the predecessor state, successor state, callback function, flow control function, and the test mode of the test task, the target command-level firmware process control unit and the hardware corresponding to the test task are guided to perform corresponding test actions on test blocks that meet preset valid conditions until the test actions are completed. The target command-level firmware process control unit is then controlled to perform corresponding release and recycling actions to generate the test results of the solid-state drive.

2. The method according to claim 1, characterized in that, Before writing the predecessor state, successor state, callback function, and flow control function, the following is also included: The address of the target task-level firmware process control unit is stored in the associated field of the target command-level firmware process control unit; Based on the address of the target task-level firmware process control unit, the callback function is generated. After the target task-level firmware process control unit completes the test action, the result of the test action is returned to the target task-level firmware process control unit based on the callback function.

3. The method according to claim 1, characterized in that, Before guiding the target command-level firmware process control unit and the hardware corresponding to the test task to execute corresponding test actions on test blocks that meet preset valid conditions, based on the test mode of the predecessor state, the successor state, the callback function, the flow control function, and the test task, the method further includes: Obtain the test bitmap for the test task; Based on the test bitmap, the test mode is determined, wherein the test mode includes a single-unit test mode that tests any test block and a full-scale test mode that tests all test blocks.

4. The method according to claim 3, characterized in that, The control unit that controls the target command-level firmware process control unit to execute the corresponding release and recycling actions includes: In the single-unit test mode, the target task-level firmware process control unit schedules the corresponding target command-level firmware process control unit to execute the test task of a single test block, and controls the target command-level firmware process control unit to release and reclaim after the execution of a single test block is completed; In the full-scale test mode, the target task-level firmware process control unit schedules the corresponding target command-level firmware process control unit to continuously execute test tasks of multiple test blocks. After all test blocks have been executed, the target command-level firmware process control unit is released and recycled, and the target task-level firmware process control unit is released.

5. The method according to claim 3, characterized in that, The release and recycling of the target command-level firmware process control unit includes: Remove the target command-level firmware process control unit from the sub-firmware process control chain of the target task-level firmware process control unit; Clear the address of the callback function in the target command-level firmware process control unit; Reset the internal state of the target command-level firmware process control unit and put the target command-level firmware process control unit back into the free list of the command-level firmware process controller.

6. The method according to claim 5, characterized in that, Also includes: When switching between the single-unit test mode and the full-scale test mode, the task parameters and test progress of the target task-level firmware process control unit are maintained. Based on the task parameters and test progress, the test task of the next test block is executed continuously until the subtask count added by the target command-level firmware process control unit is cleared to zero, thus completing the test task.

7. The method according to claim 3, characterized in that, The test mode based on the predecessor state, the successor state, the callback function, the flow control function, and the test task guides the target command-level firmware flow control unit and the hardware corresponding to the test task to execute corresponding test actions on test blocks that meet preset valid conditions, including: The target command-level firmware process control unit sends an erase command to the corresponding hardware for the test block that meets the preset valid conditions, so as to control the corresponding hardware to perform the corresponding erase action. The target task-level firmware process control unit obtains the first status data returned by the corresponding hardware, so as to determine the success of the erasure action based on the first status data; In the event that the erasure operation fails, the test block that meets the preset valid conditions is marked as not meeting the preset valid conditions and added to the bad block bitmap of the target task-level firmware process control unit; If the erasure action is successful, based on the test mode, the target command-level firmware process control unit and the hardware corresponding to the test task are guided to perform corresponding test actions on the test blocks that meet the preset valid conditions.

8. The method according to claim 7, characterized in that, Based on the test mode, the target command-level firmware process control unit and the hardware corresponding to the test task are guided to perform corresponding test actions on test blocks that meet preset valid conditions, including: In the full-scale test mode, the corresponding target task data is extracted from the target task-level firmware process control unit based on the process control function, and the target task-level firmware process control unit is reused to perform programming actions corresponding to the test task on the test block; In the single-unit test mode, a new target command-level firmware process control unit is extracted from the idle list of the command-level firmware process controller. Using the new target command-level firmware process control unit and the corresponding hardware, the test block is programmed with actions corresponding to the test task based on the target task data.

9. The method according to claim 8, characterized in that, The step of performing programming actions on the test block based on the target task data, corresponding to the test task, includes: The corresponding hardware is controlled to execute the programming action on the first page of the test block that meets the preset valid conditions; The target task-level firmware process control unit is used to obtain the corresponding hardware return second status data; Based on the second state data, after determining that the programming action of the first page has failed, the programming action is executed on the second page of the test block that meets the preset valid conditions, until the programming action of any page in the test block that meets the preset valid conditions is successful, or the programming actions of all pages in the test block that meets the preset valid conditions have failed, then the test block that meets the preset valid conditions is added to the bad block bitmap.

10. The method according to claim 1, characterized in that, Before responding to the test task, it also includes: The initial memory requirement of the task-level firmware process control unit is determined based on the pre-set storage form of the task-level firmware process control unit. The initial memory requirement is aligned upwards to the cache line of the central processing unit to obtain the actual memory requirement of the task-level firmware process control unit. Based on the preset allocation quantity, the total memory requirement of the task-level firmware process controller is determined; The task-level firmware process controller is segmented, and the segmented task-level firmware process control units are allocated. An identifier is set for each task-level firmware process control unit, and the task-level firmware process control units are added to the free list of the task-level firmware process controller.

Images