storage device

Abstract

This application provides a storage device, relating to the field of storage technology. The storage device includes a main control chip and flash memory. The main control chip includes a processor, tightly coupled memory, and a low-density parity check (LDPC) code processing module. During the card opening phase, the LPC code encodes the running code according to a first parity check mode with the strongest error correction capability. The processor writes the running code into a portion of the data area of ​​the target flash memory page and writes the first parity check code into a spare area and the space in the data area where the running code is not written. During the power-on startup phase, the running code is decoded according to the first parity check mode and loaded into the tightly coupled memory. After loading, a second parity check mode is determined based on the size of the spare area of ​​the flash memory for data encoding and decoding during normal operation. This application solves the problem in related technologies where storage devices struggle to stably complete flash memory data reading during the power-on startup phase.

Description

Technical Field

[0001] This application relates to the field of storage technology, and more specifically, to a storage device. Background Technology

[0002] Flash memory is widely used in various storage devices. To improve the reliability of data retrieval from flash memory, storage devices typically employ error correction technology to protect the data stored in the flash memory.

[0003] During the operation of the storage device, the data written to the flash memory can be encoded, and the corresponding verification information can be used to decode the data when it is read, so as to detect and correct errors in the read data.

[0004] However, during the power-on startup phase of a storage device, the operating state of the storage device differs from that during normal operation, and current data error correction methods cannot guarantee the reliable reading of the data required for startup.

[0005] Therefore, the difficulty for storage devices to reliably complete flash data reading during the power-on startup phase has become a technical problem that urgently needs to be solved. Summary of the Invention

[0006] This application provides a storage device that solves the problem in related technologies where storage devices struggle to stably complete flash memory data reading during the power-on startup phase. The technical solution is as follows:

[0007] According to one aspect of this application, a storage device includes a main control chip and flash memory, said main control chip including a processor, tightly coupled memory and a low-density parity check code processing module;

[0008] The flash memory is used to store runtime code, which is stored in a target flash page of the flash memory;

[0009] The low-density parity check code processing module is used to support multiple check modes, and encodes the running code to be written to the target flash memory page according to the first check mode during the card opening stage to obtain the first check code. The first check mode is the check mode with the strongest error correction capability among the multiple check modes.

[0010] The processor is configured to, during the card activation stage, write the running code into a portion of the data area of ​​the target flash page, and write the first verification code into the spare area of ​​the target flash page and the space in the data area of ​​the target flash page where the running code has not been written;

[0011] The processor is further configured to read the running code and the first checksum from the target flash memory page during the power-on startup phase of the storage device;

[0012] The low-density parity check code processing module is further configured to receive the running code and the first check code read by the processor, and decode the running code based on the first check code according to the first check mode.

[0013] The tightly coupled memory is used to store the running code decoded by the low-density parity check code processing module;

[0014] The processor is further configured to load the running code decoded by the low-density parity check code processing module into the tightly coupled memory, and after the running code is loaded into the tightly coupled memory, determine a second parity mode from the plurality of parity modes according to the size of the spare area of ​​the flash memory;

[0015] The low-density parity check code processing module is further configured to encode the data to be written to the flash memory according to the second verification mode during the normal operation phase of the storage device, and to decode the data read from the flash memory according to the second verification mode.

[0016] In the above technical solution, by not using the entire data area of ​​the target flash memory page to store the running code during the card opening phase, but instead utilizing the space in the data area where the running code is not written, together with the spare area, to store the first checksum, the first checksum generated by the first checksum with strong error correction capability has corresponding storage space. During the power-on startup phase, the running code is decoded using the first checksum according to the first checksum, and the decoded running code is loaded into the tightly coupled memory. After the running code is loaded, the second checksum used during normal operation is determined based on the size of the spare area of ​​the flash memory. This improves the reliability of reading and decoding the running code during the power-on startup phase of the storage device, and allows the storage device to select the appropriate checksum based on the actual storage space of the flash memory after entering the normal operation phase. Attached Figure Description

[0017] Figure 1 This is a structural block diagram of a storage device according to an exemplary embodiment;

[0018] Figure 2 This is a hardware structure diagram of a storage device shown in an application scenario;

[0019] Figure 3 This is a schematic diagram illustrating the data organization of a flash memory page in an application scenario;

[0020] Figure 4 This is a schematic diagram illustrating the card opening and power-on startup process of a storage device in an application scenario;

[0021] Figure 5This is a schematic diagram illustrating a code block structure used to store running code in an application scenario.

[0022] Figure 6 This is a schematic diagram illustrating the organization of flash memory page data during the card activation stage in an application scenario.

[0023] Figure 7 This is a schematic diagram illustrating the organization of flash memory page data during normal operation in an application scenario. Detailed Implementation

[0024] The present application will now be described in further detail with reference to the accompanying drawings and specific embodiments. Similar elements in different embodiments are referred to by related similar element reference numerals. In the following embodiments, many details are described to facilitate a better understanding of the present application. However, those skilled in the art will readily recognize that some features may be omitted in different situations, or may be replaced by other elements, materials, or methods. In some cases, certain operations related to the present application are not shown or described in the specification. This is to avoid obscuring the core parts of the present application with excessive description. For those skilled in the art, detailed description of these related operations is not necessary; they can fully understand the related operations based on the description in the specification and general technical knowledge in the art.

[0025] Furthermore, the features, operations, or characteristics described in the specification can be combined in any suitable manner to form various embodiments. At the same time, the steps or actions in the method description can be rearranged or adjusted in a manner obvious to those skilled in the art. Therefore, the various orders in the specification and drawings are only for the clear description of a particular embodiment and do not imply a necessary order, unless otherwise stated that a particular order must be followed.

[0026] The serial numbers assigned to components in this document, such as "first" and "second," are used only to distinguish the described objects and have no sequential or technical meaning. The terms "connection" and "linkage" used in this application, unless otherwise specified, include both direct and indirect connections (linkages).

[0027] The following is the applicant's research and development plan:

[0028] During their research on the power-on process of storage devices, the applicant discovered that parameters such as flash memory page size are not yet available when the storage device is first powered on, making it difficult to determine the appropriate verification mode based on the flash memory parameters. The applicant initially attempted to use a verification mode with a shorter checksum length to read the startup data, aiming to improve adaptability to different flash memory types. However, they further discovered that reducing the checksum length also reduced the hardware decoding error correction capability, and startup data reading failures could directly lead to the storage device failing to boot normally.

[0029] To improve error correction capabilities during the power-on startup phase, the applicant further attempted to encode product configuration information and operating code using a verification mode with stronger error correction capabilities during the card activation phase, enabling subsequent decoding according to the predetermined verification mode during power-on. However, in actual implementation, it was found that verification modes with stronger error correction capabilities generate longer verification codes. When valid data still occupies the data area of ​​the flash memory page in the usual way, longer verification codes may not be entirely stored in the spare area of ​​the flash memory page.

[0030] To address this issue, the applicant further noted that product configuration information and operating code are data used during the startup phase and do not need to constantly fill the flash memory page's data area like host data during normal operation. Therefore, during the card activation phase, the space occupied by product configuration information and operating code in the data area can be proactively reduced, and the freed-up data area space can be used together with the spare area to store longer verification codes.

[0031] Through the above research, the applicant's actual need is not simply to improve the error correction capability of flash memory data, but to ensure the reliable reading of the product configuration information and running code required for startup under the constraints of the power-on startup phase where complete flash memory parameters are not yet available, the checksums corresponding to stronger verification modes occupy a large amount of space, and further error correction methods such as read retries and software decoding are not yet available. Based on this, the applicant ultimately developed a complete technical solution: adopting a first verification mode during the card opening phase and releasing part of the data area space to store a longer checksum; reading product configuration information and completing the main control chip configuration according to the first verification mode during the power-on startup phase; continuing to perform hardware decoding of the running code according to the first verification mode and loading it into tightly coupled memory; and determining the second verification mode based on the size of the flash memory spare area after the running code is loaded. During normal operation, the utilization of the entire data area of ​​the flash page can be restored, and the shorter checksums generated by the second verification mode can be stored in the spare area. At the same time, combined with the already loaded read retries and / or software decoding processing, the reliability of data reading is improved, thus balancing the reliability of the power-on startup phase and the storage space utilization during normal operation.

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0033] Figure 1 This is a schematic diagram of the structure of a storage device. Figure 1As shown, the storage device 1000 may include a main control chip 1100 and a flash memory 1200. The main control chip 1100 may include a processor 1110, a tightly coupled memory 1120, and a low-density parity check processing module 1130. The flash memory 1200 may include a target flash page 1210, which may include a data area 1211 and a spare area 1212. The above reference numerals will not be repeated in the following description of the operation of the storage device.

[0034] The processor can be a Central Processing Unit (CPU) or other processing device capable of executing instructions and controlling the data read / write process in the storage device. The processor can interact with flash memory, tightly coupled memory, and low-density parity check (PDC) processing modules to control processes such as writing and reading code from flash memory, loading code, and selecting different parity check modes.

[0035] Tightly Coupled Memory (TCM) is a memory tightly coupled to the processor, providing access to executable code or data. In this embodiment, the executable code can be pre-stored in flash memory, read from flash memory during the power-on startup of the storage device, and loaded into the TCM after decoding. After the executable code is loaded into the TCM, the processor can execute the executable code in the TCM to continue the subsequent operation of the storage device.

[0036] The low-density parity-check (LDPC) processing module is a functional module that supports both LDPC encoding and decoding. It can participate in both the data writing and reading processes of the flash memory. During data writing, the data to be written to the flash memory serves as input for encoding. The LDPC processing module encodes the data according to the currently used parity mode to obtain the corresponding parity code. The data and parity code are then written to their respective storage spaces in the flash memory. During data reading, the data read from the flash memory and its corresponding parity code serve as input for decoding. The LDPC processing module decodes the read data according to the corresponding parity mode and the parity code to detect and correct any erroneous bits that may be present in the read data.

[0037] The low-density parity check (LDPC) processing module supports multiple parity check modes. Different parity check modes can use different low-density parity check matrices, corresponding to different parity check lengths and different error correction capabilities. The more parity information contained in the parity check, the larger the storage space required, and the stronger the error correction capability provided. Therefore, within the same low-density parity check processing module, multiple selectable parity check modes can be pre-set, and the appropriate parity check mode can be selected based on the current data processing stage and the parity check storage space provided by the flash memory.

[0038] Flash memory can consist of multiple flash pages. Each flash page may include a data area for storing valid data and a spare area for storing information such as checksums. The target flash page refers to the flash page used to store the running code and its first checksum in this embodiment. Typically, the valid data to be saved can be written to the data area, and the checksum obtained by encoding the valid data can be written to the spare area. Thus, when reading valid data, the corresponding checksum can be obtained and error correction can be performed simultaneously.

[0039] However, the lengths of the checksums generated by different verification modes are not the same. When a verification mode with strong error correction capabilities is used, the generated checksum requires more storage space. If the entire data area of ​​the target flash page is still used to store the running code, the space available for the checksum is mainly limited by the size of the spare area, which may prevent the running code and its checksum from being stored according to a verification mode with strong error correction capabilities. Therefore, this embodiment does not require the data area of ​​the target flash page to always be filled with running code, but rather further releases some storage space in the data area for the checksum during the card opening stage.

[0040] It should be noted that in this embodiment, the use of the space in the data area where no running code has been written to store the first checksum is not merely a reallocation of storage space within the flash memory pages. During the initial power-on startup of the storage device, the storage device has not yet completed loading the running code, and the operating conditions for flash data reading and error correction processing differ from those during normal operation. Therefore, this embodiment determines the first checksum mode used during the power-on startup phase during the card activation stage and adapts the page-level storage layout of the running code to the first checksum generated by the first checksum mode, so that the storage device can read and decode the running code according to the predetermined first checksum mode during subsequent power-on startups. After the running code is successfully loaded into the tightly coupled memory, the second checksum mode used during normal operation is determined based on the size of the spare area in the flash memory. Thus, the storage of the first checksum in the space in the data area where no running code has been written to, along with the spare area, is a storage arrangement that coordinates with the use of the first checksum mode during the power-on startup phase and the switch to the second checksum mode after startup.

[0041] Specifically, during the card activation phase, the check mode with the strongest error correction capability among the multiple check modes supported by the low-density parity check processing module can be used as the first check mode. After the execution code to be written to the target flash memory page is provided to the low-density parity check processing module, the low-density parity check processing module encodes the execution code according to the first check mode to obtain the first check code.

[0042] When storing the executable code and the first checksum, the processor can write the executable code into a portion of the data area of ​​the target flash memory page, without filling the entire data area. The space in the data area where the executable code is not written can then be used to store the first checksum. The first checksum can occupy both the spare area of ​​the target flash memory page and the space in the data area where the executable code is not written; that is, the space freed up in the spare area and the data area together form the storage space for the first checksum. This storage organization method eliminates the need for a separate limitation on the size of the original spare area of ​​the target flash memory page, thus providing the necessary storage space for the first checksum encoded according to the first checksum mode.

[0043] The aforementioned card activation stage involves the pre-encoding and storage of the runtime code and its first checksum. When the storage device is actually put into use and powered on, the runtime code already stored in the target flash memory page can be directly read and decoded according to the first checksum mode corresponding to the card activation stage, without needing to first determine the checksum mode for reading the runtime code based on the size of the flash memory's spare area.

[0044] Specifically, during the power-on startup phase of the storage device, the processor reads the running code and the first checksum from the target flash memory page. Since part of the first checksum can be located in the spare area and another part can be located in the space in the data area where the running code is not stored, the processor can obtain the running code and the corresponding first checksum according to the storage layout formed during the card opening phase, and provide the read running code and first checksum to the low-density parity check processing module.

[0045] The low-density parity check code processing module decodes the received execution code and the first check code according to the first check mode. During this decoding process, the first check code serves as the error correction basis for the execution code, used to detect and correct erroneous bits generated during flash memory storage or retrieval, thereby obtaining the decoded execution code. Since the execution code uses the corresponding first check mode for encoding and decoding during the card activation and power-on startup phases, the first check mode, with its stronger error correction capability, can be used to protect the execution code during the power-on startup phase.

[0046] After obtaining the decoded executable code, the processor loads it into tightly coupled memory. This transfers the executable code from its non-volatile storage state in flash memory to the tightly coupled memory where the processor can execute it. Once loaded, the processor can execute the executable code in the tightly coupled memory, enabling the storage device to transition from the power-on startup phase to normal operation.

[0047] It should be noted that the first parity check mode is primarily used to ensure strong error correction capabilities when reading the runtime code during the power-on startup phase. It does not require all data during normal operation to be encoded and decoded using the first parity check mode. Since different flash memory chips may offer different spare area sizes, and different parity check modes generate different checksum lengths, after the runtime code has been loaded into the tightly coupled memory, the processor can determine the second parity check mode suitable for the normal operation phase from among the multiple parity check modes supported by the low-density parity check processing module, based on the size of the spare area in the flash memory.

[0048] During normal operation, when data to be written to the flash memory exists, the low-density parity check (LDPC) processing module encodes the data according to the second parity check mode and generates a corresponding parity code. When data needs to be read from the flash memory, the LDPC processing module decodes the read data according to the second parity check mode. Thus, the first and second parity check modes correspond to different operating stages of the storage device: during the power-on startup stage, the storage layout of the pre-formed operating code and the first parity check code, generated during card activation, enables the operating code to be encoded and decoded using the first parity check mode, which has strong error correction capabilities; after the operating code has been loaded, the second parity check mode used during normal operation is determined based on the actual spare area size of the flash memory.

[0049] By employing the above method, during the card activation phase, the entire data area of ​​the target flash memory page is not used to store the runtime code. Instead, the space in the data area where the runtime code is not written is used together with the spare area to store the first checksum. This ensures that the first checksum generated by the first checksum mode, which has strong error correction capabilities, has sufficient storage space. During the power-on startup phase, the runtime code is decoded using the first checksum according to the first checksum mode, and the decoded runtime code is loaded into the tightly coupled memory. After the runtime code is loaded, the second checksum mode used during normal operation is determined based on the size of the spare area in the flash memory. This improves the reliability of reading and decoding the runtime code during the power-on startup phase of the storage device, and allows the storage device to select the appropriate checksum mode based on the actual storage space in the flash memory after entering normal operation.

[0050] In one exemplary embodiment, the low-density parity check (LDPC) code processing module may include an encoding unit and a decoding unit. The encoding unit performs low-density parity check encoding processing on the data, and the decoding unit performs low-density parity check decoding processing on the data.

[0051] Specifically, during the card opening stage, the encoding unit encodes the running code according to the first verification mode to obtain the first verification code; during the normal operation stage, the encoding unit encodes the data to be written to the flash memory according to the second verification mode.

[0052] During the power-on startup phase, the decoding unit receives the running code and the first checksum read by the processor from the target flash memory page, and decodes the running code based on the first checksum according to the first checksum mode. During the normal operation phase, the decoding unit decodes the data read from the flash memory according to the second checksum mode.

[0053] Therefore, low-density parity check processing can be completed on the data writing side and the data reading side by the encoding unit and the decoding unit respectively, and the two units can adopt the corresponding check mode according to the operating stage of the storage device.

[0054] In one exemplary embodiment, multiple parity modes can each correspond to different low-density parity-check matrices. The low-density parity-check matrix can be used to determine the parity relationship between data bits and parity bits during data encoding. For data of the same length to be encoded, encoding with different low-density parity-check matrices can generate parity codes of different lengths. Accordingly, when decoding the read data, errors can be detected and corrected based on the low-density parity-check matrix used during encoding and the corresponding length of the parity code.

[0055] There is a corresponding relationship between the checksum length and the error correction capability provided by the checksum mode. Specifically, the larger the checksum length, the more checksum information can be used for decoding, and the more error bits the corresponding checksum mode can usually correct. Therefore, among multiple checksum modes, their error correction capability can be determined based on the checksum length corresponding to each checksum mode. The checksum length corresponding to the first checksum mode is the longest among the checksum lengths corresponding to multiple checksum modes. Therefore, the first checksum mode can provide stronger error correction capability among multiple checksum modes, and in this embodiment, it is used as the checksum mode for encoding and decoding of running code during the power-on startup phase.

[0056] For example, in one implementation, the low-density parity check (PDC) processing module can support the first through fourth parity check modes. The parity check lengths for the first, second, third, and fourth parity check modes can decrease sequentially, and the corresponding error correction capabilities can also decrease sequentially. That is, the first parity check mode corresponds to the longest parity check and the strongest error correction capability, while subsequent parity check modes can reduce the storage space required for parity check in flash memory by using shorter parity check codes. The first through fourth parity check modes mentioned here are only used to illustrate the relative relationship between multiple parity check modes and do not limit the number of parity check modes supported by the low-density parity check processing module.

[0057] Furthermore, since the first verification mode has the longest checksum, it also requires the most storage space. For flash memory pages that conventionally use the data area primarily for storing valid data and the spare area for storing checksums, the storage space required for the first checksum when using the first verification mode may exceed the space that can be provided solely by the spare area. Therefore, this embodiment combines the maximum checksum length corresponding to the first verification mode with the aforementioned special storage layout of the target flash memory page: reducing the space occupied by the running code in the data area during the card activation phase, and utilizing the freed-up data area space to jointly store the first checksum with the spare area. Thus, the longer checksum corresponding to the first verification mode is not set in isolation, but rather works in conjunction with the storage method of the running code in the target flash memory page, enabling the running code to be decoded according to the first verification mode during the power-on startup phase.

[0058] In one implementation, the low-density parity check (PDC) code processing module can support multiple parity check modes, with the parity code length decreasing sequentially for each mode, and the corresponding error correction capability decreasing accordingly. For example, the parity code lengths for each mode can be represented as N, NM, N-2M, and N-3M, where N and M represent parity code length-related parameters. The parity check mode with a parity code length of N can have the strongest error correction capability among the multiple parity check modes and is used as the first parity check mode.

[0059] By configuring different low-density parity-check matrices for multiple check modes, different check modes can generate check codes of different lengths. The first check mode corresponds to the longest check code among the multiple check modes, thus providing strong error correction capabilities. Furthermore, combined with the aforementioned target flash memory page storage method, the space in the data area where no running code is written can be used in conjunction with the spare area to store the first check code corresponding to the first check mode. This ensures that the storage space for the check code matches the first check mode used during the power-on startup phase, thereby improving the reliability of reading and decoding the running code during power-on startup.

[0060] In an exemplary embodiment, when the amount of runtime code is large and needs to be stored across multiple target flash memory pages, the runtime code stored in each target flash memory page can be encoded separately. Specifically, the runtime code can be divided into multiple parts to be written to the multiple target flash memory pages. For any target flash memory page, the low-density parity check processing module encodes a portion of the runtime code to be written to that target flash memory page according to a first check mode to obtain the first check code corresponding to that target flash memory page.

[0061] For each target flash page, the processor writes a portion of the execution code into a part of the data area of ​​that target flash page, and, according to the aforementioned storage method, writes the first checksum corresponding to that target flash page into the spare area of ​​that target flash page and the space in the data area where the execution code has not been written. Thus, a correspondence is formed between a portion of the execution code and the corresponding first checksum for each target flash page.

[0062] During the power-on startup phase, the processor can sequentially read the running code and the first check code corresponding to each target flash memory page from multiple target flash memory pages. The low-density parity check processing module then decodes the running code in each target flash memory page based on the corresponding first check code to obtain the complete running code.

[0063] In the above manner, when the running code needs to occupy multiple target flash memory pages, each target flash memory page can form a storage relationship between the running code and the first check code using the first verification mode. This allows the running code stored across multiple target flash memory pages to still be read and decoded according to the first verification mode during the power-on startup phase.

[0064] In one exemplary embodiment, the flash memory may further include configuration flash pages for storing product configuration information. The product configuration information may be data used to characterize the configuration of the storage device or flash memory and for related configuration during the power-on startup process of the storage device. A configuration flash page refers to a flash page used to store the product configuration information and the corresponding checksum.

[0065] During the card activation phase, product configuration information can be provided to the low-density parity check module. The low-density parity check module encodes the product configuration information according to the first verification mode to obtain the third verification code. The third verification code is generated using the same first verification mode as the aforementioned first verification code, but the data protected by the two is different: the first verification code corresponds to the running code, while the third verification code corresponds to the product configuration information.

[0066] The processor writes product configuration information to a portion of the data area of ​​the configuration flash page, and writes the third checksum to the spare area of ​​the configuration flash page and the space in the data area where no product configuration information has been written. Thus, the configuration flash page can also utilize a portion of the data area to expand the storage space for the third checksum, enabling the product configuration information to be encoded and protected according to the first verification mode during the card activation phase, providing a data foundation for reading and using the product configuration information during the subsequent power-on startup phase.

[0067] In one exemplary embodiment, the product configuration information can be the first data read from flash memory after the storage device powers on and boots up. Here, the first data refers to the data preferentially read from flash memory after the storage device powers on and boots up, before the processor reads the execution code. Therefore, the product configuration information can be used to complete the configuration related to the storage device's boot process before proceeding with the subsequent reading of the execution code.

[0068] Specifically, during the power-on startup phase, the processor first reads the product configuration information and the corresponding third checksum from the configuration flash memory page, and then provides the read product configuration information and the third checksum to the low-density parity check processing module. The low-density parity check processing module decodes the product configuration information based on the third checksum according to the first verification mode to obtain the decoded product configuration information.

[0069] The processor receives the decoded product configuration information and configures the main control chip accordingly. This configuration can be understood as enabling the main control chip to obtain the flash memory-related configuration information required for subsequent access to the flash memory and operation of the storage device, thereby allowing the main control chip to continue executing the subsequent boot process in a manner adapted to the current flash memory. The specific content included in the product configuration information will be further explained in subsequent embodiments.

[0070] After configuring the main control chip, the processor reads the runtime code and the first checksum from the target flash memory page, and then decodes and loads the runtime code in the manner described above. Thus, the reading, decoding, and use of product configuration information precedes the reading of the runtime code, enabling the storage device to boot in the sequence of "reading product configuration information—configuring the main control chip—reading the runtime code".

[0071] In this way, after the storage device is powered on and started, the product configuration information can be reliably obtained according to the predetermined first verification mode. The main control chip is then configured using the decoded product configuration information. On this basis, the running code is then read, so that the subsequent reading of the running code is based on the fact that the main control chip has obtained the corresponding configuration information, thereby improving the stability of the power-on and startup process of the storage device.

[0072] In an exemplary embodiment, the product configuration information may include at least one of the following: storage device capacity information, number of flash memory blocks, number of flash memory pages, and flash memory page size. The capacity information can be used to characterize the data storage capacity that the storage device can provide; the number of flash memory blocks can be used to characterize the number of flash memory blocks included in the flash memory; the number of flash memory pages can be used to characterize the number of flash memory pages included in the flash memory; and the flash memory page size can be used to characterize the storage space size that a single flash memory page can provide. The processor can obtain the current flash memory organization and capacity-related parameters based on the above product configuration information and complete the corresponding configuration of the main control chip accordingly.

[0073] It's important to note that when the storage device first enters the power-on startup phase, the processor has not yet read and decoded the product configuration information from the flash memory, and therefore has not yet obtained the flash page size recorded in the product configuration information. In other words, the flash page size is not a parameter determined by the processor before reading the product configuration information; rather, it is a parameter that can only be obtained by reading and decoding the product configuration information. Therefore, before obtaining the flash page size, it cannot be used as a prerequisite for selecting the verification mode used to read the product configuration information.

[0074] Based on this, before the processor obtains the flash memory page size, the low-density parity check processing module decodes the product configuration information based on the third checksum, according to the first verification mode determined during the card opening phase. The use of the first verification mode does not rely on the processor pre-obtaining the flash memory page size during the current power-on startup process; therefore, the reading and decoding of the product configuration information can be completed first. After receiving the decoded product configuration information, the processor can obtain the flash memory page size from the product configuration information and further obtain other configuration parameters included in the product configuration information.

[0075] This creates a sequential dependency: the processor needs to decode the product configuration information to obtain the flash memory page size, but the product configuration information itself needs to be decoded before the flash memory page size is obtained. Therefore, this embodiment encodes the product configuration information according to the first verification mode during the card activation stage and continues to decode it according to the first verification mode during the power-on startup stage. This ensures that the decoding of the product configuration information does not depend on obtaining the flash memory page size in advance, thus avoiding the processing dependency of "needing to obtain the flash memory page size first to determine the verification mode, and the flash memory page size can only be obtained after the corresponding data decoding is completed."

[0076] In this way, even when the flash memory page size is not yet obtained at the initial power-on startup of the storage device, the product configuration information can be decoded according to a pre-determined first verification mode. Then, the flash memory page size can be obtained based on the decoded product configuration information, providing corresponding flash memory parameters for subsequent main control chip configuration, running code reading, and determination of the verification mode during normal operation.

[0077] In one exemplary embodiment, the main control chip may further include a read-only memory (ROM) for storing boot code. Boot code refers to the code that the processor executes first after the storage device is powered on, used to complete the basic processing of the storage device's boot phase. Compared to the aforementioned running code stored in flash memory and loaded into tightly coupled memory during power-on startup, boot code can be pre-installed in ROM, enabling the processor to directly execute the boot code after the storage device is powered on.

[0078] During the power-on startup phase, the processor executes the startup code in read-only memory and accesses flash memory during this process to read the runtime code and the first checksum from the target flash page. In other words, the process of reading the runtime code is completed by the processor based on the startup code before it is loaded into tightly coupled memory. Only after the runtime code is successfully decoded and loaded into tightly coupled memory can the processor proceed to execute the corresponding runtime code.

[0079] During the code reading process, the low-density parity check (LDPC) processing module receives the running code and the first parity check code read by the processor from the target flash memory page. Following a first parity mode, it performs hardware decoding on the running code based on the first parity check code. Hardware decoding refers to low-density parity check decoding processing based on the data read from the flash memory and the corresponding parity check code. It does not rely on further reading adjustments or software decoding processing that can only be implemented after the running code is executed. Therefore, during the power-on startup phase before the running code is loaded into the tightly coupled memory, the existing low-density parity check processing capability of the main control chip can be used to complete the error correction and decoding of the running code.

[0080] It should be noted that during the initial power-on startup phase, the processor can currently only execute the startup code in the read-only memory, while the aforementioned running code and its subsequent data reading and error correction functions have not yet been loaded into the tightly coupled memory. Therefore, the processing methods available to improve data reading reliability at this stage are relatively limited. Based on this, the aforementioned encoding of the running code according to the first verification mode during the card opening stage and providing a large storage space for the corresponding first verification code in the target flash memory page allows the low-density parity check code processing module to still utilize the first verification mode with strong error correction capabilities to correct errors in the running code even when only performing hardware decoding.

[0081] In this way, during the initial power-on startup phase before the processor has acquired and executed the running code, the running code can be read from the read-only memory by the startup code. The first verification mode is then used to perform hardware decoding on the read running code, so that the reliable reading of the running code does not depend on further error correction processing that can only be provided after the running code itself is loaded, thus providing a foundation for the successful loading of the running code into the tightly coupled memory.

[0082] In one exemplary embodiment, the running code may include at least one of read retry logic code and soft decoding logic code. The read retry logic code is used to reread the flash memory if the flash data read result does not meet the requirements; the soft decoding logic code is used to perform soft decoding processing when reading data from the flash memory to further improve the ability to correct errors in the read data.

[0083] Because the read retry logic code and the software decoding logic code are stored in the runtime code within the flash memory, the processor cannot perform the corresponding read retry processing or software decoding processing by executing the aforementioned runtime code during the initial power-on startup of the storage device, before the runtime code is loaded into the tightly coupled memory. After the runtime code completes decoding and is loaded into the tightly coupled memory as described above, the processor can execute at least one of the read retry logic code and the software decoding logic code.

[0084] Specifically, during normal operation, the storage device reads data from the flash memory according to the second verification mode. During this reading process, when it is necessary to further improve the reliability of data reading and error correction, the processor can execute at least one of read retry logic code and software decoding logic code to assist in completing the reading and decoding of flash memory data.

[0085] Therefore, storage devices can have different data error correction conditions at different stages of operation: before the running code is loaded, the hardware decoding capability corresponding to the first verification mode can be mainly relied upon to complete the reading of the data required for startup; after the running code is loaded, read retry and / or software decoding can be further utilized on the basis of the second verification mode.

[0086] In one exemplary embodiment, after the storage device enters the normal operation phase, the data in the flash memory can be encoded and decoded according to a second parity mode. A low-density parity check (LDPC) code processing module encodes the data to be written to the flash memory page according to the second parity mode to obtain a second parity code. The length of the second parity code generated according to the second parity mode is less than the length of the first parity code generated according to the first parity mode.

[0087] During normal operation, the processor can write the data to be written to the entire data area of ​​the flash memory page and write the second checksum to the spare area of ​​the flash memory page. In other words, unlike the target flash memory page used during power-on startup, during normal operation, it is not necessary to allocate space from the data area to store the checksum. Instead, the data area of ​​the flash memory page can be used to store the data to be written, and the spare area can be used to store the corresponding second checksum.

[0088] During the read process, the processor reads data and the corresponding second checksum from the flash memory page, and provides the read data and the second checksum to the low-density parity check (LDPC) processing module. The LPC processing module decodes the data based on the second checksum according to the second parity mode. As needed, this decoding process can also be combined with the aforementioned read retry processing and / or software decoding processing.

[0089] It should be noted that the first and second verification modes not only correspond to different error correction capabilities but also to different flash memory page storage layouts. The first verification mode generates a longer first checksum, which, during the card opening phase, reduces the data area space occupied by the running code in the target flash memory page, allowing the spare area and the space in the data area where no running code is written to be used together to store the first checksum. The second verification mode generates a shorter second checksum, which, during normal operation, can be stored in the spare area, and the data occupies the entire data area of ​​the flash memory page.

[0090] By using the above method, different verification modes and corresponding flash page storage methods can be adopted for the power-on startup phase and the normal operation phase: during the power-on startup phase, additional storage space is provided for the longer verification code corresponding to the first verification mode; during the normal operation phase, a shorter second verification code is used so that the data area can be used for data storage in its entirety, thereby taking into account both the error correction capability during the power-on startup phase and the data area utilization rate during the normal operation phase.

[0091] In a specific application scenario, taking a storage device that uses flash memory as the storage medium as an example, the process of opening the card, powering on and starting up the storage device and then operating normally during the product manufacturing stage will be explained.

[0092] See Figure 2 The storage device may include a controller chip and flash memory. The controller chip may include a central processing unit, read-only memory, a low-density parity check module, and tightly coupled memory. Figure 2 In this context, CPU stands for processor, ROM stands for read-only memory, LDPC stands for low-density parity check module, and TCM stands for tightly coupled memory.

[0093] The processor executes corresponding code and controls the data writing and reading processes of the flash memory. The read-only memory stores the startup code executed first when the storage device powers on. The low-density parity check (LDPC) processing module encodes the data to be written to the flash memory to generate corresponding check codes, and also decodes the data read from the flash memory based on the corresponding check codes. The tightly coupled memory stores the running code loaded from the flash memory during the power-on startup process. The flash memory can be used to store product configuration information, running code, and data that needs to be preserved during the normal operation of the storage device.

[0094] Flash memory records data through the charge state of the corresponding storage cells. As the flash memory undergoes erase / write cycles, read cycles, temperature changes, increased data retention time, or external environmental influences, the charge state stored in the flash memory may change, leading to erroneous bits in the read data. To improve the reliability of flash memory data, low-density parity-check codes can be used to correct and protect the data written to the flash memory.

[0095] See Figure 3 In one specific implementation, a flash page may include a 16KB data area and a spare area, wherein, Figure 3 The "16KB + spare size" indicates that a flash memory page includes a 16KB data area and a spare area of ​​the same size. Different flash memory types may have different spare area sizes; for example, different types of flash memory may have different spare area sizes.

[0096] In this application scenario, 4KB can be used as a low-density parity error correction unit. Therefore, for a flash memory page with a 16KB data area, the data to be protected can be divided into four 4KB data parts, and low-density parity code can be performed on each of the four 4KB data parts.

[0097] Figure 3 In this context, "Host Data" refers to the host data, which is the valid data that needs to be written to the flash memory during the normal operation of the storage device; "Host Data (4KB)" represents one 4KB portion of host data. "Parity" represents the parity code, which is the checksum generated by the low-density parity check processing module after encoding a 4KB data portion according to the corresponding parity mode. Each 4KB data portion can correspond to one Parity, so that when subsequently reading this 4KB data portion, the corresponding Parity can be used to detect and correct any possible error bits.

[0098] Therefore, for 16KB of data, it can be divided into four 4KB data parts and four check codes corresponding to the four 4KB data parts respectively.

[0099] It should be noted that, Figure 3 The alternating use of Host Data and Parity primarily indicates the correspondence between each 4KB host data portion and its corresponding parity code. It does not imply that the parity code must actually be interleaved and stored within the 16KB data area. In typical data storage methods, the four 4KB host data portions can be stored in the data area of ​​a flash page, while the parity codes corresponding to the four 4KB host data portions can be stored in the spare area of ​​the flash page.

[0100] The low-density parity check (LDPC) code processing module supports multiple parity check modes. Different parity check modes correspond to different low-density parity check matrices and can generate parity codes of different lengths. For example, the parity code lengths corresponding to multiple parity check modes can be represented as N, NM, N-2M, and N-3M, respectively. Generally, the larger the parity code length, the more data verification information is used for decoding, and the stronger the hardware decoding error correction capability provided by the corresponding parity check mode. However, the corresponding parity code also requires more storage space.

[0101] Therefore, multiple verification modes can establish different correspondences between checksum storage space and error correction capability. For the same main control chip, the appropriate verification mode can be selected from multiple verification modes based on the relevant parameters of the connected flash memory and the current data processing stage.

[0102] For example, when the flash memory is in relatively robust condition, a check mode with a relatively short check code length can be used to reduce the storage space occupied by the check code; as the flash memory is used for longer periods or enters the later stages of its lifespan, a check mode with a relatively long check code length can be used to obtain stronger error correction capabilities.

[0103] However, when the storage device is first powered on, the processor has not yet obtained complete flash memory parameters, and some data reading and error correction methods that can be used during normal operation are not yet available. Therefore, the requirements for the verification mode differ between the power-on startup phase and the normal operation phase.

[0104] See Figure 4 The process of using a storage device can include the card activation process on the product manufacturing side and the power-on startup process on the customer side.

[0105] During the product manufacturing phase, the card activation process can be executed first, during which product configuration information and runtime code are written to flash memory. After the storage device completes production and enters the customer usage phase, when the storage device is powered on, the processor first executes the boot code in the read-only memory, and during the execution of the boot code, reads the boot-related data and runtime code stored in flash memory, and then loads the runtime code into tightly coupled memory for execution.

[0106] In one specific implementation, the code storage space provided by the read-only memory can be relatively small, for example, 8KB. Therefore, the read-only memory does not need to store all the program code required for the normal operation of the storage device, but can mainly store the basic code required to complete the power-on startup.

[0107] The boot code can be used to complete the basic processing during the power-on boot phase, such as interacting with the host, receiving commands and data sent by the host, identifying the flash memory manufacturer and type, and sending read commands to the flash memory. In contrast, the runtime code, which contains a large amount of data or needs to be adapted for different flash memory, can be stored in the flash memory and loaded into tightly coupled memory during the power-on boot process.

[0108] See Figure 5 The code to be executed can be stored in a block of code in flash memory, i.e. Figure 5 The code block shown can include a header page and multiple running code pages, such as running code page 0, running code page 1, and running code page 2. These multiple running code pages can be used to store the running code that needs to be read and loaded into tightly coupled memory during power-on startup.

[0109] During the initial power-on process of a storage device, the processor currently executes the boot code in read-only memory, while the runtime code in flash memory has not yet been loaded into the tightly coupled memory. Therefore, if code used to further improve the flash memory data read capability, such as retry logic code or software decoding logic code, is part of the runtime code, the processor cannot execute the aforementioned code until the runtime code has been fully loaded.

[0110] For example, read retry can be a processing method that adjusts the flash read conditions and performs the read again if the required data is not obtained in a flash read; soft decoding can use the soft information obtained during the flash read process to further improve the low-density parity decoding capability. The above processing usually requires corresponding runtime code support.

[0111] Therefore, during the power-on startup phase, before the running code has been fully loaded, the key data and running code in the flash memory can be read mainly by the hardware decoding and error correction capabilities provided by the low-density parity check module itself.

[0112] On the other hand, during the initial power-on startup phase, the processor has not yet read the product configuration information from the flash memory, and therefore has not yet obtained parameters such as the flash page size. It is also unable to pre-select the appropriate verification mode for the current flash memory based on the size of the spare area of ​​the flash memory, as it does during normal operation.

[0113] Based on the above, during the card activation phase, the product configuration information and operating code can be pre-encoded using the first verification mode. This first verification mode can be the one with the strongest error correction capability among the multiple verification modes supported by the main control chip, and can correspond to the maximum checksum length among the multiple verification modes.

[0114] Since the checksum length corresponding to the first check mode is relatively large, if the entire data area of ​​the flash page is still used to store valid data in the normal way, the original spare area of ​​the flash page may not be able to provide enough storage space for all the checksums generated by the first check mode.

[0115] To address this, the amount of valid data stored in a single flash memory page can be reduced during the card activation phase, and the freed-up data area space can be used to store a longer checksum corresponding to the first check mode.

[0116] See Figure 6 , Figure 6 This illustrates a flash memory page data organization method during the card activation phase. Here, Code represents the execution code, and Code (4KB) represents a 4KB data portion within the execution code; Max Parity represents the maximum parity, which is the parity code obtained by encoding the corresponding 4KB execution code according to the strongest error correction mode among multiple parity modes. The "Max" here indicates that the parity code length is the maximum among the parity lengths corresponding to multiple parity modes, and is not a data type independent of the aforementioned Parity.

[0117] Figure 6 In this context, "Dummy" refers to padding data. After the code execution and corresponding checksum writing are complete, if there is still remaining space in the flash memory page that does not need to be used to store valid information, padding data can be written into that remaining space.

[0118] For example, with a data area size of 16KB, a flash page can store four 4KB data portions, or 16KB of valid data, using the usual data storage method. However, when using the first verification mode during the card activation phase, only three 4KB runtime code portions can be stored in a single flash page, resulting in 12KB of runtime code.

[0119] Therefore, some space that could have been used to store runtime code can be freed up in the 16KB data area. The low-density parity check processing module encodes the three 4KB runtime code portions according to the first parity mode to obtain the corresponding maximum check code, and uses the spare area of ​​the flash memory page and the space in the data area where no runtime code has been written to store the maximum check code.

[0120] therefore, Figure 6 The core idea is not to require a flash page to store three 4KB portions of runtime code, but to free up additional storage space for the longer checksum generated by the first check mode by reducing the amount of effective code stored in a single flash page.

[0121] The same processing method can be used for product configuration information.

[0122] Product configuration information may include storage device capacity information, number of flash memory blocks, number of flash memory pages, flash memory page size, etc., and can serve as the first piece of data read from the flash memory after the storage device is powered on.

[0123] During the card activation phase, the product configuration information can be encoded according to the first verification mode to obtain the corresponding verification code. The product configuration information is then written into a portion of the data area of ​​the configuration flash page, and the corresponding verification code is written into the spare area of ​​the configuration flash page and the space in the data area where no product configuration information has been written.

[0124] For example, in one implementation, 12KB of product configuration information can be stored in a single configuration flash page, while the remaining space in the data area and the spare area are used to store the corresponding checksum. When the amount of product configuration information exceeds the storage capacity of the current configuration flash page, the remaining product configuration information can be stored in subsequent flash pages.

[0125] The aforementioned 12KB is only used to illustrate a specific implementation of freeing up space for the checksum by reducing the space occupied by effective data, and does not limit the product configuration information to use 12KB as a fixed storage amount.

[0126] After the card is activated, the storage device enters the customer's usage phase.

[0127] When the storage device is powered on, the processor first executes the boot code in the read-only memory, and can first read the product configuration information and its corresponding checksum from the configuration flash page.

[0128] Since the processor has not yet obtained the flash memory page size at this time, the low-density parity check module directly decodes the product configuration information according to the first verification mode predetermined in the card opening stage before obtaining the flash memory page size.

[0129] Therefore, the product configuration information after error correction can be obtained first. The processor then obtains parameters such as storage device capacity, number of flash memory blocks, number of flash memory pages, and flash memory page size based on the product configuration information, and uses these parameters to complete the corresponding configuration of the main control chip.

[0130] After configuring the main control chip, the processor continues executing the boot code in the read-only memory, from... Figure 5 The execution code and its corresponding checksum are read from the flash memory page shown.

[0131] Since the above-mentioned running code has been encoded according to the first verification mode during the card opening stage, the low-density parity check code processing module can continue to perform hardware decoding of the read running code based on the corresponding check code during the power-on startup stage, according to the first verification mode.

[0132] When the executable code is stored across multiple executable code flash pages, the executable code in each flash page can be read sequentially, and decoded according to the corresponding checksum. The processor then loads the decoded executable code into the tightly coupled memory step by step.

[0133] Once the executable code is loaded into the tightly coupled memory, the processor can switch from executing the startup code in the read-only memory to executing the executable code in the tightly coupled memory, thus completing the transition from the power-on startup phase to the normal operation phase.

[0134] Since the running code can include at least one of read retry logic code and software decoding logic code, after the running code is loaded into the tightly coupled memory, the processor can perform read retry processing and / or software decoding processing during subsequent reads of flash memory data.

[0135] At this point, the processor has also obtained flash memory parameters such as flash page size through the product configuration information. Therefore, it can select the second verification mode used during normal operation from multiple verification modes based on the size of the flash memory's spare area.

[0136] The second verification mode can be selected to allow the corresponding checksum to be stored in the spare area of ​​the flash memory page. For example, in the case where a flash memory page consists of four 4KB data portions, the second verification mode can generate four checksums for each of the four 4KB data portions, which can all be stored in the spare area of ​​the flash memory page without continuing to occupy the data area of ​​the flash memory page.

[0137] See Figure 7 , Figure 7 This illustrates a method of organizing flash page data during normal operation.

[0138] Here, Host Data represents the host data, which is the valid data that needs to be written to the flash memory during the normal operation of the storage device; Host Data (4KB) represents one 4KB host data portion; Parity represents the checksum generated for the corresponding 4KB host data portion according to the second check mode; Dummy still represents the padding data in the remaining space.

[0139] During normal operation, all four 4KB host data portions can be written into the data area of ​​the flash memory page, thus fully utilizing the 16KB data area to store valid data. The low-density parity check module encodes the four 4KB host data portions according to the second parity mode, obtaining four corresponding check codes, which can then be stored in the spare area of ​​the flash memory page.

[0140] and Figure 3 similar, Figure 7 The alternating use of Host Data and Parity primarily indicates the correspondence between each host data section and its corresponding checksum, and does not imply that Parity actually occupies the 16KB data area. During normal operation, the four 4KB Host Data sections can collectively occupy the entire 16KB data area, while the corresponding Parity can be stored in the spare area.

[0141] The length of the checksum generated by the second checksum mode can be shorter than the length of the checksum generated by the first checksum mode. Therefore, with Figure 6 Compared to the card opening stage shown, Figure 7 During normal operation, it is no longer necessary to allocate space from the data area to store the verification code, and the use of the entire data area can be restored.

[0142] Although the hardware decoding error correction capability of the second verification mode is lower than that of the first verification mode, the running code has already been loaded into the tightly coupled memory, allowing the processor to further execute read retry logic code and / or software decoding logic code. Therefore, the reliability of data reading during normal operation can be improved through the coordination of hardware decoding, read retry, and software decoding.

[0143] In a specific example, the checksum length corresponding to the most powerful error correction mode supported by the main control chip can be 640 bytes, and its hardware decoding error correction capability can correct 430 error bits per 4KB of data; the checksum length corresponding to the weakest error correction mode can be 368 bytes, and its hardware decoding error correction capability can correct 220 error bits per 4KB of data. The above values ​​are only used to illustrate that the checksum length and hardware decoding error correction capability corresponding to different checksum modes can vary significantly, and do not constitute a limitation on the checksum length or error correction capability.

[0144] Therefore, during the product manufacturing stage of the storage device, the space occupied by the data area for product configuration information and running code can be reduced, allowing the space freed up in the spare area and the data area to be used together to store the longer checksum corresponding to the first check mode. During the power-on startup stage, when complete flash memory parameters have not yet been obtained and read retry and software decoding are not yet available, the first check mode can be relied upon to provide strong hardware decoding error correction capabilities to reliably read the product configuration information and running code. After the running code is loaded into the tightly coupled memory, the second check mode is selected according to the size of the spare area of ​​the flash memory, so that the data area of ​​the flash page can be used completely for normal data storage, and the reliability of data reading is improved by combining read retry and / or software decoding.

[0145] By adopting the above methods, appropriate verification modes and flash page data organization methods can be used for different operating conditions during the power-on startup phase and the normal operation phase. This ensures the reliability of code reading during the power-on startup phase while improving the utilization rate of the flash page data area during the normal operation phase.

[0146] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0147] This document describes various exemplary embodiments with reference to them. However, those skilled in the art will recognize that changes and modifications can be made to the exemplary embodiments without departing from the scope of this document. For example, various operational steps and components for performing operational steps can be implemented in different ways depending on the specific application or considering any number of cost functions associated with the operation of the system (e.g., one or more steps can be deleted, modified, or combined with other steps).

[0148] Those skilled in the art will understand that all or part of the functions of the various methods in the above embodiments can be implemented by hardware or by computer programs. When all or part of the functions in the above embodiments are implemented by computer programs, the program can be stored in a computer-readable storage medium, which may include: read-only memory, random access memory, disk, optical disk, hard disk, etc., and the program is executed by a computer to achieve the above functions. For example, the program can be stored in the memory of a device, and when the program in the memory is executed by the processor, all or part of the above functions can be achieved. In addition, when all or part of the functions in the above embodiments are implemented by computer programs, the program can also be stored in a server, another computer, disk, optical disk, flash drive, or external hard drive, etc., and can be downloaded or copied to the memory of a local device, or the system of the local device can be updated. When the program in the memory is executed by the processor, all or part of the functions in the above embodiments can be achieved.

[0149] In the above embodiments, implementation can be achieved, in whole or in part, by software, hardware, firmware, or any combination thereof. Furthermore, as those skilled in the art will understand, the principles herein can be reflected in a computer program product on a computer-readable storage medium pre-loaded with computer-readable program code. Any tangible, non-transitory computer-readable storage medium may be used, including magnetic storage devices (hard disks, floppy disks, etc.), optical storage devices (CD-ROMs, DVDs, Blu-ray discs, etc.), flash memory, and / or the like. These computer program instructions can be loaded onto a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to form a machine, such that instructions executing on the computer or other programmable data processing apparatus can generate means for performing a specified function. These computer program instructions can also be stored in a computer-readable storage medium that can instruct the computer or other programmable data processing apparatus to operate in a particular manner, such that instructions stored in the computer-readable storage medium can form an article of manufacture including means for implementing the specified function. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to perform a series of operational steps on the computer or other programmable apparatus to produce a computer-implemented process, such that instructions executing on the computer or other programmable apparatus can provide steps for implementing the specified function.

[0150] While the principles herein have been illustrated in various embodiments, numerous modifications to the structure, arrangement, proportions, elements, materials, and components, particularly suited to specific environmental and operational requirements, may be used without departing from the principles and scope of this disclosure. These modifications and other alterations or alterations will be included within the scope of this document.

[0151] The foregoing specific descriptions have been described with reference to various embodiments. However, those skilled in the art will recognize that various modifications and changes can be made without departing from the scope of this disclosure. Therefore, considerations for this disclosure are to be illustrative rather than restrictive, and all such modifications are to be included within its scope. Similarly, advantages, other advantages, and solutions to problems with respect to various embodiments have been described above. However, benefits, advantages, solutions to problems, and any elements that produce these, or make them more explicit, should not be construed as critical, essential, or necessary. The term “comprising” and any other variations thereof as used herein are non-exclusive inclusion, meaning that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed or not part of the process, method, system, article, or apparatus. Furthermore, the term “coupled” and any other variations thereof as used herein refer to physical connections, electrical connections, magnetic connections, optical connections, communication connections, functional connections, and / or any other connections.

[0152] Those skilled in the art will recognize that many changes can be made to the details of the above embodiments without departing from the basic principles of this application. Therefore, the scope of this application should be determined only by the claims.

Claims

1. A storage device, characterized in that, It includes a main control chip and flash memory, wherein the main control chip includes a processor, tightly coupled memory and a low-density parity check code processing module; The flash memory is used to store runtime code, which is stored in a target flash page of the flash memory; The low-density parity check code processing module is used to support multiple check modes, and encodes the running code to be written to the target flash memory page according to the first check mode during the card opening stage to obtain the first check code. The first check mode is the check mode with the strongest error correction capability among the multiple check modes. The processor is configured to, during the card activation stage, write the running code into a portion of the data area of ​​the target flash page, and write the first verification code into the spare area of ​​the target flash page and the space in the data area of ​​the target flash page where the running code has not been written; The processor is further configured to read the running code and the first checksum from the target flash memory page during the power-on startup phase of the storage device; The low-density parity check code processing module is further configured to receive the running code and the first check code read by the processor, and decode the running code based on the first check code according to the first check mode. The tightly coupled memory is used to store the running code decoded by the low-density parity check code processing module; The processor is further configured to load the running code decoded by the low-density parity check code processing module into the tightly coupled memory, and after the running code is loaded into the tightly coupled memory, determine a second parity mode from the plurality of parity modes according to the size of the spare area of ​​the flash memory; The low-density parity check code processing module is further configured to encode the data to be written to the flash memory according to the second verification mode during the normal operation phase of the storage device, and to decode the data read from the flash memory according to the second verification mode.

2. The storage device as claimed in claim 1, characterized in that, The low-density parity check code processing module includes an encoding unit and a decoding unit; The encoding unit is used to encode the running code according to the first verification mode during the card opening stage, and to encode the data to be written to the flash memory according to the second verification mode during the normal operation stage. The decoding unit is configured to receive the running code and the first checksum read by the processor from the target flash memory page during the power-on startup phase, and decode the running code based on the first checksum according to the first checksum mode, and decode the data read from the flash memory according to the second checksum mode during the normal operation phase.

3. The storage device as described in claim 1, characterized in that, The multiple check modes correspond to different low-density parity check matrices, and the different low-density parity check matrices are used to generate check codes of different lengths. The length of the check code corresponding to the first verification mode is the maximum length among the lengths of the check codes corresponding to the plurality of verification modes.

4. The storage device as claimed in claim 1, characterized in that, In the case where the runtime code is stored in multiple target flash pages, for each target flash page: The low-density parity check code processing module is used to encode the running code written to the target flash memory page according to the first check mode to obtain the first check code of the target flash memory page. The processor is configured to write a portion of the running code into a portion of the data area of ​​the target flash page, and to write the first checksum of the target flash page into the spare area of ​​the target flash page and the space in the data area of ​​the target flash page where the running code is not written.

5. The storage device as claimed in claim 1, characterized in that, The flash memory also includes configuration flash pages for storing product configuration information; The low-density parity check code processing module is used to encode the product configuration information according to the first verification mode during the card opening stage to obtain the third verification code. The processor is configured to, during the card activation stage, write the product configuration information into a portion of the data area of ​​the configuration flash page, and write the third verification code into the spare area of ​​the configuration flash page and the space in the data area of ​​the configuration flash page where the product configuration information has not been written.

6. The storage device as claimed in claim 5, characterized in that, The product configuration information is the first piece of data read from the flash memory after the storage device is powered on and started. The processor is configured to read the product configuration information and the third verification code from the configuration flash page during the power-on startup phase. The low-density parity check code processing module is used to receive the product configuration information and the third check code read by the processor, and decode the product configuration information based on the third check code according to the first check mode. The processor is further configured to receive the decoded product configuration information, configure the main control chip according to the product configuration information, and after completing the configuration of the main control chip, read the running code and the first verification code from the target flash memory page.

7. The storage device as claimed in claim 6, characterized in that, The product configuration information includes at least one of the following: the capacity information of the storage device, the number of flash blocks, the number of flash pages, and the flash page size. The low-density parity check code processing module is used to decode the product configuration information based on the third check code according to the first check mode before the processor obtains the flash memory page size; The processor is used to obtain the flash memory page size based on the product configuration information obtained through decoding.

8. The storage device as claimed in claim 1, characterized in that, The main control chip also includes a read-only memory; The read-only memory is used to store the startup code; The processor is configured to execute the startup code during the power-on startup phase, and read the running code and the first checksum from the target flash memory page during the execution of the startup code; The low-density parity check code processing module is used to receive the running code and the first check code read by the processor, and to perform hardware decoding on the running code based on the first check code according to the first check mode.

9. The storage device as claimed in claim 8, characterized in that, The execution code includes at least one of read retry logic code and software decoding logic code; The processor is configured to execute at least one of the read retry logic code and the software decoding logic code during the process of reading data from the flash memory after the running code is loaded into the tightly coupled memory.

10. The storage device as claimed in claim 9, characterized in that, The flash memory includes flash pages, and the low-density parity check code processing module is used to encode the data to be written to the flash page according to the second check mode during the normal operation phase to obtain the second check code. The processor is configured to write the data into the entire data area of ​​the flash memory page and write the second check code into the spare area of ​​the flash memory page; The processor is further configured to read the data and the second verification code from the flash memory page; The low-density parity check code processing module is further configured to receive the data read by the processor and the second check code, and decode the data based on the second check code according to the second check mode; The length of the second check code generated according to the second check mode is less than the length of the first check code generated according to the first check mode.

Images