A refresh cycle adaptation method for memory cells

Abstract

The application relates to the technical field of data storage, and discloses a refresh cycle self-adapting method of a memory particle, which comprises the following steps: when it is found that the memory particle is damaged, the refresh cycle time of the memory particle is debugged; a preset first time is taken as an initial refresh cycle time, the memory particle is caused to read data at the initial refresh cycle time; if the read data is correct data, the preset first time is taken as a target refresh cycle time; if the read data is error data, a preset gradient time is added to the preset first time to obtain a preset second time, the preset second time is taken as the refresh cycle time, and the memory particle is caused to read data at the refresh cycle time which is obtained by adding the preset gradient time to the preset first time. The application can more accurately find the adaptation defects of different data types in the cycle, and ensures that the target cycle can guarantee data integrity in a complex application scenario.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to an adaptive method for the refresh cycle of memory chips. Background Technology

[0002] The refresh time of memory chips is one of the core technologies enabling DRAM (Dynamic Random Access Memory) to function properly. Its essence is to counteract the physical characteristics of capacitors, thereby maintaining data integrity. The basic memory cell of DRAM is a cell consisting of a capacitor and a transistor (usually an N-channel MOSFET). The capacitor represents binary data (0 or 1) by whether it stores charge. However, this capacitor has a natural leakage phenomenon, causing the charge to gradually dissipate. If left unattended, the stored data will eventually be lost. To maintain data, the capacitor must be periodically "refreshed," i.e., recharged to restore its original charge level. This operation needs to be repeated for all memory cells throughout the entire refresh cycle (typically 64ms for standard DRAM). If the refresh operation fails to complete on time, data corruption or loss will occur. In practice, the refresh process is precisely controlled by the memory controller and defined by several key timing parameters: tREFI, which is the average refresh command interval. The controller needs to initiate a refresh operation every certain period of time (tREFI). For example, for a DRAM chip with 8192 rows, theoretically, tREFI (refresh rate function) would be approximately 3.9µs (64ms / 8192) to refresh all rows within 64ms. This interval ensures that each row is refreshed within the specified time. tRFC is the refresh cycle time. After the controller issues a refresh command, the memory chip needs a period of time to complete the actual charging and stabilization operation; this time is the refresh cycle time. tRFC is typically much longer than the time required to read or write a single cell because the refresh operation involves charging and restoring the entire row of cells. The value of tRFC increases with the increase in memory chip capacity because more storage cells require longer operation times.

[0003] Since the refresh cycle time of a certain capacity of memory is fixed, if part of the memory is damaged, its refresh cycle time will be reduced accordingly. For example, the refresh cycle time corresponding to 8GB of memory is 280ns. If 4GB of the 8GB memory is damaged, that is, the memory capacity is reduced from 8GB to 4GB, the refresh cycle time of 4GB capacity is 200ns. This will cause data to be read before it is written, resulting in data reading errors. Therefore, an adaptive refresh cycle time is needed. Summary of the Invention

[0004] This invention provides an adaptive refresh cycle method for memory chips, which can solve the technical problem that if a certain capacity of memory is damaged, its refresh cycle time will be reduced accordingly, causing data to be read before it is written, resulting in data reading errors. Therefore, an adaptive refresh cycle time is needed.

[0005] To solve the above-mentioned technical problems, one technical solution adopted by the present invention is: to provide an adaptive refresh cycle method for memory chips, the method comprising:

[0006] When a memory chip is found to be damaged, adjust the refresh cycle time of the memory chip.

[0007] The initial refresh cycle time is set to the preset first time, so that the memory chips read data at the initial refresh cycle time.

[0008] If the data read is correct, the preset first time will be used as the target refresh cycle time.

[0009] If the read data is incorrect, a preset gradient time is added to the preset first time to obtain a preset second time. The preset second time is used as the refresh cycle time, so that the memory chip reads data with the preset gradient time added to the preset first time during the refresh cycle. If the read data is correct, the preset second time is used as the target refresh cycle time. Otherwise, the preset gradient time is continuously added to the preset second time until the data read from the memory chip is correct.

[0010] The beneficial effects of this invention are as follows: By innovatively introducing a dual verification system of "baseline / random address read" and "multi-mode write-readback," the former focuses on the stability of reading existing data, while the latter covers the entire "write-storage-readback" chain. Furthermore, it designs four differentiated write modes (continuous value, alternating bits, random value, and increasing sequence) to simulate various data storage scenarios in real-world memory applications (such as system caching, file storage, and log recording). Compared to traditional single-data verification, it can more accurately identify the adaptation defects of the cycle to different data types (e.g., some cycles only support continuous value storage and are prone to errors when storing random values), ensuring that the target cycle can still guarantee data integrity in complex application scenarios, and reducing the data storage error rate to below 0.001%. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating the adaptive refresh cycle method for memory chips according to the first embodiment of the present invention.

[0012] Figure 2 yes Figure 1 A flowchart illustrating step 1.

[0013] Figure 3 yes Figure 1 A flowchart illustrating step 3.

[0014] Figure 4 yes Figure 1 A flowchart illustrating step 4. Detailed Implementation

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

[0016] The terms "comprising" and "having," and any variations thereof, used in this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0017] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0018] Figure 1 This is a flowchart illustrating the adaptive refresh cycle method for memory chips according to the first embodiment of the present invention. Figure 1 As shown, the method is as follows:

[0019] Step 1: When a memory chip is found to be damaged, adjust the refresh cycle time of the memory chip.

[0020] Step 2: Use the preset first time as the initial refresh cycle time, so that the memory chips read data at the initial refresh cycle time;

[0021] Step 3: If the data read is correct, then set the preset first time as the target refresh cycle time;

[0022] Step 4: If the read data is incorrect, add a preset gradient time to the preset first time to obtain a preset second time. Use the preset second time as the refresh cycle time, so that the memory chip reads data with the preset gradient time added to the preset first time during the refresh cycle. If the read data is correct, use the preset second time as the target refresh cycle time. Otherwise, continue to add the preset gradient time to the preset second time until the data read from the memory chip is correct.

[0023] Step 1: Trigger the refresh cycle debugging process. After confirming the memory chip is damaged, start the refresh cycle debugging, connecting the initial configuration phase with subsequent data reading and cycle adjustment operations, and clarify the debugging start conditions and execution timing. Use MemTest, system anomalies (blue screen, garbled data), or hardware diagnostics to rule out external factors such as poor memory slot contact or motherboard controller failure, confirming that the root cause of the damage is the memory chip itself. Ensure the debugging environment is stable (normal power supply voltage and ambient temperature), with no external interference affecting the accuracy of data reading.

[0024] Run the Mem Test tool again to check the chip error rate and fault type, and compare it with the damage assessment results from the initial configuration phase to confirm that the damage status has not changed (e.g., the error rate has not suddenly increased due to environmental factors). Use a multimeter to check the memory power supply voltage (e.g., DDR4 standard power supply 1.2V) to ensure that the voltage fluctuation is within ±5%; use an oscilloscope to observe the memory bus signal and eliminate signal interference issues. Load the parameters saved during the initial configuration phase (preset first time, gradient time, and baseline data address) in the dedicated debugging software, and click the "Start Refresh Cycle Debugging" function to proceed to the data reading stage in step 2.

[0025] If the damage suddenly worsens during the review (e.g., the error rate increases from 10% to 50%), the power supply or hardware connection issues must be checked first. Do not start debugging directly to avoid further damage to the chips. After debugging begins, the debugging software parameters must be locked, and the preset values ​​from the initial configuration phase must not be modified midway to ensure consistent debugging logic.

[0026] Step 2: Initial periodic data reading. The initial refresh cycle is set to the first preset time. The benchmark test data in the memory chip is read to obtain the original basis for the first data verification, which provides a basis for subsequent result judgment.

[0027] Step 1 has successfully started debugging, with the initial refresh cycle register value set to the preset first time (e.g., 64ms). Benchmark data has been written to the specified address, and the write result has been verified (data and checksum are correct). The debugging software has located the benchmark data storage address and has data reading and caching capabilities.

[0028] In the debugging software, check the current value of the refresh cycle register to confirm that it is still set to the preset first time (without any abnormal modifications). Wait for one complete initial refresh cycle (e.g., 64ms) to ensure that the memory chip completes one refresh operation according to this cycle. Send a read command to the memory chip to read data from the reference data storage address (e.g., 0x000000-0x000007). Temporarily store the read result in the debugging software's buffer, and record the read time and the current cycle value. Convert the format of the read data in the buffer (e.g., convert binary data to hexadecimal) to remove any format redundancy that may occur during the read process (e.g., checksum markers) to ensure that the data format is consistent with the reference data for easy comparison later.

[0029] During the reading process, other programs that consume memory bandwidth (such as background data transfers and large software applications) need to be paused to avoid bandwidth contention leading to reading delays or data distortion. If a timeout error occurs during reading (such as the software displaying "ReadTimeout"), the memory bus connection or the power supply to the memory chips should be checked. After ruling out hardware failures, the reading should be attempted again. Do not directly conclude that the data is incorrect.

[0030] Step 3: Initial Data Verification and Preliminary Determination of the Target Period. Compare the data read in Step 2 with the benchmark test data to determine if the initial refresh period is suitable for the damaged particles. If it is suitable, directly determine the target period to avoid redundant adjustments later. Step 2 has completed data reading, and the buffer stores complete read data (no timeouts or format errors). The benchmark test data and corresponding CRC32 checksums have been imported into the debugging software and can be retrieved for comparison at any time. The debugging software has bit-by-bit / byte-by-byte comparison capabilities and supports displaying the location of comparison differences (such as a mismatch in the value of a certain byte).

[0031] In the debugging software, activate the "Data Comparison" function, select "Read Data" and compare it bit by bit with "Baseline Data," simultaneously calculating the CRC32 checksum of the read data and comparing it with the checksum of the base data. If the bit-by-bit comparison is completely consistent and the checksum matches, the data is considered "correct." If any bit or byte does not match or the checksum is incorrect, the data is considered "incorrect." For example, if the read data is 0x5A6B7C8D9E0F1A2B, which is completely consistent with the base data and both have a CRC32 checksum of 0x12345678, then the data is considered correct. If the data is correct, record "Target Refresh Cycle = Preset First Time" in the debugging software, generate a debugging report (including cycle value, checksum result, and read time), and terminate the debugging process. Subsequently, granularity can be configured according to this cycle to periodically check data stability.

[0032] During verification, both "bit-by-bit comparison" and "checksum comparison" must be performed simultaneously to avoid misjudgment due to a single comparison method (if a bit error is missed during bit-by-bit comparison, the checksum can be used to supplement the identification). If the data is correct, it needs to be read and verified three times consecutively to ensure stable results (no sporadic correctness) before determining the target period.

[0033] Step 4: Gradient Increment Adjustment and Iterative Verification. When step 3 determines that the data is incorrect, the refresh cycle is adjusted by continuously adding gradient time, iterating through "cycle update - data read - verification" until a target cycle that can read the correct data is found, resolving the read error caused by particle damage. Since step 3 has determined that the data is incorrect, the cycle adjustment phase must be initiated. The gradient time set in the initial configuration phase (e.g., 8ms) has been loaded into the debugging software and can be directly called for addition. The debugging software supports automatic calculation of cycle values ​​and automatic register updates, reducing manual operation errors.

[0034] Calculate the new cycle: Add the gradient time to the preset first time to obtain the preset second time (formula: preset second time = preset first time + gradient time, e.g., 64ms + 8ms = 72ms). Update register values: According to the register value mapping rules in step 101, convert the preset second time to a hexadecimal register value (e.g., 72ms corresponds to 0x0480), and automatically write it to the refresh cycle register through the debugging software. Wait 1-2 clock cycles to ensure it takes effect. Secondary data reading and verification: Following the operation process in step 2, read the reference data with the preset second time as the cycle, and compare it according to the verification rules in step 3. If the data is correct, record "target refresh cycle = preset second time", and debugging terminates; if incorrect, continue the adjustment process.

[0035] Continuous Overlay Adjustment (Preset Second Time and Beyond): Iterative Calculation of New Cycle: Based on the current error cycle (e.g., preset second time 72ms), gradient times are overlaid again to generate a new cycle value (e.g., 72ms + 8ms = 80ms, i.e., preset third time). Looping Execution: After each new cycle is generated, the "convert register value - update register - read data - verify" process is repeated, recording the cycle value, read result, and verification status each time (e.g., still incorrect at 80ms, correct at 88ms). Debugging Termination Condition: When the data read in a certain instance is completely consistent with the baseline data and the verification value matches, the overlay adjustment stops, the current cycle value is determined as the target refresh cycle, a debugging report is generated, and the cycle adjustment process is clearly defined (e.g., from 64ms to 88ms after 3 overlays).

[0036] Set a maximum number of attempts (80-100 recommended). If the maximum number of attempts is reached and correct data is still not read, the particle damage is determined to be beyond the periodic adjustment and repair range (e.g., physical damage to the storage unit). Debugging is stopped and a replacement particle is prompted. After determining the target period, read data 10 times consecutively and verify. If all reads are correct, stability is confirmed. If occasional errors occur, an additional gradient time can be added (e.g., 88ms + 8ms = 96ms) to verify stability again. Record the period value, reading results, and verification difference locations for each adjustment to facilitate subsequent analysis of particle damage patterns (e.g., a high error rate in a certain period reflects the characteristics of the damaged area).

[0037] After determining the target refresh cycle, run the Mem Test tool continuously for 24 hours to monitor the memory chip error rate (target error rate < 0.1%), and record the system running status (no blue screens, no program crashes). If everything is normal, the cycle adaptability is good. Review the memory chip refresh cycle register value weekly to ensure no abnormal modifications have been made. Run data verification monthly, comparing the baseline data with the currently read data to confirm cycle stability. If the data error rate subsequently increases, steps 1-4 can be repeated to fine-tune the gradient time.

[0038] Before step 1, the method further includes:

[0039] Step 101: Set the refresh cycle register value of the memory chip to the preset first time through register operations of the memory controller, hardware driver interface or dedicated debugging tools;

[0040] Step 102: Set a preset gradient time based on the degree of damage to the memory chips and their sensitivity to periodic changes;

[0041] Step 103: Write a fixed and unique piece of test data to a specified storage address in the memory chip in advance. This will serve as the baseline data for judging whether the data reading is correct, thus avoiding misjudgment due to the simplicity of the baseline data.

[0042] Step 101: Initial Refresh Cycle Register Configuration. Write the preset first refresh time (the standard refresh cycle reference value for memory chips) into the refresh cycle register to provide an initial cycle baseline for the first data read, ensuring the debugging start point conforms to the chip's hardware characteristics. Obtain the target memory chip's manufacturer's specification sheet and clarify the refresh cycle register address (e.g., 0x1200 for DDR4 chips, 0x2400 for DDR5 chips) and the mapping relationship between register values ​​and actual cycles (e.g., 0x0400 corresponds to 64ms). Prepare the corresponding tools: memory controller register read / write tools (e.g., J-Link, Xilinx PlatformCable), hardware drivers (adapted to the target memory model), and dedicated debugging software (e.g., Mem Probe). Confirm that the memory chips are correctly connected to the debugging environment, and there are no issues such as poor hardware contact or abnormal power supply.

[0043] First, connect the register read / write tool to the memory controller via a debug interface (such as JTAG or SPI), ensuring a stable and secure connection. Next, launch the debug software and select the target memory chip model (e.g., "Samsung K4A8G165WB-BCRC") in the "Target" option to avoid incorrect model selection that could cause subsequent operations to fail. Finally, locate and enter "Register Configuration Mode" in the software's function bar, simultaneously loading the register mapping table corresponding to the memory chip to prepare for locating the register address later. For a practical example, you can use a J-Link to connect to the motherboard's JTAG interface, launch the SeggerOzone software, select "DDR4-Samsung K4A8G165WB" in the "Target" option, and click "Reg Config" to enter configuration mode.

[0044] According to the memory chip manufacturer's datasheet, the preset first time (e.g., 64ms) should be converted into a hexadecimal value that the register can recognize. The conversion process must strictly follow the mapping rules in the datasheet; do not estimate it yourself. If the chip supports multiple period units (e.g., ms, ns), you must first confirm the current register's unit setting before performing the corresponding conversion to ensure the conversion result matches the unit. For example, if the datasheet clearly states "64ms corresponds to register value 0x0400," then you can directly determine the write value as 0x0400. If the register unit is ns, you must first convert 64ms to 64,000,000ns, and then calculate the final register value according to the calculation formula provided in the datasheet (e.g., register value = period value / unit conversion factor).

[0045] In the register operation interface of the debugging software, locate the refresh cycle register address (e.g., 0x1200) using the search function or by manually finding it. After confirming the address is correct, enter the converted register value in the value input box and click the "Write" button to perform the write operation. Do not perform subsequent operations immediately after writing; wait 1-2 memory clock cycles to ensure the register value is fully written and takes effect. The specific waiting time can be calculated based on the clock frequency of the memory chips. For example, the clock cycle of DDR4-3200 is approximately 0.3125ns, so wait at least 0.625ns. Taking Segger Ozone software as an example, find address 0x1200 in the "Register" interface, enter 0x0400, and click "Write." Wait for the status bar to display "WriteSuccess," then wait another 1ns before proceeding to the next step.

[0046] After writing the register value and waiting for it to take effect, click the "Read" button in the debugging software to read the value currently stored in the refresh cycle register. Compare the read value with the previously converted preset first-time value. If they are completely consistent, the register configuration is successful. If the values ​​are inconsistent, troubleshooting is required. Possible causes include loose tool connections, incorrect register addresses, insufficient write permissions, etc. When troubleshooting, first check the tool connections and replug the debugging interface. If the problem persists, check if the register address matches the manual and if write permissions are available. After troubleshooting, re-execute the write operation until the configuration result is verified. For example, if the read value at address 0x1200 is 0x0400, which matches the preset conversion value, step 101 is considered complete. If the read value is 0x0000, first check if the JTAG connection is loose, replug it, and then try reading and comparing again.

[0047] Blindly writing to registers without confirming their addresses is prohibited to avoid modifying other critical registers (such as power control registers and data transfer registers), which could lead to hardware damage to the memory chips or system malfunctions. When writing register values, ensure stable communication between the debugging tool and the memory controller. If communication is interrupted during the writing process, first investigate the cause of the interruption (e.g., poor interface contact, software crash), resolve the issue, and then re-execute the writing operation. Do not directly repeat the writing operation. The mapping relationship between refresh cycle register addresses and values ​​may differ between different memory chip models; do not directly apply configuration parameters from other models, but always refer to the target chip manufacturer's specification sheet.

[0048] Step 102: Preset gradient time setting. Based on the actual damage level of the memory chips and their sensitivity to cycle changes, determine a reasonable preset gradient time. This ensures that when adjusting the refresh cycle later, a suitable cycle value can be accurately found, while avoiding low debugging efficiency or failure due to unreasonable gradient time. Damage data of the memory chips, including error rate and fault type (e.g., partial damage, overall damage), has been obtained using professional testing tools (such as MemTest and memory fault diagnostic tools). Equipment such as an oscilloscope is available to monitor the working status of the memory chips at different cycles, helping to determine their sensitivity to cycle changes. The normal refresh cycle adjustment range of the target memory chips is understood to avoid setting the gradient time outside the reasonable range.

[0049] The degree of damage to memory chips is analyzed using data obtained through professional testing tools. The specific criteria for judgment are as follows: If the system experiences only occasional data read errors, the Mem Test error rate is <5%, and the chips do not exhibit significant overheating during operation, it can be classified as slightly damaged. If the system frequently experiences blue screens and program crashes, the Mem Test error rate is between 5% and 30%, and the chips occasionally display garbled characters when reading data, it is classified as moderately damaged. If the system cannot boot normally, the Mem Test error rate is >30%, the chips continuously overheat during operation, and even exhibit hardware overheating, it is classified as severely damaged. Multiple tests are required during the judgment process, and the average error rate is used as the basis for judgment to avoid the influence of single test errors on the results.

[0050] Connect an oscilloscope to the refresh signal pin of the memory chip to monitor signal changes at different refresh cycles. If a slight adjustment to the cycle (e.g., increasing it by 4ms) causes a significant change in signal stability and a large fluctuation in the data read error rate, it indicates that the chip is highly sensitive to cycle changes. Conversely, if a large change in cycle (e.g., increasing it by more than 32ms) is required for a significant change in signal stability and data read error rate, it indicates that the chip is less sensitive to cycle changes. During monitoring, other test conditions (such as power supply voltage and ambient temperature) must be kept stable to avoid external factors interfering with the sensitivity assessment results.

[0051] Based on the degree of particle damage and sensitivity to periodic changes, the gradient time value is determined following the principle of "precision first, efficiency second": For highly sensitive particles with slight or moderate damage, a smaller gradient time (4ms / 8ms) is selected. This ensures accurate positioning of the appropriate periodic value during adjustment while avoiding skipping the optimal period due to an excessively large gradient. For low-sensitivity particles with severe damage, a larger gradient time (16ms / 32ms / 64ms) can be selected to speed up the debugging process and reduce the number of invalid attempts. After determining the gradient time, it must be recorded in the debugging parameter log table and saved to the parameter configuration file of the debugging tool to ensure that it can be directly called during subsequent gradient adjustments, avoiding repeated settings.

[0052] Gradient timing should not be set solely based on experience. It must be combined with the actual damage level and sensitivity data of the memory chips. Otherwise, the gradient time may be too large, missing the optimal period value, or too small, prolonging the debugging time. If the chip sensitivity cannot be accurately determined during the testing process (e.g., abnormal oscilloscope data), an intermediate gradient time (e.g., 16ms) can be selected for debugging first. Subsequently, the gradient time can be flexibly adjusted based on the debugging results (e.g., multiple adjustments still fail to read the correct data). Memory chips of the same model produced in different batches may have different sensitivities after damage due to process differences. The gradient time must be determined and set individually for each damaged chip; the same gradient value cannot be applied to a batch.

[0053] Step 103: Write benchmark test data. Write fixed and unique test data at a specified storage address of the memory chip to provide a clear benchmark for subsequent data reading correctness verification. Avoid misjudgment due to simple benchmark data (such as all 0s or all 1s) and ensure the accuracy of data verification results during debugging.

[0054] It has been confirmed that the memory chips contain free address segments not occupied by system or user data, or that dedicated test address areas have been designated (such as reserved memory test areas in embedded systems) to prevent the written benchmark data from overwriting useful data. A data generation tool is prepared to generate unique data containing random sequences and fixed identifiers, and also has data verification capabilities to verify the integrity of the written data. The write function of the memory chips is confirmed to be normal. If a write failure occurs, the cause of the failure must be investigated first (such as physical damage to the chips or interface failure); benchmark data should not be written directly beforehand.

[0055] Using memory address mapping tools or the system memory management interface, check the address allocation of memory chips and filter out free address segments without any data usage. The length of the address segment must meet the storage requirements of the benchmark test data (e.g., if the data length is 64 bits, the address segment must contain at least 8 consecutive address units). Simultaneously, ensure that this address segment will not be automatically occupied by the system or other programs during subsequent debugging. For embedded systems, you can directly select the manufacturer-reserved dedicated test address area (e.g., 0x000000-0x00FFFF). This type of address area is usually not used by regular programs and offers higher security. After selection, record the start and end addresses of the address segment for accurate positioning during subsequent write and read operations.

[0056] Using professional data generation tools, generate a unique binary or hexadecimal data segment. The data design must adhere to the principles of "non-repetitive and easy to verify," and can include two parts: a random sequence and a fixed identifier. For example, in 64-bit data 0x5A6B7C8D9E0F1A2B_5A6B7C8D9E0F1A2B, "5A6B" is the fixed identifier, and the rest is a random sequence. Avoid generating simple, repetitive data (such as 0x00000000 or 0xFFFFFFFF), as this type of data may still be readable even when the particle is partially damaged, leading to false positives. Simultaneously, calculate a checksum (such as a CRC32 checksum) for the generated data and save it along with the data, providing double protection for subsequent verification.

[0057] Activate the "Data Write" function of the programmer or debugging tool. Enter the selected target memory address (starting address) in the address input box, import the generated unique test data into the tool, and click the "Write" button to execute the write operation. During the write process, ensure a stable connection between the tool and the memory chip to prevent write interruptions that could lead to incomplete data. After writing is complete, immediately use the tool's "Data Read" function to read data from the same memory address. Compare the read data bit by bit with the original generated test data, and simultaneously check if the data checksum is consistent. If the read data is completely consistent with the original data and the checksum matches, the baseline data has been successfully written. If the data is inconsistent or the checksum fails, recheck whether the target address is occupied and whether the chip's write function is working properly. After troubleshooting, reselect the address and execute the write operation again until the write result is verified. After successful verification, record the memory address, original data content, and checksum of the baseline data in detail to provide a basis for data verification during subsequent debugging.

[0058] Before writing baseline data, it is necessary to confirm again that there is no useful data at the target storage address. This can be done by reading the current data at that address and backing it up (if there is data), to avoid data loss due to incorrect address selection. During data writing and reading verification, other programs or processes that may occupy that memory address must be closed to prevent data tampering and affecting the accuracy of the verification results. If verification still fails after multiple write attempts, and factors such as address occupancy and tool malfunction have been ruled out, the memory chip's write function may be damaged. In this case, write operations must be stopped, and the chip must be determined to be beyond repair through refresh cycle debugging, requiring replacement with a new chip.

[0059] Step 102 includes:

[0060] Step 1021: If the memory chips are slightly damaged, set a smaller gradient and find the optimal cycle.

[0061] Step 1022: If the memory chips are significantly damaged, increase the gradient and speed up the debugging process.

[0062] Step 1021: Gradient setting and optimal cycle location for minor damage scenarios. Gradient value determination: When the chip is determined to be slightly damaged (e.g., error rate 2%, only occasional data read errors, no blue screen), regardless of the cycle sensitivity, a smaller gradient time of 4ms or 8ms is preferentially selected. For example, for slightly damaged DDR4 chips with high sensitivity, set it to 4ms; for slightly damaged chips with low sensitivity, set it to 8ms, ensuring that the gradient adjustment can accurately capture the optimal cycle.

[0063] Starting from a preset initial time (e.g., 64ms), after each 4ms / 8ms gradient time is added, data needs to be read and verified three times consecutively, and the error rate for each time needs to be recorded (e.g., 2% error rate for 64ms, 1% error rate for 68ms, and 0% error rate for 72ms). When there are no errors in three consecutive verifications and the error rate is stable at 0%, the current period (e.g., 72ms) is determined to be the optimal period; if the error rate decreases first and then increases after the addition (e.g., the error rate decreases from 64ms to 68ms, and increases from 72ms to 76ms), then the period with the lowest error rate (e.g., 68ms) is selected as the optimal period.

[0064] Example: Samsung K4A8G165WB-BCRC NAND flash memory, 3% error rate (minor damage), high sensitivity, gradient time set to 4ms. Starting from 64ms, 64ms (3% error rate) → 68ms (1% error rate) → 72ms (0% error rate, 3 consecutive correct tests), finally 72ms was determined to be the optimal period.

[0065] Step 1022: Gradient settings and debugging efficiency improvement for obviously damaged scenarios. Gradient value determination: When the chip is determined to be moderately or severely damaged (e.g., error rate of 15%, frequent blue screens; or error rate of 40%, unable to start normally), i.e., the damage is obvious, adjust the gradient time according to the sensitivity: set it to 16ms for high sensitivity and 32ms or 64ms for low sensitivity. By increasing the gradient, the number of invalid attempts is reduced, and the debugging process is accelerated. For example, for DDR5 chips with moderate damage and high sensitivity, set it to 16ms; for severely damaged chips with low sensitivity, set it to 64ms.

[0066] After each gradient stacking, only one data reading and verification is needed (no need for three consecutive readings). If the data is correct, two more verifications are performed to confirm stability; if the data is incorrect, proceed directly to the next gradient stacking, reducing waiting time. For example, with a preset initial time of 32ms (DDR5), a gradient of 16ms, the process is: 32ms (error) → 48ms (error) → 64ms (correct). After two additional verifications, both are correct, directly determining 64ms as the target period, eliminating the need for continuous verification and shortening debugging time. Practical example: Micron MT53E2G32D4NQ-046 NAND flash memory, 35% error rate (severe damage), low sensitivity, gradient time set to 64ms. 32ms (error) → 96ms (error) → 160ms (correct). After two additional verifications, both are correct, debugging is completed within 10 minutes, an 80% efficiency improvement compared to a 4ms gradient (requiring multiple stackings). Gradient time recording and saving: Record the determined gradient time (e.g., 4ms, 16ms) to the debugging parameter table, and save it to the "gradient configuration template" of the debugging tool for easy access in similar damage scenarios.

[0067] In step 1021, if a minor damage scenario occurs where "multiple consecutive cycles are error-free" (e.g., 72ms, 76ms, and 80ms are all correct), the shortest cycle (72ms) is selected as the optimal cycle to avoid excessively extending the cycle and causing memory performance loss.

[0068] In step 1022, although the gradient is increased for obviously damaged scenarios, it is necessary to ensure that the gradient value does not exceed 10% of the maximum supported cycle of the particle (e.g., if the particle's maximum supported cycle is 256ms, the gradient should not exceed 25.6ms, so use 24ms or 32ms) to avoid exceeding the hardware's tolerance. Different batches of the same model of particle may have different sensitivities due to process differences, and must be determined and set individually, and cannot be applied in batches.

[0069] Figure 2 yes Figure 1 The flowchart for step 1 is as follows: Figure 2 As shown, step 1 includes:

[0070] Step 104: After configuring the preset first time, you need to wait for 1-2 complete refresh cycles to ensure that the hardware circuit completes the parameter response and avoids subsequent data reading abnormalities due to the cycle not taking effect.

[0071] Step 105: When a memory chip is found to be damaged, a data read command is sent to the memory chip to read data from the address where test data has been written beforehand.

[0072] Step 104: Configure the preset wait operation after the first time. Refresh cycle: This refers to the period at which the hardware circuit refreshes the data at fixed time intervals to maintain the validity of data in memory and other storage units. The specific duration needs to be referred to the technical specifications of the currently used hardware (e.g., the refresh cycle of common memory chips may be 64ms, 128ms, etc., and there are differences between different hardware models). 1-2 complete refresh cycles: If the hardware technical specifications specify the refresh cycle as T, then the waiting time range is T-2T. For example, when the refresh cycle is 64ms, you need to wait 64ms-128ms.

[0073] After completing the preset initial configuration operation, confirm through the hardware monitoring interface or dedicated testing tool that the configuration parameters have been successfully written to the hardware control module (e.g., displaying prompts such as "Configuration successful" or "Parameters saved"). Record the start time: Use a timer (such as the hardware's built-in timing function, computer timing software, or a high-precision stopwatch) to record the exact time the configuration was completed, as the starting point of the waiting time.

[0074] First, consult the hardware specifications to obtain the standard refresh cycle T for that hardware. Calculate the required waiting time range (T-2T) based on T, and strictly adhere to this range. During this time, avoid any parameter modifications, data read / write operations, or other operations on the hardware to prevent interference with the parameter response process. If the hardware does not explicitly specify a refresh cycle, refer to the common refresh cycle of similar hardware (e.g., the default refresh cycle of mainstream memory chips in the industry is 64ms), or consult the hardware supplier for accurate data to avoid insufficient or excessive waiting time due to estimation errors.

[0075] After the waiting period ends, use the hardware status detection function to check whether the circuit parameters have stabilized (e.g., the parameter values ​​no longer fluctuate and meet the preset standard range). If the parameters are still unstable, the refresh cycle needs to be reconfirmed, and wait for 1-2 complete cycles again until the parameters stabilize.

[0076] Step 105: Data reading operation when memory chip is damaged. The memory chip has been confirmed to be damaged (such as bad sectors, data storage errors, inability to respond to instructions, etc.) by memory testing tools (such as Mem Test, hardware built-in diagnostic program), and test data has been written to the healthy memory area in advance (the test data must contain clear identification information, such as data number, writing time, check code, etc., to facilitate subsequent identification and verification).

[0077] Select a professional data reading tool (such as a hardware debugger or memory data reading software) that is compatible with your current memory model. Ensure that the tool has the correct driver installed and has established a stable connection with the memory (such as through a PCIe interface, SATA interface, etc. For specific connection methods, please refer to the memory and tool's user manual).

[0078] Obtain the specific address of the pre-written test data from the memory management log or pre-recorded document (the address must be accurate to the start and end address of the memory unit, such as "0x10000000-0x10000FFF"). If the address record is unclear, the address range can be located by using the memory scanning function based on the identification information of the test data (such as specific checksums and data formats).

[0079] In the operation interface of the reading tool, enter the located test data address, select the "data reading" mode (such as "single read" or "continuous read", it is recommended to select "single read" first to avoid causing additional damage to the damaged chip due to continuous reading); click the "send command" button to send the data reading command to the memory chip, and at the same time enable the tool's log recording function to record the status information during the reading process in real time (such as command sending success / failure, reading progress, error prompts, etc.).

[0080] If the read command is executed successfully, the tool will display the data read from the target address. At this point, the read data needs to be compared with the pre-written test data (such as checking the data content, checksum, data length, etc.) to determine whether the data is complete and whether there is any distortion or loss. If the read command fails to execute (such as the tool prompting "read timeout", "address inaccessible", "data error"), you need to first check whether the connection between the reading tool and the memory is normal and whether the address is correct. If the connection and address are both fine, it may be that the damaged memory chip is completely unable to respond to the read command. In this case, you need to stop the read operation to avoid the tool continuously sending commands, which may cause the memory to overheat or the circuit to be damaged.

[0081] Regardless of whether the read is successful or not, the read results must be recorded in detail, including the read time, target address, read data content (or error message), data comparison results, etc., to form a complete operation report, which will provide a basis for subsequent memory fault analysis, repair or replacement.

[0082] If the test data read is complete and error-free, it means that the damaged memory chip has not affected the address area where the test data was written beforehand, and the status of other memory areas can be further checked. If the test data is distorted, lost, or cannot be read, the damaged address range should be marked, and the damaged memory chip should be replaced in time to avoid the spread of the damaged chip and affect the stability of the entire memory system.

[0083] After step 2, the method further includes:

[0084] Step 201: Compare the read data with the original data to determine whether the two data are consistent;

[0085] Step 202: When the read data matches the original data, the read data is determined to be correct.

[0086] Step 203: When the read data is inconsistent with the original data, the read data is determined to be erroneous. The system automatically triggers the refresh cycle adjustment mechanism, gradually increasing the preset gradient time. After each adjustment, the data is read and verified again until the data is correct. The final target refresh cycle time will be recorded and used for subsequent aging tests and reliability analysis to ensure the stable operation of memory chips on different platforms.

[0087] Step 201: Compare the read data with the original data. By accurately comparing the read data with the original data, the core basis for subsequent data correctness determination and refresh cycle adjustment is provided, avoiding misjudgment of memory operation status due to unidentified data differences.

[0088] Test data pre-written to the healthy memory region must include complete basic information (such as character sequences and numerical combinations), verification information (such as CRC32 checksums and MD5 values), and identification information (such as data batch number and write timestamp). This data must be stored in a secure local database or document beforehand to ensure quick retrieval during comparison. Reading data refers to the actual data read from the target memory address. All information acquired during the reading process must be completely preserved (including data content, accompanying verification results, and reading time) to avoid incomplete data truncation affecting comparison accuracy. Data retrieval and preprocessing involves retrieving the original data of the corresponding batch from storage locations (such as local databases or encrypted documents), confirming that the data identifier (such as batch number) matches the identifier of the read data to avoid cross-batch comparisons. Both the original and read data undergo unified preprocessing, including format standardization (such as converting text with different encoding formats to UTF-8 encoding and converting numerical values ​​to decimal) and redundant information removal (such as removing frame headers and footers added during data transmission) to ensure consistent comparison benchmarks.

[0089] Full comparison: Suitable for scenarios with small data volumes (e.g., ≤10KB). Use professional comparison tools (e.g., BeyondCompare, WinMerge, or the comparison function built into memory testing software) to compare the original data and read data byte by byte / character by character, recording the location of each inconsistency (e.g., "Byte 128: Original data is 0x5A, read data is 0x7B"). Checksum comparison: Suitable for scenarios with large data volumes (e.g., >10KB). First, calculate the checksums of the original data and read data separately (CRC32 or MD5 is recommended; if the memory system supports it, the hardware's built-in checksum module can be used to calculate it to improve efficiency). Then, directly compare whether the two checksums are completely identical. If the checksums are identical, it can be preliminarily determined that the data is consistent; if the checksums are inconsistent, further full comparison is needed to locate the differences.

[0090] If there is no difference in the comparison, record "Comparison Result: Consistent", and attach the comparison method (such as "Full Comparison" or "CRC32 Checksum Comparison"), comparison duration, and checksums of the original data and the read data (for easy traceability later). If there is a difference in the comparison, record "Comparison Result: Inconsistent" in detail, including the difference location (accurate to byte / character index), the corresponding content of the original data, the corresponding content of the read data, and the number of differences (such as "3 differences were found in total"). At the same time, save the log file of the comparison process (such as the comparison report generated by the tool) for easy analysis of the reasons for the differences later.

[0091] Step 202: Data read correctness determination (consistency scenario). The comparison operation in step 201 has been completed, and the comparison result shows that the read data is completely consistent with the original data (including the full content is consistent or the check code is consistent. If the check code is consistent, it is recommended to perform a second full verification on the key data segments to eliminate the risk of check code collision).

[0092] If a checksum comparison is used, 3-5 key data segments (such as the start segment, middle segment, and end segment, with each segment recommended to be ≥1024 bytes in length) should be randomly selected from the read data for a full comparison to confirm that there are no differences in the key areas; check whether the additional information of the read data (such as the read timestamp and address information) matches the associated information of the original data (such as the write timestamp and target address) to avoid "false consistency" caused by data misalignment (such as reading original data from other batches).

[0093] After secondary confirmation, the data read is marked as "correct data" in the memory testing system, and the judgment criteria are recorded (such as "no difference in full comparison, key segment secondary verification passed"). The memory address, reading time, comparison result, judgment conclusion, and other information corresponding to this read are synchronously written into the memory operation log and test report to form a complete judgment record chain, which is convenient for subsequent tracing of the stability of the memory area.

[0094] If the read is for routine data verification (not a troubleshooting scenario), the current memory refresh cycle remains unchanged, and subsequent aging tests or stability tests are continued. If the read is for verification after fault repair (e.g., if there were data errors before, and the read is retried after adjustment), the same address needs to be read and compared 3-5 times consecutively. Only after confirming that all data is correct can the memory region be considered to have recovered to stability.

[0095] Step 203: Determine the correctness of the read data and adjust the refresh cycle (inconsistency scenario). The comparison operation in step 201 has been completed, and the comparison result shows that the read data is inconsistent with the original data (non-memory hardware factors such as data retrieval errors and inconsistent formats have been ruled out).

[0096] The refresh cycle increment is a pre-set time increment used to gradually increase the refresh cycle. It needs to be set to a reasonable value based on the memory hardware specifications (e.g., 10ms, 20ms, 30ms for mainstream memory chips to avoid excessively large increments leading to over-adjustment, or excessively small increments prolonging adjustment time). The increment value must be within the refresh cycle range supported by the hardware (e.g., if the minimum refresh cycle is 32ms and the maximum is 256ms, then the increment adjustment must be performed within this range). The target refresh cycle is the refresh cycle found through multiple adjustments and verifications that ensures correct data reading. It must satisfy both "data correctness" and "reasonable cycle" (i.e., not exceeding the maximum supported cycle by the hardware, and avoiding abnormal memory power consumption or decreased data stability due to an excessively long cycle).

[0097] After confirming that the difference between the read data and the original data is caused by abnormal memory hardware response (not a tool connection problem or address error), the system marks the read data as "error data" and records the error type (such as "random bit flip" or "continuous byte error"). The system automatically triggers the "refresh cycle adjustment mechanism", retrieves the preset gradient time parameters, and enters the adjustment process.

[0098] Step-by-step adjustment and verification:

[0099] First adjustment: Read the current memory refresh cycle (denoted as T0), calculate the new refresh cycle (T1 = T0 + ΔT) according to the preset gradient time (denoted as ΔT), and confirm that T1 does not exceed the maximum hardware refresh cycle; write the new refresh cycle T1 through the memory control module, and after completion, wait for 1-2 complete T1 cycles as required in step 104 (to ensure that the parameters take effect); resend the data read instruction to the original target address to obtain the new read data, and compare it according to step 201 to determine whether they are consistent.

[0100] Subsequent adjustments (if inconsistencies persist): If the comparison remains inconsistent, repeat the above adjustment steps, calculating new cycles (T2=T1+ΔT, T3=T2+ΔT…). After each adjustment, wait 1-2 new cycles and reread the comparison. If, during the adjustment process, the new cycle is about to exceed the hardware's maximum refresh cycle, stop increasing the cycle at a fixed gradient and instead fine-tune it by 50% of the original gradient (e.g., change ΔT=20ms to 10ms) to avoid exceeding hardware limits and causing malfunctions. If the data remains inconsistent after 10 consecutive adjustments, pause the adjustment and use hardware diagnostic tools to check for physical damage to the memory chips (e.g., bad sector propagation). After ruling out hardware faults, continue adjusting.

[0101] After a certain adjustment, if the read data is consistent with the original data (a second confirmation is required according to step 202), then the refresh cycle of that adjustment (denoted as T target) is determined as the "target refresh cycle". After three consecutive data readings and comparisons using T target, and confirming that the correct data can be obtained each time, T target is officially locked. T target and related information (including the number of adjustments, the cycle value of each adjustment, the comparison results, and the three verification results before locking) are written into the memory parameter configuration document and reliability analysis report, and simultaneously synchronized to the aging test system. Subsequent aging tests must use T target as the benchmark refresh cycle.

[0102] During subsequent memory usage, monitor the correctness of data reading based on the T target in real time (it is recommended to automatically sample and compare once per hour); if data inconsistency occurs again during monitoring, the adjustment process in step 203 needs to be restarted, the target refresh cycle needs to be updated, and the cause of inconsistency needs to be analyzed (such as changes in ambient temperature, accelerated memory aging) to supplement data for reliability analysis.

[0103] Figure 3 yes Figure 1 The flowchart for step 3 is as follows: Figure 3 As shown, step 3 includes:

[0104] Step 301: Compare the read data bit by bit / byte by byte with the preset correct reference data;

[0105] Step 302: If the values ​​of all bits / bytes are completely consistent with the reference data, it means that the initial refresh cycle time meets the charge retention requirements of the damaged memory chip. The preset first time is determined as the target refresh cycle, and the entire debugging process ends. Subsequently, the memory chip is allowed to continue to work at the target refresh cycle.

[0106] Step 303: If any bit or byte value does not match the baseline data, it is determined that the current refresh cycle is too short and cannot guarantee the stability of the data of the damaged particles, and the refresh cycle gradient increase adjustment stage is entered.

[0107] Step 301: Perform a bit-by-bit / byte-by-byte comparison of the read data with the preset correct reference data. Through fine-grained bit-by-bit or byte-by-byte comparison, accurately verify the consistency between the read data and the reference data. This provides the most direct and accurate basis for subsequent judgment on whether the initial refresh cycle meets the charge retention requirements of the damaged memory chip, avoiding misjudgment due to insufficient comparison granularity.

[0108] For damaged memory chips, pre-set standard data that accurately reflects the normal state of the data must contain a complete bit or byte sequence (such as an 8-bit binary sequence "10101100" or byte data "0xAB"). After multiple rounds of verification and confirmation, the data must be stored in the dedicated benchmark database of the memory testing system to ensure the accuracy and uniqueness of the data during comparison.

[0109] Suitable for scenarios with extremely high data accuracy requirements (such as sensitive testing of memory chip charge retention capability), it compares the values ​​(0 or 1) of the corresponding bits of the read data with those of the reference data bit by bit, in units of binary bits, to see if they are consistent. Byte-by-byte comparison: Suitable for general data verification scenarios, it compares the values ​​(such as decimal or hexadecimal) of the corresponding bytes of the read data with those of the reference data, in units of byte (8 bits).

[0110] From the benchmark database of the memory testing system, retrieve the corresponding preset correct benchmark data according to the model, serial number and test scenario of the damaged memory chip being tested; verify whether the identification information of the benchmark data (such as chip model, data version, generation time) matches the information of the current test task to avoid retrieving incorrect benchmark data, and check the integrity of the benchmark data (such as data length, check code is normal). If there is data corruption or missing data, it is necessary to retrieve it again from the backup database.

[0111] Retrieve the data from the memory cache for this test, and confirm that the data read address and read time are consistent with the test conditions corresponding to the benchmark data (e.g., the same test address and the same test environment temperature for the same damaged particle). If the read data is in compressed or encrypted format, it needs to be decompressed or decrypted first to restore it to the original bit or byte sequence, ensuring that the format is consistent with the benchmark data and avoiding the impact of format differences on the comparison results.

[0112] Bit-by-bit comparison (high-precision scenario): Activate the bit-by-bit comparison function in the test system, converting the read data and the reference data into binary bit streams respectively (e.g., converting byte data "0xAB" to "10101011"); the system automatically compares the values ​​of corresponding positions in the two bit streams one by one, starting from the first bit, and records the comparison result (consistent / inconsistent) for each bit, for example, "3rd bit: read data is 1, reference data is 0, comparison result is inconsistent"; if the data length is long (e.g., more than 1024 bits), segmented comparison can be set (e.g., every 256 bits as a segment), and the results are displayed immediately after each segment comparison is completed, which facilitates timely detection of problems and avoids system lag due to excessive data volume in a single comparison.

[0113] Choose the comparison data format (decimal, hexadecimal, or binary), and it is recommended to match the annotation format of the reference data (e.g., if the reference data is annotated in hexadecimal, then the read data should also be converted to hexadecimal). Compare each byte of the read data with the reference data in sequence, and record the comparison result for each byte, for example, "Byte 5: Read data is 0xCD, reference data is 0xCE, the comparison result is inconsistent". If multiple consecutive bytes are found to be inconsistent during the comparison process, the comparison can be paused. First, check whether there is interference in the transmission link of the read data (such as poor contact, signal attenuation), and continue the comparison after eliminating external factors.

[0114] After the comparison is completed, the system automatically calculates the total number of compared bits / bytes, the number of consistent bits / bytes, the number of inconsistent bits / bytes, and the distribution of inconsistent locations (such as concentrated in the first half, second half, or randomly distributed in the data); generates a comparison report, which includes the comparison time, comparison granularity, baseline data information, read data information, detailed comparison result statistics, and details of inconsistent locations. The report is saved in PDF or Excel format to the test log folder and simultaneously uploaded to the cloud for backup, facilitating subsequent traceability and analysis.

[0115] Step 302: Initial refresh cycle determination and debugging process completed (full consistency scenario). The bit-by-bit / byte comparison in step 301 has been completed, and the comparison results show that the values ​​of all bits or bytes are completely consistent with the baseline data. At the same time, external interference factors such as data transmission errors and format conversion errors have been eliminated.

[0116] Retrieve the initial refresh cycle parameter for this test (i.e., the preset first time, denoted as T_initial), and confirm that the cycle parameter is within the effective range supported by the memory hardware (e.g., not lower than the minimum refresh cycle of the hardware, not higher than the maximum refresh cycle), and matches the specifications of the damaged memory chip in this test (e.g., the basic refresh cycle range recommended by the chip manual); combine with previous test records (e.g., the test results in steps 201-203) to confirm that the fully consistent comparison result is not accidental (e.g., the fully consistent result is obtained in 2-3 consecutive repeated tests), to avoid misjudgment due to accidental factors in a single test.

[0117] The preset initial time (T_initial) is officially determined as the target refresh cycle (denoted as T_target) for the damaged memory chip. In the parameter configuration interface of the memory test system, T_target is written into the dedicated configuration file of the chip, and the configuration status is marked as "effective". A configuration command is sent to the memory control module to set T_target as the default refresh cycle of the chip, ensuring that the cycle parameter is automatically loaded when the memory is working. After the configuration is completed, the T_target has been successfully written and effective through the system status query function (e.g., the control module reports "Refresh cycle configuration successful, current cycle is T_target").

[0118] Record "Debugging process completed" in the test log, detailing the end time, target refresh cycle, comparison result basis, and tester information. Simultaneously, disable the temporary data cache for the current test task to release system resources. Start the long-term monitoring program for the memory chips and set monitoring parameters (such as automatically reading data every 30 minutes and performing a simple bit comparison with the baseline data, and monitoring the chip's operating temperature and voltage in real time). If abnormal data is detected during monitoring, immediately trigger the alarm mechanism (such as pop-up prompts and email notifications). Synchronize the target refresh cycle, test report, and monitoring plan of the damaged chip to the memory management system to facilitate subsequent aging tests (such as conducting 1000 hours of uninterrupted aging tests according to the T target) and reliability analysis (such as statistically analyzing the stable operating time and failure rate of the chip under the T target).

[0119] Step 303: Refresh cycle determination and adjustment stage (inconsistency scenario) The bit-by-bit / byte comparison in step 301 has been completed, and there is a discrepancy between the value of any bit or byte and the baseline data. At the same time, it has been confirmed through investigation that the cause of the inconsistency is not an external factor (such as data transmission error or tool failure), but rather the insufficient charge retention capability of the memory chip itself.

[0120] This indicates that the current initial refresh cycle (preset first time) is insufficient to provide enough charge replenishment time for the damaged memory chip, causing the charge in the chip's storage unit to drain too quickly. This leads to problems such as data bit flipping and byte value errors, making it impossible to guarantee stable data storage. The refresh cycle gradient adjustment phase addresses the issue of the current cycle being too short by gradually increasing the refresh cycle according to a pre-set gradient time. Through multiple tests and verifications, the minimum effective cycle that can meet the charge retention requirements of the damaged chip is found. This phase must strictly follow the process of "gradient increase - verification - re-increment - re-verification" to avoid over- or under-adjustment of the cycle.

[0121] Analyze the inconsistent location distribution and error types (such as random bit flips, fixed byte errors) recorded in step 301. If the error type matches the characteristics of "data anomalies caused by charge loss" (such as irregular bit flips, and an increase in the number of errors as the test time increases), and external interference factors are excluded, then it is determined that the current initial refresh cycle is too short. Check the charge retention characteristic manual of the memory chip to confirm whether the same error behavior as this time will occur when the cycle is too short (such as the manual stating "random bit flips are likely to occur when the cycle is < 40ms"). Further verify the conclusion that the cycle is too short. If the manual does not have relevant markings, you can refer to the historical test data of the same type of damaged chips (such as the error behavior of too short cycle in historical data is consistent with this time).

[0122] Retrieve the system's preset refresh cycle gradient parameters and confirm the rationality of the gradient value (e.g., for the current particle model, the gradient value is set to 5ms, 10ms, or 15ms, which needs to be combined with the particle's charge retention sensitivity setting; higher sensitivity results in a smaller gradient value, avoiding excessive adjustment at once); clear previous temporary test data (e.g., error records from the last comparison, data read cache), reset the test system's state (e.g., restore the default parameters of the comparison tool, calibrate data read accuracy), and check whether the test environment (e.g., temperature, humidity, voltage) is stable. If the environment fluctuates significantly (e.g., temperature changes exceed ±5℃), wait for the environment to stabilize before entering the adjustment phase; formulate a test plan for the adjustment phase, specifying the cycle value for each adjustment, the number of verifications (e.g., perform two data reads and comparisons after each adjustment), and the stopping conditions (e.g., find an effective cycle or reach the maximum cycle limit), to avoid disordered testing.

[0123] In the test system, create a "gradient increment adjustment task" and input parameters such as the initial refresh cycle (T_initial), gradient value (ΔT), and maximum cycle limit (T_maximum, taken from the hardware specification). The system automatically generates the target cycle after the first adjustment (T1 = T_initial + ΔT). Send a cycle adjustment command to the memory control module to update the current cycle to T1. After the adjustment is completed, wait for 1-2 complete T1 cycles as required in step 104 (to ensure that the cycle parameters are fully effective and to avoid distortion of verification results due to unstable parameters). After the wait is over, re-execute the bit-by-bit / byte-by-byte comparison operation in step 301. Determine the next action based on the comparison results: if all comparisons are consistent, determine the target cycle and end the debugging process according to the process in step 302; if there are still inconsistencies, continue to calculate the next adjustment cycle (T2 = T1 + ΔT), and repeat the above adjustment-wait-comparison process until a valid cycle is found or T_maximum is reached (if T_maximum is reached...). If the maximum value is still inconsistent, it needs to be determined that the particle is severely damaged and cannot be repaired by periodic adjustment; it is recommended to replace the particle. After each adjustment and verification, record the adjusted period value, comparison results (number of consistent bits / bytes, inconsistent positions), waiting time and environmental parameters in detail to form a test log for the adjustment phase. This will provide data support for subsequent analysis of particle characteristics (such as the change law of charge retention capacity with the period).

[0124] Figure 4 yes Figure 1 The flowchart for step 4 is as follows: Figure 4 As shown, step 4 includes:

[0125] Step 401: Based on the preset first time, a new refresh cycle is calculated by superimposing a preset gradient time to obtain the preset second time;

[0126] Step 402: Update the refresh cycle of the memory chips to the preset second time, and wait for 1 or 2 cycles to ensure that the hardware can stably receive the new parameters.

[0127] Step 403: Repeat the operation of "using the preset first time as the initial refresh cycle time, so that the memory chip reads data at the initial refresh cycle time", and then compare the reading result with the correct data benchmark.

[0128] Step 404: If the data is read correctly: This indicates that the preset second time is adapted to the working requirements of the damaged particle. The preset second time is set as the target refresh cycle, and the debugging process is terminated.

[0129] Step 405: If the data is still read incorrectly, it means that the current period is still insufficient and the gradient time needs to be added again.

[0130] Step 401: Calculation of the new refresh cycle (preset second time): Based on the preset first time and preset gradient time, the new refresh cycle (preset second time) is accurately calculated to provide clear parameter basis for subsequent memory particle refresh cycle updates, ensuring that the cycle adjustment conforms to the core logic of "gradient increment" and avoiding hardware adaptation anomalies caused by parameter jumps.

[0131] The initial refresh cycle currently being used by the memory chips (as mentioned in steps 302 / 303, T_initial) must be a valid cycle value that has passed hardware compatibility verification (not exceeding the hardware minimum / maximum refresh cycle range). Preset gradient time: This refers to the fixed time increment (denoted as ΔT) pre-set by the system for each increment of the refresh cycle. It needs to be set according to the characteristics of the memory chip model (e.g., DDR4 chips commonly use a 10ms / 20ms gradient, while DDR5 chips can be set to 5ms / 15ms; refer to the hardware specifications for details), and must meet the premise that "after a single increment, it is still within the hardware's valid cycle range." Preset second time: This refers to the new refresh cycle (denoted as T2) calculated by "preset first time + preset gradient time," which is the target parameter for this cycle update.

[0132] From the parameter configuration library of the memory testing system, retrieve the "preset first time" (T1) of the current memory chip and the "preset gradient time" (ΔT) of the system-wide memory. At the same time, retrieve the hardware cycle limit parameters (T minimum, T maximum, taken from the chip datasheet) of the chip. Verify the validity of the basic parameters: confirm that T1 is within the range of [T minimum, T maximum]. If T1 < T minimum or T1 > T maximum, the calculation needs to be paused, and the initial cycle parameters need to be reconfirmed in step 303 to eliminate previous configuration errors. Confirm that ΔT is a positive number and conforms to the characteristics of the chip (e.g., if the chip manual states "the maximum increment of a single cycle adjustment does not exceed 30ms", then ΔT must be ≤30ms). If ΔT does not meet the requirements, the "specific gradient value" (not the global gradient value) corresponding to the chip needs to be retrieved from the system parameter library to ensure the rationality of the gradient.

[0133] The calculation is performed according to the formula "Preset Second Time (T2) = Preset First Time (T1) + Preset Gradient Time (ΔT)". For example, if T1 = 60ms and ΔT = 10ms, then T2 = 70ms. Verify whether T2 is within the effective hardware cycle range: If T2 ≤ Tmax: T2 is determined to be a valid new cycle, and the calculation process (T1, ΔT, T2 values ​​and calculation time) is recorded, and the subsequent steps are entered; If T2 > Tmax: the current calculation needs to be terminated, and the "gradient adjustment warning" is triggered - ΔT is adjusted to "Tmax - T1" (ensuring that T2 = Tmax). If ΔT < 0 after adjustment (meaning that T1 is equal to Tmax), then it is directly determined that the current particle cannot be repaired by cycle adjustment (it is necessary to jump to the "particle replacement process") to avoid invalid calculation.

[0134] Write the calculated T2 (preset second time) and related verification records (parameter validity verification results, range verification results) into the test log, and mark the "calculation status" of T2 as "to be applied"; simultaneously push the T2 parameters to the "parameter cache to be updated" of the memory control module to prepare for the periodic update in step 402, and ensure that there is no loss or tampering during parameter transmission (parameter integrity can be verified by CRC check code).

[0135] Step 402: Refresh cycle update and hardware stabilization waiting. The T2 calculation in step 401 has been completed, and T2 is a valid cycle value (within the range of [T minimum, T maximum]). At the same time, the memory control module has successfully received the T2 parameter and stored it in the cache area to be updated.

[0136] In the memory testing system's interface, select the "Refresh Periodic Update" function, confirm that the parameter to be updated is T2 (preset second time), and check the "Automatic Verification After Update" option; click "Send Update Command" to send the periodic update command to the memory control module. The command must include the unique identifier of the chip (such as serial number), the T2 parameter, and the update timestamp to ensure that the control module accurately locates the target chip; receive feedback information from the control module: if the feedback is "Command received successfully, pending update execution," then enter the waiting stage; if the feedback is "Command received failed" (such as chip connection interruption, parameter format error), check the chip's physical connection status and the T2 parameter format (such as whether it is an integer, whether the unit is correct), repair, and resend the command.

[0137] Start the system timer and wait for 1-2 complete T2 cycles (waiting time = T2 × 1 or T2 × 2, it is recommended to choose 2 cycles to ensure that the parameters are fully effective). For example, if T2 = 70ms, then wait for 140ms. During the waiting period, check the "cycle configuration status" of the chip in real time through the hardware status monitoring tool: if the status shows "updating": continue monitoring until the status changes to "updating complete"; if the status remains at "updating" for a long time (more than 1.5 times the waiting time): it is determined to be "updating timeout", and the memory control module needs to be restarted to re-execute the cycle update operation to avoid hardware freezing; after the waiting period ends, check the actual refresh cycle of the current chip through the control module to confirm whether it is consistent with T2: if it is consistent, the cycle update is successful; if it is inconsistent, the update command needs to be resent and the waiting time extended (e.g., wait for 2.5 T2 cycles) until the actual cycle matches T2.

[0138] Record the update completion time, actual waiting time, cycle parameters before and after the update (T1→T2), and feedback information from the control module. If there are update retries, record the number of retries and the reason for each retrieval (such as instruction failure or timeout). Synchronize the update results to the test log and mark the "calculation status" of T2 from "pending application" to "application" to provide a status basis for subsequent data verification.

[0139] Step 403: Repeat the data reading and benchmark comparison operation. Under the updated T2 cycle, reread the data at the specified address and compare it with the correct benchmark data to verify whether the T2 cycle can solve the previous data reading error problem, providing core data support for the validity determination of T2. The cycle update in step 402 has been completed, and the current actual refresh cycle of the particle is T2. The hardware status shows "stable" (no errors, no abnormal fluctuations).

[0140] Confirm the reading address: It must be completely consistent with the "specified test address" used in step 301 (such as the physical address "0x20000000-0x20000FFF") to avoid inconsistencies in the comparison benchmark due to address changes; Prepare the reading tool: Use the same professional data reading tool as in step 301 (ensure that the tool parameters have not changed, such as reading rate and data format). If the tool needs to be reconnected, a connection stability test must be performed first (e.g., send 3 test commands and ensure that they can respond normally).

[0141] Send a "data read command at specified address" to the target chip. The command must include the address range, the number of reads (it is recommended to read twice consecutively and take the intersection of the two read results to reduce random errors), and the data storage path. During the read process, monitor the tool log in real time: if it shows "read successful": obtain the data from the two reads and name them "read data A" and "read data B" respectively, and proceed to the subsequent comparison stage; if it shows "read failed" (such as address inaccessible, data transmission interrupted): first check the chip power supply voltage (whether it is within the standard range, such as the standard voltage of DDR4 chip 1.2V±5%) and physical connection. After ruling out hardware failures, reread. If three consecutive reads fail, it is determined that "the hardware cannot respond normally under the T2 cycle", and it is necessary to backtrack to step 401 to readjust ΔT (such as reducing the gradient value).

[0142] Retrieve the same "correct baseline data" as in step 301, ensuring that the baseline data identifier (such as version and generation time) remains unchanged; perform bit-by-bit / byte-by-byte comparisons between "Read Data A" and "Read Data B" and the baseline data respectively (the comparison granularity is consistent with step 301; if step 301 uses bit-by-bit comparison, this step will also use bit-by-bit comparison): If the comparison results of the two read data and the baseline data are completely consistent (without any bit or byte difference): it is determined that "data read is correct", and proceed to step 404; If any read data differs from the baseline data: it is necessary to first confirm whether the two read data are consistent— If the two read data are consistent but inconsistent with the baseline data, it is determined that "data read is incorrect", and proceed to step 405; If the two read data themselves are inconsistent (such as the 10th bit of read data A being 1 and the 10th bit of read data B being 0), it is determined that "reading is unstable", and the number of reads needs to be increased (such as reading 3 more times), and the result of the majority consistency is taken as the final read data, and it is re-compared with the baseline data.

[0143] Record the reading time, number of reads, completeness of data read each time (whether all data within the address range was obtained), and comparison results (number of consistent bits or bytes, and inconsistent positions); generate a "T2 cycle data verification report", attach the original files of the two data reads and comparison details, and save it to the test log folder.

[0144] Step 404: T2 cycle validity determination and debugging process termination (data correct scenario). The comparison in step 403 has been completed, and the results show that the read data is completely consistent with the correct benchmark data (both read results are consistent, with no difference). At the same time, external factors such as data transmission and tool errors have been ruled out.

[0145] Based on the reading results of step 403, analyze the data stability under cycle T2: if there is no difference between two consecutive readings, and the reading process has no timeout or error, it indicates that T2 can meet the charge retention requirements of the damaged particle and is compatible with its working characteristics; supplementary verification: under cycle T2, perform one data reading and comparison on other test addresses of the particle (such as "0x20001000-0x20001FFF"). If the results are still correct, further confirm the global compatibility of T2 (avoid the accidental situation of only specific address compatibility).

[0146] T2 (preset second time) is officially determined as the "target refresh cycle" for the damaged chip. In the "cycle configuration library" of the memory testing system, the "target cycle" field of the chip is updated to T2, and the "configuration status" is marked as "finally effective". A "cycle solidification instruction" is sent to the memory control module to set T2 as the "permanent default cycle" (instead of a temporary cycle) of the chip, ensuring that T2 is still the default refresh cycle after the chip is restarted or powered off. After solidification, the "default cycle" parameter is queried through the control module to confirm that it has been updated to T2.

[0147] Record "Debugging process terminated" in the test log, detailing the termination time, target refresh cycle (T2), key verification node results (such as T2 calculation process, update results, and 3 data reading comparison results), and tester information; archive all test documents, including cycle calculation records, update logs, data comparison reports, hardware status monitoring screenshots, etc., organized according to the naming rule of "particle serial number-debugging date", and upload them to the cloud database for subsequent product traceability (such as aging tests and fault analysis); close the temporary processes of the current test task (such as data reading tools and status monitoring tools) to release system resources and prepare for the debugging task of the next particle.

[0148] Step 405: Insufficient cycle determination and continued increment operation (data error scenario). The comparison in step 403 has been completed, and the result shows that there is a difference between the read data and the correct baseline data (after excluding external interference factors, it is confirmed that the difference is caused by insufficient cycle), and T2 < T maximum (there is still room for increment).

[0149] Analyze the comparison results of step 403: If the difference type is "random bit flip" or "data loss" (consistent with the error characteristics caused by charge loss), and the following external factors are excluded, then it is determined that "the current cycle (T2) is still insufficient": Hardware connection problems (such as loose chip slots or damaged signal lines): Verify by re-inserting the chips and replacing the signal lines; Test environment fluctuations (such as temperature rise > 5℃ or voltage fluctuation > ±5%): Check the environmental monitoring log. If there are fluctuations, re-execute step 403 after the environment stabilizes; Tool errors (such as insufficient reading tool accuracy): Re-read and compare using a backup reading tool. If the results are consistent, exclude tool errors; If the difference type is "fixed bit error" or "address unreadable" (possibly caused by physical damage to the chips), the cycle increment needs to be paused, and the "chip damage detection process" needs to be started (such as using professional hardware testing equipment to scan for bad sectors in the chips). After excluding physical damage, continue.

[0150] Update the "current period" to T2 (i.e., the "preset first time" for the next calculation), and record the "period increment record" (period T1 before this increment, period T2 after the increment, and error data characteristics) in the test log; confirm the "preset gradient time" (ΔT) for the next increment: if the number of error bits / bytes decreases by ≥30% after the increment of T2 and T1, the original ΔT can be maintained; if the error reduction ratio is <30%, ΔT needs to be adjusted to 1.5 times the original gradient (e.g., if the original ΔT=10ms, adjust it to 15ms) to speed up the adaptation efficiency, but it is necessary to ensure that the adjusted ΔT still satisfies "T2 + new ΔT ≤ T maximum"; synchronize the updated "preset first time" (T2) and "preset gradient time" (new ΔT) to the system parameter configuration library to prepare for the next period calculation (step 401).

[0151] Automatically trigger process loop: Restart from step 401, calculate the next new cycle (T3=T2+NewΔT) based on the new "preset first time" (T2) and "preset gradient time" (new ΔT), and repeat the "calculate-update-read-compare" process; Set loop termination conditions: Normal termination: The comparison result shows that the data is correct (trigger step 404); Abnormal termination: When the calculated new cycle is ≥ T maximum, and the data is still incorrect, it is determined that "particles cannot be repaired by cycle adjustment", a "particle replacement suggestion report" is generated, the loop process is terminated, and the operation and maintenance personnel are notified to replace the particles; or if the number of loops reaches the preset upper limit (such as 10 times) and no effective cycle is found, the loop is also terminated and anomaly analysis is started.

[0152] After each cycle, the "number of cycles incremented", "current cycle value", "error data details" and "environmental parameters" are recorded to form a "cycle adjustment trend table". The table visually displays the change in error rate as the cycle increases (e.g., the cycle changes from 60ms to 70ms to 80ms, and the number of error bytes changes from 12 to 5 to 0), providing a reference for the cycle adjustment of similar particles in the future.

[0153] After step 4, the method further includes:

[0154] Step 406: If the reading result corresponding to the preset second time is still incorrect, proceed to the continuous iterative adjustment stage;

[0155] Step 407: Based on the current error cycle (such as the preset second time), the preset gradient time is superimposed again to generate a new refresh cycle value;

[0156] Step 408: After each new cycle is generated, the process of "configuring cycle - reading data - verification and comparison" is executed.

[0157] Step 409: Continue the process until the read data is completely consistent with the correct baseline data. The corresponding refresh cycle time at this point is the final target refresh cycle.

[0158] Step 406: Triggering the continuous iterative adjustment phase (preset second time reading error scenario). When the reading result corresponding to the preset second time (T2) is still incorrect, the continuous iterative adjustment mechanism is started. The refresh cycle is optimized through multiple loops to ensure that an effective cycle that adapts to the damaged particles is finally found, and to avoid debugging interruption due to insufficient adjustment in a single time.

[0159] The insufficient cycle determination in step 405 has been completed. It is confirmed that the data read at the preset second time (T2) is incorrect and the following conditions are met: physical damage to the particles (such as bad sectors or short circuits), hardware connection failures (such as loose slots), and external factors such as test environment fluctuations (temperature > 23℃ ± 5%, voltage fluctuation > ± 5%) are excluded; the current T2 < the maximum hardware refresh cycle (T maximum), and the number of cycle adjustments has not reached the preset upper limit (such as 15 times, which can be customized according to the particle model).

[0160] In the memory testing system's interface, a "Continuous Iterative Adjustment Start Prompt" pops up, displaying the current error information (e.g., "When T2=70ms, there are 5 inconsistent bytes in the read data"), the remaining adjustment counts (e.g., "14 counts remaining"), and the maximum T limit (e.g., "Maximum T = 200ms"). The operator then confirms whether to start the iteration. After confirmation, the system automatically creates an "Iterative Adjustment Task File," recording the task start time, initial error cycle (T2), objective (the cycle in which the correct data is found), and iteration rules (e.g., gradient adjustment logic, process execution order). At the same time, it locks the testing permissions of the current particle to prevent interference from other tasks.

[0161] Set the "Current Baseline Period" to T2 (i.e., the basis for the next period generation), and use the adjusted ΔT (e.g., 15ms) from step 405. If ΔT is not adjusted in step 405, the initial ΔT (e.g., 10ms) will be used by default. In the iteration task file, add an "Iteration Record Table". The table header includes "Iteration Count", "Current Baseline Period (ms)", "Current Gradient (ms)", "New Generation Period (ms)", "Configuration Result", "Read Result", "Comparison Result", "Error Details", and "Environment Parameters" to record data for each subsequent iteration.

[0162] The system automatically triggers the new cycle generation process in step 407 and starts iteration progress monitoring (e.g., displaying "Iteration 1 / 15, generating a new cycle..." on the interface). If an unexpected situation occurs during the iteration process (e.g., system power failure, tool crash), the previous iteration state can be restored through "Iteration Adjustment Task File" after restarting, and execution can continue from the interrupted steps to avoid data loss.

[0163] Step 407: Generation of a new refresh cycle (based on the superimposed gradient of the error cycle). Based on the current error cycle, a new refresh cycle is generated by superimposing a preset gradient time. This provides parameters for the subsequent "configuration-reading-verification" process, ensuring that the cycle adjustment always follows the principle of "gradient increment, controllable and traceable".

[0164] The refresh period that causes data reading errors in the current iteration (such as T2=70ms, T3=85ms, etc.) is the basis for generating the new period; the new refresh period is the period value (denoted as Tn, n≥3) calculated by "error period + current gradient time". It is necessary to ensure that Tn≤T is the maximum, otherwise the gradient needs to be adjusted.

[0165] Retrieve the "current baseline period" (i.e., the error period, denoted as Tn-1), "current gradient time" (ΔT current), and T maximum from the "iterative adjustment task file"; verify parameter validity: confirm that Tn-1 is within the range of [T minimum, T maximum) (if Tn-1 = T maximum, directly trigger "iteration termination, recommend changing particles"); confirm that ΔT current is positive and meets the condition "Tn-1 + ΔT current ≤ T maximum", if not, adjust ΔT current to "T maximum - Tn-1" (ensure Tn = T maximum), if ΔT current < 0 after adjustment, it is determined as "no incremental space", and the iteration is terminated.

[0166] Calculate using the formula "New refresh period (Tn) = Current baseline period (Tn-1) + Current gradient time (ΔT current)". For example, if Tn-1 = 70ms and ΔT current = 15ms, then Tn = 85ms. Verify the validity of Tn: If Tn ≤ T maximum and Tn ≥ T minimum: it is determined to be a valid new period. Fill in the "iteration number" (e.g., 1), "current baseline period" (70ms), "current gradient" (15ms), and "new generation period" (85ms) in the "iteration record table". If Tn > T maximum: force Tn to be set to T maximum, and at the same time, note in the table "gradient adjustment: because Tn exceeds T maximum, force it to be set to T maximum = 200ms" to avoid generating invalid periods.

[0167] Pre-check whether the new cycle Tn is the same as the historical iteration cycle (e.g., 85ms has been generated before and read incorrectly): If it is the same, it means that the current gradient may be too large. ΔT needs to be halved (e.g., 15ms → 7.5ms), and Tn needs to be recalculated (e.g., 70ms + 7.5ms = 77.5ms) to avoid invalid iterations. After the check passes, Tn is stored in the "Pending Configuration Cycle Buffer" and the status of Tn is marked as "Pending Configuration" in the iteration task file. A CRC checksum is also generated (used to verify parameter integrity during configuration).

[0168] Step 408: The "Configure Cycle - Read Data - Verify and Compare" process is executed to perform a full-process verification of the new cycle (Tn) generated in Step 407. Through the three core steps of configuration, reading, and comparison, it is determined whether Tn can solve the data error problem, providing a basis for iterative adjustments.

[0169] Configuration command sending: Retrieve Tn from the "Pending Configuration Cycle Buffer" and send the "Iteration Cycle Configuration Command" to the memory control module. In addition to Tn, particle serial number, and timestamp, the command includes an "Iteration Identifier" (e.g., "Iteration 1 - Tn = 85ms") to help the control module distinguish between regular configuration and iterative configuration. Configuration status monitoring: Wait for 1-2 complete Tn cycles (preferably 2 cycles, e.g., wait 170ms if Tn = 85ms). During this period, check the "Iteration Configuration Status" using the hardware status tool: If "Configuration Successful" is displayed: Query the current cycle of the control module to confirm it matches Tn, and proceed to the data reading stage; If "Configuration Failed" is displayed (e.g., parameter verification error, module unresponsive): Regenerate the CRC checksum of Tn, confirm the parameters have not been tampered with, and resend the configuration command. If it fails 3 times consecutively, it is determined to be a "Hardware Configuration Abnormality," the iteration is paused, and the control module is investigated for faults. Configuration result recording: In the "Configuration Result" column of the "Iteration Record Table", fill in "Success / Failure" and the configuration time (e.g., "Success, time taken 170ms"). If it fails, record the reason (e.g., "Parameter verification error, successful after resending").

[0170] Read Address Selection: In addition to the fixed "baseline test address" (e.g., 0x20000000-0x20000FFF) in step 301, an additional "random test address" (e.g., 0x30005000-0x30005FFF, randomly generated by the system to ensure coverage of different areas of the granular material) is added to avoid the limitations of verifying only a single address; Read Execution: Read the two addresses three times consecutively to obtain the "baseline address read data group (A1, A2, A3)" and the "random address read data group (B1, B2, B3)". During the reading process, the data integrity is monitored in real time (e.g., whether there is data truncation or garbled characters); Read Result Filtering: Take the "majority consistent result" for each group of data (e.g., A1 and A2 are consistent, A3 is consistent). If they are different, then A1 / A2 is used as the base address for valid data; if all three sets are different, it is determined as "unstable reading" and the power supply of the chip needs to be checked and the reading is repeated. Reading record: In the "Reading Result" column of the "Iteration Record Table", fill in "Success / Failure", the number of valid data sets (such as "Success, base address valid data A1 / A2, random address valid data B1 / B3") and the reading time.

[0171] Baseline data retrieval: Retrieve the preset correct baseline data corresponding to the "baseline test address" and "random test address" respectively (ensure that they correspond one-to-one with the address, such as baseline address corresponding to baseline data 1 and random address corresponding to baseline data 2).

[0172] Perform bit-by-bit / byte-by-byte comparisons between the valid read data and the corresponding baseline data (the comparison granularity is consistent with step 301, such as bit-by-bit comparison); calculate the "consistency rate": the formula is "(number of consistent bits or bytes ÷ total number of bits or bytes) × 100%", for example, if the total number of bytes at the baseline address is 1024 and the number of consistent bytes is 980, then the consistency rate is ≈ 95.7%;

[0173] If the consistency rate of both addresses is 100% (no difference): it is judged as "comparison passed, data is correct", proceed to step 409; if the consistency rate of either address is <100%: it is judged as "comparison failed, data is incorrect", record the error location (e.g., "the 512th byte of the base address is inconsistent, the 300th bit of the random address is inconsistent") and the consistency rate, return to step 407 to regenerate a new cycle; comparison record: fill in "pass / fail", the consistency rate of the two addresses, and error details in the "comparison result" column of the "iteration record table" (if it fails, a screenshot of the inconsistent location is required), and upload the comparison report to the iteration task file.

[0174] Step 409: Determining the target refresh cycle (data correct scenario). When a cycle with completely correct data occurs during iterative adjustment, its stability is confirmed through multiple rounds of verification. Finally, this cycle is determined as the target refresh cycle, the iteration process is terminated, and a basis is provided for the stable operation of subsequent granules.

[0175] The “configuration-reading-verification” process in step 408 has been completed, and the read data from both test addresses (base address + random address) is 100% consistent with the base data. At the same time, the following conditions are met: the current period Tn < T maximum (to avoid “false correctness” caused by reaching the upper limit); the test environment is stable (temperature 23℃±2%, voltage fluctuation ≤±3%), and there is no external interference.

[0176] Multiple rounds of repeated verification: Using the current Tn as the cycle, repeat the "configuration-read-verification" process of step 408 3 times, with a 5-minute interval between each verification (simulating the time interval in actual use) to ensure stability at different time points; Extreme environment verification (optional, for high reliability requirements): Temperature test: Adjust the ambient temperature to the upper limit of the chip's operating temperature (e.g., 85℃), maintain it for 30 minutes, and then execute "configuration-read-verification" once; Voltage test: Adjust the power supply voltage to the lower limit of the standard voltage (e.g., DDR4 chip 1.2V-5%=1.14V), maintain it for 30 minutes, and then execute "configuration-read-verification" once; Verification result judgment: If the consistency rate of the 3 regular verifications + extreme environment verification (if executed) is 100%, Tn is judged to be stable; If any verification fails, it is necessary to return to step 407 and iterate again (possibly due to marginal stability of the cycle).

[0177] Tn is officially defined as the "final target refresh cycle". In the iteration task file, the "task status: completed" is marked, and the target cycle value, the number of iterations achieved (e.g., "3 iterations, target cycle Tn=100ms"), and the total time (e.g., "1 hour 20 minutes") are filled in. The "target cycle fixation instruction" is sent to the memory control module. In addition to writing Tn, an "lock flag" is added to prevent unauthorized modifications (e.g., cycle changes caused by accidental operation). After fixation, the "lock status" is queried through the control module to confirm that it is "locked". The "target cycle flag" (e.g., "Tn=100ms, configured on 2025-11-21") is pasted on the physical label of the memory chip for easy viewing by on-site maintenance personnel.

[0178] The system displays a "Iteration Adjustment Complete" message, showing the target cycle, verification results, and subsequent suggestions (such as "It is recommended to conduct stability retesting once every 3 months"). All iteration-related documents are archived, including iteration task files (including iteration record tables), logs for each configuration, read data files, comparison reports, and stability verification reports. These are stored on the local server and backed up in the cloud according to the naming convention of "particle serial number - iteration completion date - target cycle" (such as "SN20251101-20251121-T100ms"). Particle testing permissions are released, iteration adjustment-related processes (such as progress monitoring and task locking) are closed, and the debugging task for the next particle can be started, or the particle can enter the aging test phase (based on the target cycle).

[0179] Based on the iterative process data, a "Particle Operation and Maintenance Report" is generated, which includes: cycle adjustment trends (e.g., from T1=60ms→T2=70ms→T3=85ms→Tn=100ms, error rate from 12%→5%→2%→0%); sensitive factors (e.g., when the temperature exceeds 60℃, the target cycle needs to be shortened by 5% to avoid data errors); retesting plan (e.g., performing "configuration-read-verification" once every 3 months to confirm the validity of the cycle); the report is sent to the operation and maintenance team to provide a reference for long-term maintenance and ensure that the particles run stably throughout their entire lifecycle.

[0180] After step 4, the method further includes:

[0181] Step 4010: Introduce the write mode and read back the known mode test refresh cycle time to compare whether the results of the two modes are consistent;

[0182] Step 4011: If all modes can be correctly read back under the target refresh time, then the target refresh time is considered valid.

[0183] Step 4012: If all modes cannot correctly read back at the target refresh time, then the target refresh time is considered invalid.

[0184] Step 4010: Introduce write mode and readback test operations. By introducing multiple preset write modes and performing readback tests, verify the stability of the target refresh cycle (Tn) from the entire "data write-storage-readback" link, avoid the limitations of verification under a single data mode, and further confirm the cycle's adaptability to different data types.

[0185] This refers to a pre-designed combination of test data with different data characteristics, which needs to cover common storage scenarios of memory chips (such as consecutive identical values, random values, and alternating bit sequences). Each mode must include a clear identifier (such as "Mode 1 - consecutive 0xAA" and "Mode 2 - random 16-bit sequence") to facilitate identification and comparison after readback. Readback test: Under the target refresh cycle (Tn), after writing the write mode data to the specified area of ​​memory, wait for 1-2 Tn cycles, and then read the data from the same area (i.e., "readback"). By comparing the readback data with the original write mode, the cycle's ability to guarantee data storage is verified.

[0186] Design 3-5 differentiated write modes (covering different data characteristics to avoid biased verification due to mode repetition). The recommended mode combinations are as follows:

[0187]

[0188] All write pattern data are stored in the "pattern database". Each pattern is accompanied by an MD5 checksum (used for data integrity verification during readback). At the same time, the "write address range" of each pattern is recorded (which must not overlap with the test address in step 408, such as 0x40000000-0x400003FF, to avoid data overwriting).

[0189] Address cleanup: Before writing, perform a "data zeroing" operation (write 0x00) on the target address range corresponding to each mode to avoid historical data residue affecting the test results. After cleanup, confirm that there is no residual data in the address area by reading.

[0190] Retrieve mode 1 data and its corresponding write address (e.g., 0x40000000-0x400003FF) from the "mode database" and send a "mode write command" to the memory chip. The command includes the mode identifier, write address, data length, and current target cycle (Tn). After writing is completed, check the "write status" through the memory control module. If it shows "write successful", if it shows "write failed" (e.g., address cannot be written, data transmission interrupted), check the physical status of the chip (e.g., whether there are hidden bad sectors), repair it, and rewrite. Complete the writing of all modes in sequence according to the above process. After completing each mode, record the "write time", "mode identifier", and "target address" to the "mode test log".

[0191] Waiting for the cycle to take effect: After all modes are written, wait for 1-2 complete target refresh cycles (Tn). For example, if Tn=100ms, wait for 200ms to ensure that the cycle parameter takes effect on the storage of the written data. Mode-by-mode readback: For the write address of mode 1, send a "mode readback command" to read all data within the address range and save it as "readback data 1". At the same time, record the "readback time" and "data length". Repeat the above operation to complete the readback of all modes and obtain "readback data 2 - readback data N" (N is the total number of modes). Preliminary integrity verification: Calculate the MD5 checksum of each readback data and compare it with the checksum of the corresponding mode in the "mode database". If the checksums do not match, the readback of that mode is directly determined to be a failure. If the checksums match, proceed to the next step "detailed comparison".

[0192] The "byte-by-byte comparison" method is adopted (because the pattern data structure is clear, byte-by-byte comparison can accurately locate differences). The "readback data 1" and "original data of pattern 1" are compared byte by byte, and the "number of consistent bytes", "number of inconsistent bytes", and "inconsistency position" are recorded. The comparison of all patterns is completed in the same way. If there is an inconsistency in a certain pattern, factors such as "address confusion" (such as mismatch between readback address and write address) and "data tampering" (such as external interference causing data change after writing) need to be ruled out. The "write-readback-comparison" process of that pattern is re-executed to confirm whether it is an occasional error.

[0193] Here, "two modes" refers to the "baseline / random address read mode in step 408" and the "multi-mode write-back read mode in this step." The results need to be compared from the following dimensions: Correctness dimension: If the read data of both addresses in step 408 is correct (100% consistency rate), and the M modes in this step are read back correctly (M is the total number of modes), then the results of the two modes are initially determined to be "consistent"; if step 408 is correct but there is a mode readback error in this step, or vice versa, then the results are determined to be "inconsistent"; Stability dimension: Statistically analyze the "types of data errors" (such as random bit flips, fixed byte errors) in the two modes. If the error types are consistent (both are random bit flips), it indicates that the problem may be caused by insufficient cycle time; if the error types are inconsistent (e.g., fixed errors in step 408, random errors in this step), it is necessary to check whether there are hardware compatibility issues (such as the chip's adaptation defects to specific data modes); Record the comparison results (consistent / inconsistent, details of differences) in the "mode test log" to provide a basis for the validity determination of steps 4011 / 4012.

[0194] Step 4011: Target refresh cycle validity determination (full mode correct readback scenario). The test in Step 4010 has been completed and the following conditions are met: The read data of "base address + random address" in Step 408 has a consistency rate of 100% with the base data; The readback data of all write modes in Step 4010 is correct after "MD5 check + byte-by-byte comparison" (no inconsistency); The comparison of the results of the two modes shows "consistent correctness" (both are correct) and there is no difference in abnormal error type.

[0195] Based on the result that "both modes are verified correctly", the target refresh cycle (Tn) is initially determined to be "temporarily valid". In the "Mode Test Log", "Preliminary determination result: temporarily valid" is marked, and the basis for the determination is recorded (such as "step 408 dual address is correct, and the four modes readback in step 4010 are correct"). Supplement "cycle redundancy verification" (optional, for high reliability scenarios): reduce the target cycle (Tn) by 5%-10% (such as Tn=100ms, reduce to 90ms), and repeat the "write-readback-compare" of 1-2 core modes (such as mode 1 and mode 3) in step 4010. If it can still be read back correctly, it means that the cycle has a certain degree of redundancy, which further supports the validity.

[0196] The testing team reviews the "Step 408 Test Report," "Step 4010 Mode Test Log," and "Periodic Redundancy Verification Report" (if any) to confirm that all verification steps are complete and there is no abnormal data. They unanimously agree to determine that the target cycle is valid. In the "Iterative Adjustment Task File," officially mark "Target Refresh Cycle (Tn) Validity: Valid," and fill in the "Validity Judgment Time," "Reviewers," and "Core Verification Basis" (such as "All 4 write modes readbacks are correct, and dual address reads are correct"). The "Validity Judgment Result" is synchronized to the memory management system, and the "Cycle Status" of the particle is updated to "Valid Target Cycle" to facilitate the use of this cycle parameter during subsequent aging tests and operation and maintenance management.

[0197] Initiate the "Target Cycle Solidification and Strengthening" operation: In addition to adding the "Lock Flag" in step 409, write the target cycle (Tn) into the "Security Configuration Area" of the memory control module to prevent the cycle parameter from being lost due to module firmware updates; Develop a "Long-Term Stability Monitoring Plan" based on the effective cycle: Set up an "Automatic Mode Back-Read Test" once a week (selecting 2 core modes) and a "Full Mode Back-Read Test" once a month. If a mode back-read error occurs during monitoring, immediately trigger the "Cycle Re-verification Process" (backtracking to step 407); Synchronize the target cycle (Tn) and validity judgment report to the "Particle Production Quality Database" to provide a reference for cycle debugging of particles of the same model and batch (e.g., subsequent particles of the same batch can be preferentially tried based on Tn as the base cycle to shorten the debugging time).

[0198] Step 4012: Target refresh cycle validity determination (scenario where all modes cannot read back correctly). The test in Step 4010 has been completed, and one of the following conditions is met: all write modes in Step 4010 have read back data with errors (after excluding external factors, it is confirmed that the errors are caused by the cycle); more than 50% of the write modes in Step 4010 have read back errors, and there are address read errors in Step 408, and the results of both modes show "incorrect".

[0199] Extract key information from the "Pattern Test Log" to analyze the reasons for ineffectiveness. Common causes and troubleshooting methods are as follows:

[0200]

[0201] If the investigation determines that the problem is due to non-periodic factors such as "particle physical damage expansion" or "abnormal hardware configuration", the problem must be fixed first (such as replacing the particles or repairing the control module) before re-executing the test in step 4010. If the problem is determined to be "the target cycle is still insufficient", proceed to the next step "cycle re-iteration".

[0202] In the "Iterative Adjustment Task File", mark "Target Refresh Cycle (Tn) Validity: Invalid", and record in detail "Invalid Judgment Time", "Invalid Reason" (e.g., "All 4 modes readbacks are incorrect, the error type is random bit flip, the judgment cycle is still insufficient") and "Error Details" (e.g., error rate of each mode, distribution of inconsistent positions); synchronize the "Invalid Judgment Result" to the "Mode Test Log" and generate an "Invalid Cycle Analysis Report", which includes "Test Process Review", "Error Data Statistics", "Cause Investigation Process" and "Follow-up Suggestions", to provide direction for re-iteration.

[0203] Parameter Reset: Update the "Current Baseline Period" to Tn (i.e., the invalid period in this iteration). If the gradient time (ΔT) was not adjusted in the previous iteration, ΔT can be increased to 1.2-1.5 times the original gradient (e.g., if the original ΔT = 10ms, adjust it to 12ms) to speed up the period adaptation efficiency, but it is necessary to ensure that "Tn + new ΔT ≤ T maximum". Process Backtracking: Start from step 407 again, generate a new period (Tn+1) based on the new "Current Baseline Period" and "Gradient Time", and repeat the process of "new period generation - configuration - reading - comparison - mode backread test" until a valid period is found that is "all correct in step 408 + all correct in mode backread in step 4010". Iteration Upper Limit Control: If a valid period is not found after more than 5 iterations, or the new period has reached T maximum (T maximum) and the mode backread is still incorrect, it is determined that "the particle cannot be repaired by period adjustment", a "particle replacement suggestion form" is generated, noting "invalid period record" and "damage characteristics", and the operation and maintenance team is notified to replace the particle and terminate the iteration process.

[0204] Collect relevant data from this "invalid cycle" (such as Tn value, error mode characteristics, and iteration count), and enter it into the "invalid cycle case library." The case library should be stored in categories of "particle type" and "error type" to facilitate quick location of the cause when encountering similar problems in the future. Based on the data in the case library, optimize the "initial gradient time" setting for particles of the same type (e.g., if a certain type of particle repeatedly causes inefficient iteration due to an insufficient initial gradient, the initial gradient can be adjusted from 10ms to 15ms) to improve subsequent debugging efficiency.

[0205] This embodiment innovatively introduces a dual verification system: "baseline / random address read" and "multi-mode write-readback." The former focuses on the stability of reading existing data, while the latter covers the entire "write-storage-readback" chain. It also designs four differentiated write modes (continuous value, alternating bits, random value, and incrementing sequence) to simulate various data storage scenarios in real-world memory applications (such as system caching, file storage, and log recording). Compared to traditional single-data verification, it can more accurately identify the adaptation defects of the cycle to different data types (e.g., some cycles only support continuous value storage and are prone to errors when storing random values), ensuring that the target cycle can still guarantee data integrity in complex application scenarios, and reducing the data storage error rate to below 0.001%.

[0206] For example, step 408 requires "100% consistency between dual addresses", step 4010 requires "MD5 verification passed + no difference in byte-by-byte comparison", and step 4012 uses "more than 50% of the patterns are incorrect" as the invalidation threshold. By using standardized and quantifiable verification standards to replace traditional subjective judgments that rely on experience (such as "the data looks normal"), the risk of misjudgment caused by differences in human operation is reduced, and the reliability of the verification results is improved to over 99.9%, providing a reliable basis for periodic parameters for subsequent aging tests and long-term operation and maintenance.

[0207] For example, step 405 needs to exclude physical damage characteristics such as "fixed bit error" and "address unreadable". Step 4012 judges the bad sector expansion of the chip through "error address concentration". Step 4010 performs "address cleanup" before writing to avoid interference from historical data. These designs can identify hidden hardware problems of memory chips in advance (such as early bad sectors and signal transmission failures), rather than simply relying on period adjustment. This avoids "ineffective debugging" caused by ignoring hardware damage. For example, if a chip causes data errors due to physical bad sectors, directly increasing the period without investigation may mask the fault and eventually cause system crash. This solution can advance the discovery time of such hardware faults by more than 50%, reducing the risk of fault propagation.

[0208] The gradient time can be dynamically adjusted based on the error rate (increasing the gradient if the error rate decreases slowly), while a maximum hardware cycle (Tmax) is set as an upper limit to avoid power waste caused by excessive cycles. After each iteration, the results are fed back through "dual-mode verification" to ensure that the cycle adjustment always approaches the "effective range". Compared with unconstrained blind incrementing (such as continuously accumulating a fixed gradient until Tmax), the adaptation efficiency of the target cycle can be improved by 30%-40%, while avoiding data loss due to insufficient cycles or increased memory power consumption due to excessive cycles (excessive cycles may increase memory power consumption by 10%-15%).

[0209] The entire debugging process is broken down into standardized steps of "cycle calculation - configuration - verification - judgment". Each step clearly defines the "operational prerequisites, core processes, and recording requirements", and provides reusable tools and templates (such as iteration record tables, mode test logs, and invalidity cause investigation tables). For example, the write mode in step 4010 has preset data characteristics and address planning, so operators do not need to manually design test data; the invalidity cause investigation table in step 4012 directly provides the "cause-investigation method" correspondence, allowing novice operators to get started quickly. Compared with debugging without a standard process (such as relying on the experience of senior employees), the training cycle for new personnel can be shortened by 60%, and the debugging time per particle can be reduced from an average of 2 hours to less than 1 hour.

[0210] Archive "iteration records, verification reports, and validity judgment results" in a standardized format and synchronize them to the "Particle Production Quality Database" and the "Invalid Cycle Case Library." The former provides cycle references for particles of the same model and batch (e.g., the target cycle for a batch of particles is concentrated in 100-120ms, and subsequent debugging can prioritize attempts within this range), reducing the number of iterations by more than 50% during batch debugging. The latter stores invalid cycle cases categorized by "particle model - error type." When encountering similar errors later (e.g., random bit flipping), historical troubleshooting methods can be directly referenced to avoid repeated trial and error. For example, if a certain model of particle is repeatedly judged as having an invalid cycle due to "random value mode readback error," the case library can record "the gradient needs to be adjusted from 10ms to 15ms." This experience can be directly reused for subsequent debugging of the same model, improving efficiency by 40%.

[0211] After the target cycle is determined to be valid, a long-term monitoring plan of "weekly automatic mode readback and monthly full mode readback" is designed, along with an anomaly alarm mechanism (such as immediately triggering process backtracking if a mode readback error occurs). Memory chips may experience a decline in charge retention capacity due to aging during long-term use, and the original valid cycle may gradually become invalid—for example, after 6 months of use, a certain chip may start showing data errors at the target cycle of 100ms. The monitoring plan can promptly detect this problem, trigger cycle re-verification, and avoid system failures caused by cycle failure. Compared to unmonitored operations and maintenance (such as only troubleshooting after a failure), the response time for cycle failure can be shortened from "hours" to "minutes," improving system availability.

[0212] For high-reliability scenarios, a "cycle redundancy verification" design is implemented (e.g., the target cycle can still be read correctly even when reduced by 5%-10%) to ensure the cycle has a certain degree of resistance to interference (e.g., ambient temperature fluctuations, small voltage changes). Simultaneously, a triple-layer solidification measure—"control module locking + security configuration area writing + physical tag marking"—prevents the loss or tampering of cycle parameters due to misoperation, firmware updates, or personnel changes. For example, in a data center, a maintenance personnel mistakenly modified the memory cycle, leading to multiple data errors. The solution's solidification measures can completely prevent such human error, reducing the incidence of maintenance incidents caused by parameter changes to zero.

[0213] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0214] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0215] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for adaptive refresh cycle of memory chips, characterized in that, The method includes: When a memory chip is found to be damaged, adjust the refresh cycle time of the memory chip. The initial refresh cycle time is set to the preset first time, so that the memory chips read data at the initial refresh cycle time. If the data read is correct, the preset first time will be used as the target refresh cycle time, including: The read data is compared bit-by-bit / byte-by-byte with the preset correct reference data, including: Depending on the data accuracy requirements of the test scenario, choose either bit-by-bit comparison or byte-by-byte comparison. When the test scenario is a sensitive test of the charge retention capability of memory chips, a bit-by-bit comparison is adopted. The read data and the baseline data are converted into binary bit streams respectively. Starting from the first bit, the values ​​at the corresponding positions are compared one by one, and the comparison result of each bit is recorded. When the test scenario is routine data verification, a byte-by-byte comparison is used, comparing each byte of the read data with the baseline data in sequence, and recording the comparison result of each byte; If the values ​​of all bits / bytes are completely consistent with the baseline data, it means that the initial refresh cycle time meets the charge retention requirements of the damaged memory chip. The preset first time is determined as the target refresh cycle, the entire debugging process ends, and the memory chip is allowed to continue to work at the target refresh cycle. If any bit or byte value does not match the baseline data, it is determined that the current refresh cycle is too short and cannot guarantee the stability of the data of the damaged particles, and the refresh cycle gradient increase adjustment stage is entered. If the data read is incorrect, a preset gradient time is added to the preset first time to obtain a preset second time. The preset second time is used as the refresh cycle time, so that the memory chip reads data with the preset gradient time added to the preset first time during the refresh cycle. If the data read is correct, the preset second time is used as the target refresh cycle time. Otherwise, the preset gradient time is continuously added to the preset second time until the data read from the memory chip is correct. The preset gradient time is set based on the degree of damage to the memory chips and their sensitivity to periodic changes, including: If the memory chips are slightly damaged, set a small gradient and find the optimal cycle time; If the memory chips are significantly damaged, set a large gradient and speed up the debugging process.

2. The adaptive refresh cycle method for memory chips according to claim 1, characterized in that, Before the step of adjusting the refresh cycle time of the memory chip when damage is detected, the method further includes: The refresh cycle register value of the memory chip can be set to the preset first time through register operations of the memory controller, hardware driver interface, or dedicated debugging tools. The preset gradient time is set according to the degree of damage to the memory chips and their sensitivity to periodic changes; Write a fixed and unique piece of test data in advance at a specified storage address of the memory chip. This serves as the baseline data for judging whether the data reading is correct, thus avoiding misjudgment due to the simplicity of the baseline data.

3. The adaptive refresh cycle method for memory chips according to claim 1, characterized in that, The steps for adjusting the refresh cycle time of memory chips when damage is detected include: After configuring the preset first time, wait for 1 or 2 complete refresh cycles to ensure that the hardware circuit completes the parameter response and avoids subsequent data reading abnormalities due to the cycle not taking effect. When a memory chip is found to be damaged, a data read command is sent to the memory chip to read data from the address where test data has been written beforehand.

4. The adaptive refresh cycle method for memory chips according to claim 1, characterized in that, After the step of using a preset first time as the initial refresh cycle time to enable the memory chips to read data at the initial refresh cycle time, the method further includes: The read data is compared with the original data to determine whether the two data are consistent; When the read data matches the original data, the read data is determined to be correct. When the read data is inconsistent with the original data, the read data is determined to be erroneous. The system automatically triggers the refresh cycle adjustment mechanism, gradually increasing the preset gradient time. After each adjustment, the data is read and verified again until the data is correct. The final target refresh cycle time will be recorded and used for subsequent aging tests and reliability analysis to ensure the stable operation of memory chips on different platforms.

5. The adaptive refresh cycle method for memory chips according to claim 1, characterized in that, The step of adding a preset gradient time to a preset second time based on a preset first time if the read data is incorrect, and using the preset second time as the refresh cycle time, causes the memory chip to read data based on the preset first time plus the preset gradient time during the refresh cycle. If the read data is correct, the preset second time is used as the target refresh cycle time; otherwise, the preset gradient time is continuously added to the preset second time until the data read from the memory chip is correct. Based on the preset first time, a new refresh cycle is calculated by superimposing a preset gradient time to obtain the preset second time; Update the refresh cycle of the memory chips to the preset second time, and wait for 1 or 2 cycles to ensure that the hardware can stably receive new parameters; Repeat the operation of "using the preset first time as the initial refresh cycle time, so that the memory chips read data at the initial refresh cycle time", and then compare the reading result with the correct data benchmark. If the data is read correctly: This indicates that the preset second time is adapted to the working requirements of the damaged particles. The preset second time is set as the target refresh cycle, and the debugging process is terminated. If the data is still read incorrectly, it means that the current period is still insufficient, so continue to add gradient time.

6. The adaptive refresh cycle method for memory chips according to claim 5, characterized in that, After the step of adding a preset gradient time to the preset second time based on the preset first time if the read data is incorrect, and using the preset second time as the refresh cycle time, the method further includes: If the reading result corresponding to the second preset time is still incorrect, enter the continuous iterative adjustment phase; Based on the current error cycle, a new refresh cycle value is generated by superimposing a preset gradient time. Each time a new cycle is generated, the process of "configuring cycle - reading data - verification and comparison" is executed. Continue the process until the read data is completely consistent with the correct baseline data. The corresponding refresh cycle time at this point is the final target refresh cycle.

7. The adaptive refresh cycle method for memory chips according to claim 6, characterized in that, After the step of adding a preset gradient time to the preset second time based on the preset first time if the read data is incorrect, and using the preset second time as the refresh cycle time, the method further includes: Introduce a write mode and read back the known mode to test the refresh cycle time, then compare the results of the two modes to see if they are consistent. If all modes can correctly read back at the target refresh time, then the target refresh time is considered valid. If all modes cannot correctly read back at the target refresh time, then the target refresh time is considered invalid.

Images