Firmware data rereading method and device and storage medium

Abstract

The invention discloses a firmware data rereading method and device and a storage medium, and relates to the technical field of data processing. The method comprises the following steps: modifying a decoding parameter when firmware data is failed to read, and acquiring a reliability parameter of each word line in an entity programming unit; then, according to the reliability parameter, determining a target word line and target backup firmware data corresponding to the target word line in the entity programming unit; and then, reading target backup firmware data in the target word line through the decoder, a decoding parameter corresponding to the decoder and a target reading voltage corresponding to the current rereading step. According to the method, reading is started from the most reliable backup position according to the reliability parameter of the character line, the number of rereading times caused by reading damaged data can be reduced, the rereading delay of backup firmware data is reduced, and therefore the starting speed is increased.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a firmware data rereading method, device, and storage medium. Background Art

[0002] Firmware is program code stored in non-volatile memory that runs when a computer or other device boots up, responsible for initializing hardware components and loading the operating system. If firmware data is reread slowly, the entire system startup process will be delayed. Currently, firmware data is typically written repeatedly to non-volatile memory in a sequential write manner in single-layer units. When reading firmware data, if a certain firmware data segment cannot be correctly decoded, the reading code will jump to the next repeated segment in the non-volatile memory in the order of writing and re-read the backup firmware data at the same location. However, in actual use, non-volatile memory damage is uneven, and some backup locations may be more prone to errors due to physical damage or aging. The aforementioned sequential reading method cannot adapt to the actual wear and tear of non-volatile memory, resulting in more time wasted during the reread process.

[0003] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a firmware data rereading method, device and storage medium, aiming to solve the technical problem of how to reduce the delay of rereading backup firmware data.

[0005] To achieve the above objectives, the present application proposes a firmware data rereading method, the method comprising: When reading the firmware data fails, the decoding parameters are modified and the reliability parameters of each word line in the physical programming unit are obtained; determining, in the physical programming unit, a target word line and target backup firmware data corresponding to the target word line according to the reliability parameter; The target backup firmware data in the target word line is read through a decoder, the decoding parameter corresponding to the decoder, and a target read voltage corresponding to a current reread step.

[0006] In one embodiment, before the step of modifying the decoding parameters and obtaining the reliability parameters of each word line in the physical programming unit when reading the firmware data fails, the method further includes: Acquiring the firmware data, and storing the firmware data in a preset word line of the physical programming unit; Copying the firmware data to obtain the backup firmware data; A plurality of copies of the backup firmware data are stored in other word lines until the storage space in the physical programming unit is used up, wherein the other word lines are continuous word lines other than the preset word line.

[0007] In one embodiment, before the step of obtaining the firmware data and storing the firmware data in a preset word line of the physical programming unit, the method further includes: Writing test data into the physical programming unit; Erasing the test data from the physical programming unit and rewriting it according to a preset number of wear cycles; Reading the test data to determine the bit error rate corresponding to each word line in the physical programming unit; A reliability parameter of each word line is determined based on the bit error rate, wherein the bit error rate is inversely proportional to the reliability parameter.

[0008] In one embodiment, the step of reading the target backup firmware data in the target word line using a decoder, the decoding parameters corresponding to the decoder, and a target read voltage corresponding to the current reread step includes: Reading the target backup firmware data in the target word line using a first decoder, a first decoding parameter, and a target read voltage corresponding to the current reread step; If the reading fails, obtain the number of voltage adjustments; If the voltage adjustment times are greater than or equal to a preset adjustment times threshold, selecting an optimal voltage among the read voltages based on a bit error rate; The target backup firmware data in the target word line is read again by using a second decoder, a second decoding parameter and the optimal voltage, wherein the bandwidth of the second decoder is lower than that of the first decoder and the second decoding parameter is greater than the first decoding parameter.

[0009] In one embodiment, the step of selecting an optimal voltage among the read voltages based on the bit error rate includes: Get the bit error rate corresponding to all read voltages; The read voltage with the lowest bit error rate is determined as the optimal voltage.

[0010] In one embodiment, before the step of obtaining the number of voltage adjustment times, the method further includes: Reading the target backup firmware data in the target word line using a third decoder, a third decoding parameter, and the target read voltage, wherein the bandwidth of the third decoder is lower than that of the first decoder and higher than that of the second decoder, and the third decoding parameter is greater than the first decoding parameter and less than the third decoding parameter; If the reading fails, the step of obtaining the voltage adjustment times is performed.

[0011] In one embodiment, after the step of obtaining the number of voltage adjustment times, the method further includes: If the voltage adjustment times are less than the preset adjustment times threshold, re-determining the target read voltage and reducing the first decoding parameter and the second decoding parameter; The step of reading the target backup firmware data in the target word line using a first decoder, a first decoding parameter, and a target read voltage corresponding to the current reread step is performed.

[0012] In one embodiment, after the step of re-reading the target backup firmware data in the target word line using the second decoder, the second decoding parameter, and the optimal voltage, the method further includes: If the read fails again, re-determining the target backup firmware data and the target word line corresponding to the target backup firmware data in the physical programming unit according to the reliability parameter; Using the optimal voltage as a target read voltage corresponding to the current reread step, and reducing the first decoding parameter and the second decoding parameter; The step of reading the target backup firmware data in the target word line is performed using a first decoder, a first decoding parameter, and a target read voltage corresponding to the current reread step.

[0013] In addition, to achieve the above-mentioned purpose, the present application also proposes a firmware data rereading device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the firmware data rereading method as described above.

[0014] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium. A computer program is stored on the storage medium, and when the computer program is executed by the processor, the steps of the firmware data rereading method described above are implemented.

[0015] This application provides a firmware data rereading method. When firmware data reading fails, decoding parameters are modified and reliability parameters of each word line in a physical programming unit are obtained. Then, based on the reliability parameters, a target word line and target backup firmware data corresponding to the target word line are determined in the physical programming unit. Finally, the target backup firmware data in the target word line is read using a decoder, the decoding parameters corresponding to the decoder, and the target read voltage corresponding to the current reread step. By analyzing the reliability parameters of the word lines to find a word line with a higher read success rate for rereading, the above method can reduce the number of rereads caused by reading damaged data, reduce the latency of rereading the backup firmware data, and thus accelerate boot speed. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0018] Figure 1 A flowchart of the first embodiment of the firmware data rereading method of the present application is provided; Figure 2 A flowchart of the second embodiment of the firmware data rereading method of the present application is provided; Figure 3 A flowchart of the third embodiment of the firmware data rereading method of the present application is provided; Figure 4 A flowchart of the fourth embodiment of the firmware data rereading method of the present application is provided; Figure 5 A flowchart of the sixth embodiment of the firmware data rereading method of the present application is provided; Figure 6 A flowchart of Embodiment 7 of the firmware data rereading method of the present application is provided; Figure 7 Schematic diagram of a simplified flow chart of a firmware data rereading method according to an embodiment of the present application; Figure 8 A flowchart of Embodiment 8 of the firmware data rereading method of the present application is provided; Figure 9 Schematic diagram of the device structure of the hardware operating environment involved in the firmware data rereading method in the embodiment of the present application.

[0019] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0020] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not intended to limit the present application.

[0021] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0022] Firmware is program code stored in non-volatile memory that runs when a computer or other device boots up, responsible for initializing hardware components and loading the operating system. If firmware data is reread slowly, the entire system startup process will be delayed. Currently, firmware data is typically written repeatedly to non-volatile memory in a sequential write manner in single-layer units. When reading firmware data, if a certain firmware data segment cannot be correctly decoded, the reading code will jump to the next repeated segment in the non-volatile memory in the order of writing and re-read the backup firmware data at the same location. However, in actual use, non-volatile memory damage is uneven, and some backup locations may be more prone to errors due to physical damage or aging. The aforementioned sequential reading method cannot adapt to the actual wear and tear of non-volatile memory, resulting in more time wasted during the reread process.

[0023] In view of the above problems, this application proposes a firmware data rereading method. When firmware data reading fails, decoding parameters are modified and reliability parameters of each word line in the physical programming unit are obtained. Then, based on the reliability parameters, a target word line and the target backup firmware data corresponding to the target word line are determined in the physical programming unit. Then, the target backup firmware data in the target word line is read using a decoder, the decoding parameters corresponding to the decoder, and the target read voltage corresponding to the current reread step. By analyzing the reliability parameters of the word line to find a word line with a higher read success rate for rereading, the above method can reduce the number of rereads caused by reading damaged data, reduce the latency of rereading the backup firmware data, and thus speed up the startup process.

[0024] It should be noted that the execution subject of this embodiment may be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of implementing the above functions. This embodiment and the following embodiments are described below using a storage controller as an example.

[0025] Based on this, the first embodiment proposed in this application provides a firmware data rereading method, referring to Figure 1In this embodiment, the firmware data rereading method includes steps S10 to S30: Step S10 , when the firmware data reading fails, the decoding parameters are modified, and the reliability parameters of each word line in the physical programming unit are obtained.

[0026] It should be noted that the reliability parameters of each word line in the physical programming unit can be obtained by performing a reliability test on the physical programming unit before reading the firmware data, or by evaluating the historical read data of each word line in the physical programming unit. For example, evaluation indicators such as the historical number of bit errors, historical bit error rate, historical syndrome value, and historical read success rate corresponding to each word line can be collected, and the reliability weight of each word line can be obtained by weighted summing these evaluation indicators to serve as the reliability parameter.

[0027] After the reliability parameters are obtained, the reliability parameters are written into the physical programming unit as readable parameters. When the storage controller determines the target backup firmware data and the word line corresponding to the target backup firmware data, the reliability parameters of each word line are read from the physical programming unit.

[0028] It should also be noted that when the storage controller first reads firmware data from the physical programming unit, it can use decoders with different decoding capabilities to decode the read data. The decoding parameter refers to the number of decoding iterations of the decoder. When the initial reading of the firmware data fails, the encoding parameter can be modified. For example, the number of decoding iterations of the decoder with lower decoding capabilities can be reduced, or the number of decoding iterations of the decoder with lower decoding capabilities can be changed to 0, indicating that the decoder with lower decoding capabilities is skipped and the decoder with higher decoding capabilities is directly used for decoding.

[0029] Step S20 , determining a target word line and target backup firmware data corresponding to the target word line in the physical programming unit according to the reliability parameter.

[0030] Optionally, the memory controller sorts the word lines according to a reliability parameter, with word lines with higher reliability parameters being ranked higher. The order in which the backup firmware data is read is determined based on the sorting result, with the backup firmware data in the word lines with the highest reliability being read first.

[0031] Optionally, when reading the firmware data fails, the decoding parameters are modified, and a reliability parameter table is obtained, and the target word line is determined according to the reliability parameter table.

[0032] For example, after the control memory performs a reliability test on the physical programming unit, a reliability parameter table is generated based on the test results, such as the bit error rate and the number of bit error bits, to indicate the reading order of various locations in the non-volatile memory, such as word lines, pages, or data blocks. For example, assuming that after a reliability test is performed on a physical programming unit, the number of bit error bits corresponding to the first word line is 300; the number of bit error bits corresponding to the second word line is 500; and the number of bit error bits corresponding to the third word line is 200. A reliability parameter table TABLE is generated based on the test results, wherein the reliability parameter table contains three parameters: TABLE[0]=3, indicating that data is read from the third word line; TABLE[1]=1, indicating that data is read from the first word line; and TABLE[2]=2, indicating that data is read from the second word line. In this way, when reading firmware data fails, the storage controller can directly read the reliability parameter table TABLE and, based on the reading order in the reliability parameter table, determine the corresponding word line position to read the target backup firmware data.

[0033] Step S30 , reading the target backup firmware data in the target word line through a decoder, the decoding parameters corresponding to the decoder, and a target read voltage corresponding to the current rereading step.

[0034] It should be noted that in non-volatile storage, data is stored in memory cells as bits. Multiple memory cells are arranged on the same wordline, which together form a physical programming unit (page). During data writing, the memory controller activates the corresponding wordline to write the data to the specified memory cell. After data writing is complete, the data is stored in the memory cell as an electrical charge. Different charge levels represent different data values. When reading data, the memory controller activates the corresponding wordline to retrieve the data from the specified physical programming unit. The retrieved charge level is decoded by the decoder to restore it to the original data byte.

[0035] For example, when the storage controller fails to read the firmware data for the first time, it determines the target word line and the target backup firmware data corresponding to the target word line in the physical programming unit based on the reliability parameter. The storage controller then sends a read instruction to the non-volatile memory through the non-volatile memory's control interface to reread the target backup firmware data from the storage cell in the target word line. The target backup firmware data in the storage cell is stored in the form of charge. By applying the target read voltage, the non-volatile memory converts the charge state of the storage cell into a digital signal and returns it to the storage controller as the original data.

[0036] It should be noted that in non-volatile memory, because the storage medium itself may be affected by physical properties such as charge leakage, errors may occur during the storage or reading process of data. Therefore, when the storage controller reads firmware data from the storage unit of the non-volatile memory, it will simultaneously read redundant information related to the firmware data, such as error correction code, and use the redundant information to detect whether there are errors in the read firmware data. If errors are detected, a decoder is used to try to correct these errors. If multiple error correction attempts fail, the storage controller can adjust the read parameters such as the read voltage or the word line position to be read, reread the firmware data and then try error correction again.

[0037] In this embodiment, by acquiring and evaluating the reliability parameters of each word line in the physical programming unit before reading the firmware data, determining the target word line based on these parameters, and preferentially reading the backup firmware data in the word line with the highest reliability, the success rate and efficiency of firmware data reading are significantly improved, and the delay introduced by repeated attempts to read damaged or low-reliability backup data is reduced, thereby accelerating the system startup time and reducing the risk of read failure.

[0038] Based on the above embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment can be referred to the above introduction and will not be described in detail later. Figure 2 Before step S10, the firmware data rereading method further includes steps S40 to S60: Step S40 , obtaining firmware data, and storing the firmware data in a preset word line of the physical programming unit.

[0039] Exemplarily, the storage controller receives firmware data from an external device or reads it from another storage location. The firmware data is typically stored in binary format and contains critical information required for system startup and operation. Next, the storage controller determines a physical programming unit for storing the firmware data based on the physical structure of the storage device and a preset storage policy. Within the selected physical programming unit, the controller determines a specific preset word line and writes the firmware data to the specified storage unit within the preset word line via the control interface of the non-volatile memory.

[0040] Step S50: copy the firmware data to obtain backup firmware data.

[0041] In step S60 , a plurality of copies of the backup firmware data are stored in other word lines until the storage space in the physical programming unit is fully used, wherein the other word lines are continuous word lines other than the preset word lines.

[0042] After the firmware data is written into the physical programming unit, the firmware data is copied to obtain multiple copies of backup firmware data, and the multiple copies of backup firmware data are sequentially written into the available storage space in the physical programming unit until the storage space in the physical programming unit is used up.

[0043] In this embodiment, through the above steps, the storage controller can reliably store the firmware data and its backup in non-volatile memory. This redundant storage strategy helps improve data reliability and data read fault tolerance, ensuring that if the main firmware data fails to be read due to damage or loss, the backup firmware data can be read from other storage locations.

[0044] Based on the above embodiments of the present application, in the third embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction and will not be described in detail later. Figure 3 Before step S40, the firmware data rereading method further includes steps S70 to S100: Step S70: writing test data into the physical programming unit.

[0045] In step S80 , the test data is erased from the physical programming unit and written again according to a preset number of wear cycles.

[0046] Step S90 , reading the test data to determine the bit error rate corresponding to each word line in the physical programming unit.

[0047] Step S100 : determining a reliability parameter of each word line based on the bit error rate, wherein the bit error rate is inversely proportional to the reliability parameter.

[0048] The storage controller generates a set of test data. The content of this test data is known, facilitating subsequent reading and comparison. The physical programming unit used to store firmware data is then used as the test object, and the test data is written into the selected physical programming unit to ensure that the data is correctly stored. Based on the test or actual use requirements, a preset number of wear cycles is set. Within this preset number of wear cycles, the following operations are repeatedly performed to simulate the data erasure process in actual use: the test data in the physical programming unit is erased using the storage device's erase command, and then the test data is written into the physical programming unit again.

[0049] Optionally, after the wear-out cycle is complete, the test data is read and decoded from the physical programming unit. The decoded data is compared with the original test data, and the number of bit errors on each word line is counted to calculate the bit error rate (BER): BER = bit error / total number of bits. Next, based on the BER for each word line, a corresponding reliability parameter is determined. The reliability parameter is inversely proportional to the BER; that is, the lower the BER, the higher the reliability parameter.

[0050] Optionally, after the wear-out cycle is complete, test data is read and decoded from the physical programming unit. The decoded data is compared with the original test data, and the number of bit errors on each word line is counted. Next, based on the number of bit errors on each word line, a corresponding reliability parameter is determined. The reliability parameter is inversely proportional to the number of bit errors; that is, a lower number of errors indicates a higher reliability parameter.

[0051] Optionally, when decoding of the test data read from the physical programming unit fails, a syndrome value corresponding to each word line is obtained and converted into a bit error rate or bit error number using a preset conversion method. Then, the corresponding reliability parameter is determined based on the bit error rate or bit error number for each word line.

[0052] It's important to note that during the decoding process, the decoder can obtain various information, including candidate values, which are used to detect errors in the data. If the candidate value is a zero vector, it's generally assumed that no error has been detected; if the candidate value is non-zero, it indicates that an error has been detected. In the encoding rules, each possible non-zero candidate value corresponds to a specific error pattern, and the location of the error can be determined through table lookup or calculation.

[0053] In this embodiment, the reliability of each word line can be accurately evaluated through actual wear testing and bit error rate calculation, so that word lines with high reliability are preferentially selected in subsequent data rereading, reducing the probability of rereading failure.

[0054] Based on the above embodiments of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction and will not be described in detail later. Figure 4 , step S30 includes steps S31 to S34: Step S31 , reading the target backup firmware data in the target word line using a first decoder, a first decoding parameter, and a target read voltage corresponding to the current reread step.

[0055] Exemplarily, after receiving the original data returned by the non-volatile memory, the storage controller uses the first decoder to decode the original data. The purpose of the decoder is to convert the original data returned by the non-volatile memory, which may contain noise or errors, into correct firmware data. Then, the storage controller repeatedly performs decoding through the first decoder according to the preset first decoding parameters. This is because one decoding may not be able to completely correct the errors in the original data, and the probability of error correction can be increased through multiple decoding. After completing the number of decoding iterations corresponding to the first decoding parameters, the storage controller checks whether the firmware reread data obtained after decoding meets the format and verification requirements of the firmware data. If the firmware reread data obtained after decoding is correct, the reading is successful; if the firmware reread data obtained after decoding still has errors or the decoding fails, the subsequent processing steps are entered.

[0056] Step S32: If the reading fails, obtain the number of voltage adjustment times.

[0057] Optionally, when reading the target backup firmware data in the target word line using the first decoder, the first decoding parameter, and the target read voltage, a verification mechanism is used to determine whether the firmware reread data obtained after decoding by the first decoder contains errors each time decoding is performed. If errors are present, decoding is continued. If the number of decodings reaches the first decoding parameter and errors are still present in the firmware reread data obtained after decoding, it is determined that the reading of the target backup firmware data has failed.

[0058] For example, using the cyclic redundancy check (CRC) mechanism, when firmware data is written to non-volatile memory, the storage controller uses a predefined generator polynomial, treating the firmware data as a large binary number and performing a modulo-2 division operation on the generator polynomial. The result of the modulo-2 division is a remainder whose number of bits is one less than the degree of the generator polynomial. This remainder is called a cyclic redundancy check code. The cyclic redundancy check code is appended to the end of the firmware data and stored together in the non-volatile memory.

[0059] When the storage controller reads the target backup firmware data, it reads both the data portion and the appended cyclic redundancy check code. The storage controller then uses the same generating polynomial to perform a modulo-2 division on the entire target backup firmware data (including the data portion and the cyclic redundancy check code). If the reread data remains unchanged, the result of the modulo-2 division should be zero. If the result of the modulo-2 division is not zero, an error occurred during the storage or reading process of the target backup firmware data, and the read failed.

[0060] For example, assume the first decoding parameter is set to 3. The storage controller uses the first decoder to decode the original data returned by the non-volatile memory. After decoding, the memory controller performs a modulo-2 division on the obtained firmware reread data using a cyclic redundancy check mechanism. If the result of the modulo-2 division is not 0, the memory controller continues to decode the data using the first decoder. If the result of the modulo-2 division is still not 0 after three decoding cycles, the target backup firmware data is determined to have failed to be read.

[0061] Optionally, the decoder uses an iterative belief propagation algorithm to gradually correct errors in the data through multiple iterations and verify whether the decoding is successful.

[0062] For example, consider a decoder using Low-Density Parity-Check (LDPC). The parity check matrix for LDPC codes is a sparse matrix, with each check equation corresponding to a check node. During the decoding process, the decoder checks whether the check condition for each check node is satisfied. Specifically, the decoder initializes the prior probability of each bit node in the data and the initial value of the check node. During each decoding iteration, the decoder updates the posterior probability of each bit node through message transmission between the bit node and the check node. Bit nodes update their posterior probabilities based on the messages from the check nodes, and check nodes update their check conditions based on the messages from the bit nodes. After each iteration, the decoder checks whether the check conditions for all check nodes are satisfied. Specifically, for each check node, the decoder checks whether the values of the connected bit nodes satisfy the check equation. If the check conditions for some check nodes are not satisfied, the decoder determines that the read has failed, and the decoder proceeds to the next decoding iteration. The decoder also estimates the bit error rate of the current decoding result. For example, taking a low-density parity check decoder as an example, after the number of iterative decoding reaches a first decoding parameter, if a check condition of a check node is not satisfied, it is determined that the target backup firmware data has failed to be read.

[0063] Optionally, if decoding of the original data returned by the non-volatile memory fails, it is determined that reading of the target backup firmware data fails.

[0064] It should be noted that in non-volatile memory, the storage state is defined by changing the threshold voltage of the memory cell. Typically, a high threshold voltage indicates that the memory cell is in the "0" state, while a low threshold voltage indicates the "1" state. Due to various factors such as wear, long-term storage, interference, etc., the threshold voltage of the memory cell may change. As the usage time increases, the threshold voltage of the memory cell may drift, resulting in the original voltage setting being unable to correctly recognize the data. In order to read the data correctly, the voltage during reading needs to be adjusted according to these changes. Through feedback information during the reading process, the voltage is adjusted in real time to optimize the accuracy of data reading.

[0065] A voltage adjustment counter is set in the non-volatile memory. When the target backup firmware data fails to be read, the storage controller queries the voltage adjustment counter to obtain the number of voltage adjustments currently attempted. The voltage adjustment counter is incremented each time the target read voltage is adjusted.

[0066] In step S33 , if the voltage adjustment times are greater than or equal to a preset adjustment times threshold, an optimal voltage is selected from the read voltages based on the bit error rate.

[0067] Step S34 , reading the target backup firmware data in the target word line again through a second decoder, a second decoding parameter, and the optimal voltage, wherein the bandwidth of the second decoder is lower than that of the first decoder, and the second decoding parameter is greater than the first decoding parameter.

[0068] Exemplarily, the memory controller compares the acquired voltage adjustment count with a preset adjustment count threshold. If the voltage adjustment count is greater than or equal to the adjustment count threshold, it indicates that multiple voltage adjustments have been attempted but the target backup firmware data has not been successfully read. At this point, the memory controller analyzes all previously attempted read voltages and their corresponding data read results, selecting the voltage most likely to successfully read data as the optimal voltage. The preset adjustment count threshold is the read voltage adjustment count threshold corresponding to the current target word line.

[0069] Optionally, when there are errors in the firmware reread data obtained after decoding the original data returned by the non-volatile memory through the decoder under all read voltages, the step of selecting the optimal voltage among the read voltages includes: obtaining the bit error rates corresponding to all read voltages, and determining the read voltage with the lowest bit error rate as the optimal voltage.

[0070] For example, after performing the firmware data rereading step using various read voltages, the decoded firmware reread data corresponding to each read voltage is compared with the original firmware data to obtain the number of error bits read, and the bit error rate is calculated based on the number of error bits. The bit error rates calculated at each read voltage are compared, and the read voltage corresponding to the minimum bit error rate is found as the optimal voltage.

[0071] Optionally, when decoding of the original data returned by the non-volatile memory by the decoder fails under all read voltages, the step of selecting the optimal voltage among the read voltages includes: obtaining symptom values corresponding to all read voltages, converting the symptom values into bit error rates through a preset conversion method, and selecting the read voltage with the lowest bit error rate as the optimal voltage.

[0072] It should be noted that during the decoding process, the decoder can obtain a variety of information, among which the syndrome value is used to detect whether there is an error in the data. If the syndrome value is a zero vector, it is generally considered that no error has been detected; if the syndrome value is non-zero, it means that an error has been detected. Among them, in the coding rules, each possible non-zero syndrome value corresponds to a specific error pattern, and the location of the error can be determined by looking up a table or calculation. If the decoder fails to decode the original data returned by the non-volatile memory under all read voltages, the decoder will send the syndrome value to the storage controller. The storage controller converts the syndrome value into a bit error rate through a preset conversion method, and uses the read voltage with the lowest bit error rate as the optimal voltage.

[0073] After determining the optimal voltage, the target backup firmware data in the target word line is read again using a second decoder, second decoding parameters, and the optimal voltage. The second decoder has lower bandwidth and stronger error correction capabilities than the first decoder, but requires more computing resources and time. Furthermore, the second decoding parameters are set greater than the first decoding parameters to further increase the probability of successful decoding. For example, if the first decoder uses simple hard-decision decoding, the second decoder can use soft-decision decoding or iterative decoding.

[0074] In this embodiment, during the first reread, a first decoder and first decoding parameters are used. The decoding algorithm used by the first decoder is relatively simple, consumes less computing resources, and has a fast decoding speed. The first decoding parameters are set relatively low to avoid excessive attempts affecting the speed. This method enables the storage controller to read data quickly, meets the requirements under normal circumstances, and reduces startup time. When the first reread fails, this embodiment improves the error correction capability and reread speed by adjusting the read voltage and upgrading the decoding strategy. The storage controller first checks the number of voltage adjustments. If it reaches a preset threshold, it means that multiple attempts have failed, and the strategy needs to be changed. Then, by analyzing the bit error rate or symptom value under all read voltages, the optimal voltage is determined to ensure that subsequent rereads are performed under the conditions most likely to succeed. At the same time, a decoder with lower bandwidth and stronger error correction capability is used for decoding, and the decoding parameters are increased to cooperate with more decoding attempts to improve the decoding success rate, balance the reread speed and error correction capability, and ultimately improve the reread speed while ensuring data accuracy.

[0075] Based on the above embodiments of the present application, in the fifth embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to above and will not be further described. Furthermore, before obtaining the number of voltage adjustment times, the method further includes: reading the target backup firmware data in the target word line using a third decoder, a third decoding parameter, and a target read voltage, wherein the bandwidth of the third decoder is lower than that of the first decoder and higher than that of the second decoder, and the third decoding parameter is greater than the first decoding parameter and less than the third decoding parameter. If the read fails, the method further executes the step of obtaining the number of voltage adjustment times.

[0076] In this embodiment, after data reading fails using the first decoder, the first decoding parameters, and the target read voltage, the data is first reread using the third decoder, the third decoding parameters, and the target read voltage. If data rereading still fails using the third decoder and the third decoding parameters, the memory controller obtains the current number of voltage adjustments to determine whether further read voltage adjustment or a more complex decoder is needed.

[0077] Optionally, the first decoder may adopt a decoding algorithm with lower decoding capability but high bandwidth and low latency, such as a low-density parity check bit flipping (LDPC Bit Flipping) hard decision algorithm; the second decoder may adopt a decoding algorithm with higher decoding capability but lower bandwidth and high latency, such as a low-density parity check minimum sum (LDPC Min-Sum) hard decision algorithm; the third decoder may adopt a decoding algorithm with the highest decoding capability, the lowest bandwidth and the highest latency, such as a low-density parity check minimum sum soft decision algorithm.

[0078] This embodiment provides an intermediate error correction layer after an initial reread fails. By setting a third decoder and third decoding parameters, it is possible to attempt to correct more errors without directly entering the most complex decoder and adjusting voltages. This layered error correction strategy avoids the use of complex decoders during the initial reread phase, conserving computing resources and avoiding the time-consuming and complex decoding process. This achieves the effect of optimizing the reread speed of firmware data while ensuring error correction capabilities.

[0079] Based on the above embodiments of the present application, in the sixth embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction and will not be described in detail later. Figure 5 After step S32, the firmware data rereading method further includes steps S35-S36: Step S35 : if the voltage adjustment times are less than the preset adjustment times threshold, redetermine the target read voltage, and reduce the first decoding parameter and the second decoding parameter.

[0080] Step S36 , executing the step of reading the target backup firmware data in the target word line using the first decoder, the first decoding parameter, and the target read voltage corresponding to the current reread step.

[0081] In this embodiment, the obtained number of voltage adjustments is compared with a preset adjustment number threshold. If the voltage adjustment number is less than the preset adjustment number threshold, it means that there is room for further attempts, and the target read voltage and decoding parameters can be further adjusted to re-read. In order to save time and computing resources in subsequent re-read attempts, the first decoding parameter and the second decoding parameter are appropriately reduced. For example, if the first decoding parameter was originally 3 times, it can be reduced to 2 times; if the second decoding parameter was originally 5 times, it can be reduced to 4 times. Optionally, the first decoding parameter can be reduced to 0 times, indicating that the decoding process of the first decoder is skipped and decoding is directly performed by the third decoder.

[0082] This embodiment increases the chances of rereading data at different voltages by redetermining the target read voltage and performing multiple attempts, thereby improving the probability of successful rereading. At the same time, by reducing decoding parameters, it avoids wasting computing resources and time on unnecessary decoding attempts, ensuring data error correction capabilities without excessively increasing the reread time.

[0083] Based on the above embodiments of the present application, in the seventh embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction and will not be described in detail later. Figure 6 After step S34, the firmware data rereading method further includes steps S37 to S39: Step S37 : If the read operation fails again, re-determine the target backup firmware data and the target word line corresponding to the target backup firmware data in the physical programming unit according to the reliability parameter.

[0084] For example, if the target backup firmware data corresponding to the current read step cannot be read again using the complex second decoder and the optimal voltage, the target backup firmware data is found from another location in the programming unit according to the reliability parameter and read again.

[0085] Step S38 , using the optimal voltage as the target read voltage corresponding to the current re-read step, and reducing the first decoding parameter and the second decoding parameter.

[0086] Step S39 , executing a step of reading the target backup firmware data in the target word line using the first decoder, the first decoding parameter, and the target read voltage corresponding to the current reread step.

[0087] After re-determining the target backup firmware data and the target word line corresponding to the target backup firmware data, the previously determined optimal voltage is used as the new target read voltage, and the step of re-reading the target backup firmware data in the target word line using the first decoder, the first decoding parameter, and the target read voltage corresponding to the current re-reading step is re-executed. Simultaneously, to optimize the subsequent re-reading process, the first decoding parameter and the second decoding parameter are reduced during the re-reading process. This is because after finding more reliable backup data, the number of decoding operations can be appropriately reduced, thereby saving computing resources and time.

[0088] It is understood that conventional firmware data rereading methods typically read the firmware data from the first storage location at each boot. If decoding fails, the firmware data backup is read from the next storage location in sequence. However, this embodiment does not employ a sequential read method. Instead, it prioritizes reading the target backup firmware data from the more reliable word lines. This increases the probability of successfully reading the firmware data, reduces the number of rereads required due to decoding failures, and thus shortens the firmware data rereading time.

[0089] For example, in order to help understand the implementation process of the firmware data rereading method obtained by combining this embodiment with the above embodiments, please refer to Figure 7 , Figure 7 A brief flowchart of a firmware data rereading method is provided, specifically: First, when firmware data reading fails, decoding parameters are modified and reliability parameters for each word line in the file programming unit are obtained. Based on the reliability parameters, target backup firmware data and the target word line corresponding to the target backup firmware data are determined in the physical programming unit. Next, the target backup firmware data in the target word line is read using a first decoder, the first decoding parameters, and the target read voltage corresponding to the current reread step. Success is checked. If unsuccessful, the target backup firmware data in the target word line is read using a third decoder, the third decoding parameters, and the target read voltage. Success is further checked. If unsuccessful, the number of voltage adjustments is obtained and a determination is made as to whether the number of voltage adjustments is greater than or equal to a preset adjustment threshold. If not, the target read voltage is re-determined, the first and second decoding parameters are reduced, and the step of reading the target backup firmware data in the target word line using the first decoder, the first decoding parameters, and the target read voltage corresponding to the current reread step is repeated. If so, an optimal read voltage is selected based on the bit error rate. The target backup firmware data in the target word line is then read again using a second decoder, the second decoding parameters, and the optimal voltage. If the read operation fails again, the target backup firmware data and the target word line corresponding to the target backup firmware data are re-determined in the physical programming unit according to the reliability parameter; the optimal voltage is used as the target read voltage corresponding to the current reread step, and the first decoding parameter and the second decoding parameter are reduced; and the step of reading the target backup firmware data in the target word line through the first decoder, the first decoding parameter and the target read voltage corresponding to the current reread step is executed.

[0090] Optionally, based on the above embodiment, in the eighth embodiment of the present application, referring to Figure 8 Prior to step S10, the step of reading firmware data includes: reading the firmware data in the preset word line using the first decoder, the fourth decoding parameter, and the preset read voltage; if the read fails, continuing to read the firmware data in the preset word line using the third decoder and the fifth decoding parameter; if the read still fails, obtaining the number of voltage adjustments; if the number of voltage adjustments is less than the threshold number of adjustments corresponding to the preset word line, modifying the preset read voltage and re-reading the firmware data in the preset word line using the first decoder, the fourth decoding parameter, and the preset read voltage. If the number of voltage adjustments is greater than or equal to the threshold number of adjustments corresponding to the preset word line, determining an optimal read voltage among the preset read voltages based on the bit error rate, and reading the firmware data in the preset word line using the second decoding algorithm, the sixth decoding parameter, and the optimal read voltage. If the read still fails, determining that the firmware data read failed. Modifying the aforementioned decoding parameters to re-read the firmware data, specifically: reducing the fourth decoding parameter to obtain the first decoding parameter, reducing the fifth decoding parameter to obtain the third decoding parameter, and reducing the sixth decoding parameter to obtain the second decoding parameter.

[0091] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the firmware data rereading method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0092] The present application provides a firmware data rereading device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the firmware data rereading method in the above-mentioned embodiment one.

[0093] Reference below Figure 9 , which shows a schematic diagram of the structure of a firmware data re-reading device suitable for implementing embodiments of the present application. The firmware data re-reading device in the embodiments of the present application may include, but is not limited to, mobile terminals such as laptop computers, tablet computers (PADs), portable multimedia players (PMPs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 9 The firmware data re-reading device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0094] like Figure 9As shown, the firmware data re-reading device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the firmware data re-reading device. Processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems may be connected to I / O interface 1006: input device 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output device 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and communication device 1009. Communication device 1009 may allow the firmware data re-reading device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a firmware data re-reading device with various systems, it should be understood that implementation or presence of all the illustrated systems is not required. More or fewer systems may alternatively be implemented or present.

[0095] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0096] The firmware data rereading device provided by this application, employing the firmware data rereading method of the aforementioned embodiment, can solve the technical problem of reducing the latency of rereading backup firmware data. Compared to the prior art, the beneficial effects of the firmware data rereading device provided by this application are the same as those of the firmware data rereading method of the aforementioned embodiment. Other technical features of the firmware data rereading device are the same as those disclosed in the aforementioned embodiment and are not further elaborated here.

[0097] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0098] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0099] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, a computer program) stored thereon, wherein the computer-readable program instructions are used to execute the firmware data rereading method in the above embodiment.

[0100] The computer-readable storage medium provided herein may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including, but not limited to, wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0101] The computer-readable storage medium may be included in the firmware data re-reading device; or may exist independently without being assembled into the firmware data re-reading device.

[0102] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the firmware data rereading device, the firmware data rereading device can write computer program codes for performing the operations of the present application in one or more programming languages or a combination thereof. The programming languages include object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user computer, partially on the user computer, or as a separate software package, partially on the user computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, through the Internet using an Internet service provider).

[0103] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of code, and the module, program segment or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, as well as the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or can be implemented using a combination of dedicated hardware and computer instructions.

[0104] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0105] The computer-readable storage medium provided in this application stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned firmware data rereading method. This computer-readable storage medium can address the technical problem of reducing the latency associated with rereading backup firmware data. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are similar to those of the firmware data rereading method provided in the aforementioned embodiments, and will not be further elaborated upon here.

[0106] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A firmware data rereading method, characterized in that: The firmware data rereading method comprises: When reading the firmware data fails, the decoding parameters are modified and the reliability parameters of each word line in the physical programming unit are obtained; determining, in the physical programming unit, a target word line and target backup firmware data corresponding to the target word line according to the reliability parameter; The target backup firmware data in the target word line is read through a decoder, the decoding parameter corresponding to the decoder, and a target read voltage corresponding to a current reread step.

2. The firmware data rereading method according to claim 1, wherein: Before the step of modifying the decoding parameters and obtaining the reliability parameters of each word line in the physical programming unit when the firmware data reading fails, the method further includes: Acquiring the firmware data, and storing the firmware data in a preset word line of the physical programming unit; Copying the firmware data to obtain the backup firmware data; A plurality of copies of the backup firmware data are stored in other word lines until the storage space in the physical programming unit is used up, wherein the other word lines are continuous word lines other than the preset word line.

3. The firmware data rereading method according to claim 2, wherein: Before the step of acquiring the firmware data and storing the firmware data in the preset word line of the physical programming unit, the method further includes: Writing test data into the physical programming unit; Erasing the test data from the physical programming unit and rewriting it according to a preset number of wear cycles; Reading the test data to determine the bit error rate corresponding to each word line in the physical programming unit; A reliability parameter of each word line is determined based on the bit error rate, wherein the bit error rate is inversely proportional to the reliability parameter.

4. The firmware data rereading method according to claim 1, wherein: The step of reading the target backup firmware data in the target word line by using a decoder, the decoding parameter corresponding to the decoder, and a target read voltage corresponding to the current reread step includes: Reading the target backup firmware data in the target word line using a first decoder, a first decoding parameter, and a target read voltage corresponding to the current reread step; If the reading fails, obtain the number of voltage adjustments; If the voltage adjustment times are greater than or equal to a preset adjustment times threshold, selecting an optimal voltage among the read voltages based on a bit error rate; The target backup firmware data in the target word line is read again by using a second decoder, a second decoding parameter and the optimal voltage, wherein the bandwidth of the second decoder is lower than that of the first decoder and the second decoding parameter is greater than the first decoding parameter.

5. The firmware data rereading method according to claim 4, wherein: Before the step of obtaining the number of voltage adjustment times, the method further includes: Reading the target backup firmware data in the target word line using a third decoder, a third decoding parameter, and the target read voltage, wherein the bandwidth of the third decoder is lower than that of the first decoder and higher than that of the second decoder, and the third decoding parameter is greater than the first decoding parameter and less than the third decoding parameter; The obtaining of the number of voltage adjustment times includes: If the reading fails, obtain the number of voltage adjustments.

6. The firmware data rereading method according to claim 4 or 5, wherein: After the step of obtaining the number of voltage adjustment times, the method further includes: If the voltage adjustment times are less than the preset adjustment times threshold, re-determining the target read voltage and reducing the first decoding parameter and the second decoding parameter; The step of reading the target backup firmware data in the target word line using a first decoder, a first decoding parameter, and a target read voltage corresponding to the current reread step is performed.

7. The firmware data rereading method according to claim 4 or 5, wherein: After the step of re-reading the target backup firmware data in the target word line using the second decoder, the second decoding parameter and the optimal voltage, the method further includes: If the read fails again, re-determining the target backup firmware data and the target word line corresponding to the target backup firmware data in the physical programming unit according to the reliability parameter; Using the optimal voltage as a target read voltage corresponding to the current reread step, and reducing the first decoding parameter and the second decoding parameter; The step of reading the target backup firmware data in the target word line is performed using a first decoder, a first decoding parameter, and a target read voltage corresponding to the current reread step.

8. The firmware data rereading method according to claim 4, wherein: The step of selecting an optimal voltage among the read voltages based on the bit error rate comprises: Get the bit error rate corresponding to all read voltages; The read voltage with the lowest bit error rate is determined as the optimal voltage.

9. A firmware data rereading device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the firmware data rereading method according to any one of claims 1 to 8.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the firmware data rereading method according to any one of claims 1 to 8 are implemented.

Images