Memory test method, device, apparatus and storage medium
By running the test program of the pre-selected module in self-refresh state and reading the data of the unallocated address segment, the problem of low efficiency of DRAM self-refresh test is solved, and efficient SR test is realized.
Patent Information
- Application Number
- CN202111121715.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-09-24
- Publication Date
- 2025-12-05
- Estimated Expiration
- 2041-09-24
AI Technical Summary
In existing technologies, DRAM self-refresh testing is inefficient and the system-level SR testing pressure is insufficient, resulting in a low probability of error detection and long processing time.
By executing the enter self-refresh command and exit self-refresh command, the test program of the pre-selected module is run in the self-refresh state of the memory under test, and the unallocated address segment data is read until the test end condition is met.
It improves the efficiency of DRAM self-refresh testing, takes into account stress testing, shortens test time, and improves the accuracy of error detection.
Smart Images

Figure CN115862719B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of memory technology, and more specifically, to a memory testing method, apparatus, device, and readable storage medium. Background Technology
[0002] Dynamic Random Access Memory (DRAM) relies on the potential of its internal capacitors to record its logic values. However, due to various technical difficulties, capacitors inevitably experience significant leakage (discharge), leading to a drop in potential. Therefore, it is necessary to periodically charge the high-potential capacitors to maintain their potential stability; this is DRAM refresh. DRAM refresh operations are divided into two types: Auto Refresh (AR) and Self Refresh (SR).
[0003] In DRAM testing, the Read Retention (SR) test is crucial for assessing DRAM's data retention capabilities. System-level SR testing can be performed in two ways: one is through the system's preset standby mode, which is time-consuming per test; the other is through a dedicated program that repeatedly enters and exits the SR mode. However, the system-level SR tests in related technologies do not apply sufficient stress, leaving much of the system DRAM idle. Problems are only discovered when timing issues arise or when errors occur in the DRAM segments of the test program, causing system freezes or panics. The probability of detecting errors is relatively low, potentially requiring multiple tests and resulting in a lengthy overall testing time.
[0004] As mentioned above, improving the efficiency of testing has become an urgent problem to be solved.
[0005] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0006] The purpose of this disclosure is to provide a memory testing method, apparatus, device, and readable storage medium that improves the efficiency of SR testing to at least a certain extent.
[0007] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.
[0008] According to one aspect of this disclosure, a memory testing method is provided, comprising: executing an enter self-refresh command to cause the memory under test to enter a self-refresh state; executing an exit self-refresh command to cause the memory under test to exit the self-refresh state; running a test program corresponding to a pre-selected module to test the address segment of the memory under test allocated to the pre-selected module; reading data on the unallocated address segment in the space of the memory under test to test the unallocated address segment of the memory under test; and, if it is determined that the test termination condition is not met, returning to the step of executing the enter self-refresh command to test the memory under test.
[0009] According to one embodiment of this disclosure, the unallocated address segment includes a filled address segment and a reserved address segment; the step of reading data on the unallocated address segment of the memory under test to test the unallocated address segment of the memory under test includes: reading data on the filled address segment of the memory under test and obtaining data reading results; comparing the data reading results with preset test data, and obtaining test results of the filled address segment of the memory under test based on the comparison results.
[0010] According to one embodiment of this disclosure, the method further includes: performing an operation of writing the preset test data into the fill address segment of the memory to be tested.
[0011] According to one embodiment of this disclosure, the method further includes: obtaining the space size of the memory to be tested; and obtaining the memory space size corresponding to the filled address segment and the memory space size corresponding to the reserved address segment based on the space size of the memory to be tested.
[0012] According to one embodiment of this disclosure, the method further includes: obtaining the test result of the memory to be tested; and adjusting the memory space size corresponding to the filled address segment and the memory space size corresponding to the reserved address segment based on the space size of the memory to be tested and the test result.
[0013] According to one embodiment of this disclosure, the method further includes: determining the pre-selected module from a plurality of device modules for which an address segment of the memory to be tested has been allocated.
[0014] According to one embodiment of this disclosure, running the test program corresponding to the preselected module to test the address segment allocated to the preselected module in the memory under test includes: running the test program corresponding to the preselected module, and obtaining the test result of the address segment allocated to the preselected module in the memory under test based on the running status of the test program.
[0015] According to one embodiment of this disclosure, the method further includes: setting a hibernation recovery time; the execution of the leave self-refresh command includes: timing based on the time when the memory under test enters the self-refresh state and the hibernation recovery time, and executing the leave self-refresh command when the timing ends.
[0016] According to one embodiment of this disclosure, reading data from the unallocated address segment in the space of the memory under test includes: timing based on the time when the memory under test enters the self-refresh state and the hibernation recovery time, and reading data from the unallocated address segment in the space of the memory under test when the timing ends.
[0017] According to one embodiment of this disclosure, running the test program corresponding to the pre-selected module to test the address segment allocated to the pre-selected module in the memory under test includes: running the test program corresponding to the pre-selected module before executing the enter self-refresh command; executing the enter self-refresh command to make the memory under test enter the self-refresh state includes: executing the enter self-refresh command to make the memory under test enter the self-refresh state, and pausing the test program when the memory under test enters the self-refresh state; executing the exit self-refresh command to make the memory under test exit the self-refresh state includes: executing the exit self-refresh command to make the memory under test exit the self-refresh state, and resuming the test program when the memory under test exits the self-refresh state.
[0018] According to one embodiment of this disclosure, the step of returning to the step of executing the self-refresh command to test the memory under test when it is determined that the test end condition is not met includes: returning to the step of executing the self-refresh command when it is determined that the test end condition is not met, and obtaining the test result of the memory under test based on the self-refresh state.
[0019] According to one embodiment of this disclosure, the step of returning to the step of executing the self-refresh command when it is determined that the test end condition is not met includes: obtaining the current self-refresh count; if the current self-refresh count is less than the preset self-refresh count, determining that the test end condition is not met, and returning to the step of executing the self-refresh command.
[0020] According to another aspect of this disclosure, a memory testing apparatus is provided, comprising: an entry self-refresh command execution module for executing an entry self-refresh command to cause the memory under test to enter a self-refresh state; an exit self-refresh command execution module for executing an exit self-refresh command to cause the memory under test to exit the self-refresh state; a test program execution module for running a test program corresponding to a pre-selected module to test the address segment of the memory under test allocated to the pre-selected module; a data reading test module for reading data on the unallocated address segment in the space of the memory under test to test the unallocated address segment of the memory under test; and a test end judgment module for returning to the step of executing the entry self-refresh command to test the memory under test when it is determined that the test end condition is not met.
[0021] According to one embodiment of this disclosure, the unallocated address segment includes a filled address segment and a reserved address segment; the data read test module includes: a data read module, used to read data on the filled address segment of the memory under test and obtain data read results; and a data read test result obtaining module, used to compare the data read results with preset test data and obtain test results of the filled address segment of the memory under test based on the comparison results.
[0022] According to one embodiment of this disclosure, the apparatus further includes: a test data writing module, configured to perform the operation of writing the preset test data into the fill address segment of the memory to be tested.
[0023] According to one embodiment of this disclosure, the apparatus further includes: a memory space size acquisition module, configured to acquire the space size of the memory to be tested; and a reserved space size acquisition module, configured to acquire the memory space size corresponding to the filled address segment and the memory space size corresponding to the reserved address segment based on the space size of the memory to be tested.
[0024] According to one embodiment of this disclosure, the apparatus further includes: a test result acquisition module, configured to acquire the test result of the memory to be tested; and a reserved space size adjustment module, configured to adjust the memory space size corresponding to the filled address segment and the memory space size corresponding to the reserved address segment according to the space size of the memory to be tested and the test result.
[0025] According to one embodiment of this disclosure, the apparatus further includes a preselection module determining module, configured to determine the preselection module from a plurality of device modules for which an address segment of the memory to be tested has been allocated.
[0026] According to one embodiment of this disclosure, the test program running module is further configured to run a test program corresponding to the preselected module, and obtain the test results of the address segment allocated to the preselected module in the memory to be tested based on the running status of the test program.
[0027] According to one embodiment of this disclosure, the device further includes: a hibernation recovery time setting module, used to set a hibernation recovery time; the exit self-refresh command execution module is further used to time the time when the memory under test enters the self-refresh state and the hibernation recovery time, and execute the exit self-refresh command when the timer ends.
[0028] According to one embodiment of this disclosure, the data reading test module is further configured to time the time when the memory under test enters the self-refresh state and the hibernation recovery time, and read the data on the unallocated address segment in the space of the memory under test when the timer ends.
[0029] According to one embodiment of this disclosure, the test program running module is further configured to run a test program corresponding to a pre-selected module before executing the enter self-refresh command; the enter self-refresh command execution module is further configured to execute the enter self-refresh command to cause the memory under test to enter a self-refresh state, and the test program suspends operation when the memory under test enters the self-refresh state; the leave self-refresh command execution module is further configured to execute the leave self-refresh command to cause the memory under test to leave the self-refresh state, and the test program resumes operation when the memory under test leaves the self-refresh state.
[0030] According to one embodiment of this disclosure, the test result acquisition module is further configured to return to the step of executing the self-refresh command when it is determined that the test termination condition is not met, and obtain the test result of the memory under test according to the self-refresh state.
[0031] According to one embodiment of this disclosure, the test end determination module includes: a self-refresh count acquisition module, used to acquire the current self-refresh count; the test end determination module is further used to determine that the test end condition is not met when the current self-refresh count is less than the preset self-refresh count, and return to the step of executing the self-refresh command.
[0032] According to another aspect of this disclosure, an apparatus is provided, comprising: a memory, a processor, and executable instructions stored in the memory and executable in the processor, wherein the processor, when executing the executable instructions, implements any of the methods described above.
[0033] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores computer-executable instructions thereon, which, when executed by a processor, implement any of the methods described above.
[0034] The memory testing method provided in the embodiments of this disclosure enters the self-refresh state of the memory under test by executing an enter self-refresh command, exits the self-refresh state by executing an exit self-refresh command, and then runs the test program corresponding to the pre-selected module to test the address segment allocated to the pre-selected module in the memory under test. Then, it reads data from the unallocated address segment in the space of the memory under test to test the unallocated address segment of the memory under test. When it is determined that the test termination condition is not met, it returns to the step of executing the enter self-refresh command to perform SR test on the memory under test. Thus, stress testing can be carried out simultaneously with SR testing, thereby improving the efficiency of testing.
[0035] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this disclosure. Attached Figure Description
[0036] The above and other objects, features and advantages of this disclosure will become more apparent from a detailed description of exemplary embodiments thereof with reference to the accompanying drawings.
[0037] Figure 1 This illustration shows an exemplary Android system startup architecture in an embodiment of the present disclosure.
[0038] Figure 2 An exemplary embodiment illustrates the steps of performing a self-refresh test at the kernel layer.
[0039] Figure 3 A flowchart of a memory testing method according to an embodiment of this disclosure is shown.
[0040] Figure 4 It shows Figure 3 The steps S302 to S304 and S310 shown are schematic diagrams of the processing procedure in one embodiment.
[0041] Figure 5 It is based on Figure 4 The diagram illustrates a self-refreshing test process.
[0042] Figure 6 This is a schematic diagram illustrating the process of a system entering hibernation according to an exemplary embodiment.
[0043] Figure 7 It is based on Figure 6 The diagram shows an implementation of an early hibernation mechanism at the kernel level.
[0044] Figure 8 It is based on Figures 3 to 5 The diagram shows a schematic of a memory testing process.
[0045] Figure 9 It is based on Figures 3 to 8 The diagram illustrates a DRAM access implementation during a DRAM test.
[0046] Figure 10 A block diagram of a memory testing apparatus according to an embodiment of the present disclosure is shown.
[0047] Figure 11 A block diagram of another memory testing apparatus according to an embodiment of this disclosure is shown.
[0048] Figure 12 A schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation
[0049] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.
[0050] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced with one or more of the specific details omitted, or other methods, apparatuses, steps, etc., can be employed. In other instances, well-known structures, methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.
[0051] Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this disclosure, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. The symbol " / " generally indicates that the preceding and following objects are in an "or" relationship.
[0052] In this disclosure, unless otherwise expressly specified and limited, the term "connection" and similar terms should be interpreted broadly, for example, it can refer to an electrical connection or the ability to communicate with each other; it can refer to a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this disclosure according to the specific circumstances.
[0053] Figure 1 An exemplary Android system boot architecture is illustrated, to which the memory testing methods or devices disclosed herein can be applied. Android system boot is a bottom-up process: Loader layer 102 → Kernel layer 104 → Native services layer 106 → Application framework (including C++ Framework 108 and Java Framework 110) layer → Apps layer 112. During Android system boot, at Loader layer 102, the chip is guided to execute preset code stored in Read-Only Memory (ROM) (Boot ROM stage), and then the bootloader is loaded into Random Access Memory (RAM); next, the bootloader in RAM is started (Boot Loader stage), implementing functions such as RAM checks and parameter initialization. In other layers, several processes are started sequentially from bottom to top to load various modules during system boot.
[0054] SR testing in related technologies can proceed in three stages: 1) Boot Loader stage, 2) Kernel layer startup stage, and 3) Application layer startup stage (also known as the system stage or Android stage). Entering SR testing in a higher-level startup stage requires calling lower-level processes. In the Boot Loader stage, the bootloader can run on Static Random Access Memory (SRAM). After Dynamic Random Access Memory (DRAM) initialization is complete, DRAM can be read and written, allowing for full-size DRAM testing. SR testing of DRAM in this stage can be performed by directly writing to the Mode Register (MR) command. This method can be used for system-level testing (SLT) and packaged chip-level functional testing (FT). This method, which uses the Central Processing Unit (CPU) to directly write MR commands to put DRAM into SR, and uses the CPU to directly send read and write commands to read and write DRAM, has the following disadvantages: the CPU directly operates on DRAM without any intermediate process; it only operates on DRAM and does not involve other modules of the system; it can only test the timing and functional errors of DRAM itself.
[0055] During the Kernel startup phase, all devices run on DRAM and are managed by the Kernel layer. At this phase, DRAM enters SR (Streaming Service), and DRAM becomes inaccessible, so all devices must stop running. Figure 2 A schematic diagram illustrating the steps of performing SR testing on the Kernel layer is shown according to an exemplary embodiment. Figure 2 As shown, taking the Linux kernel as an example, there are three ways to enter hibernation (suspend): Freeze, Standby, and Suspend to RAM (STR). These hibernation methods can be triggered by writing "freeze", "standby", and "mem" to the " / sys / power / state" file in user space (2006). In the kernel layer (2004), hibernation is entered using the following three steps.
[0056] (1) Freeze user-mode processes and kernel-mode tasks, and stop the currently running tasks in the Kernel layer (S204).
[0057] (2) Call the hibernation callback function of the registered device, and put each device into suspend state in turn (S206) to stop the operation of each device.
[0058] (3) Hibernate core devices and put the CPU into hibernation state (S208, S210, S212, S214).
[0059] Freezing processes involves the kernel setting the state of all processes in the process list to stopped and saving the context of all processes. This is to ensure that the data can be restored to the state before entering the SR state when exiting the SR (S232). After the Kernel layer 2004 completes the hibernation process, it enters the loader layer 2002, and the platform enters hibernation (S216). Hibernation begins, and SR proceeds automatically until the hibernation recovery time, at which point the platform exits hibernation (S218), and then enters the Kernel layer recovery process. The Kernel layer recovery process S220 to S230 corresponds one-to-one with steps S214, S212...S204, until the state before entering hibernation is restored in user space 2006 (S232).
[0060] In kernel layer 2004 and loader layer 2002, the hibernation and recovery process involves multiple modules such as the power management (PM) core, device (PM), drivers for each device, platform-dependent (PM), and CPU control interrupt request (IRQ), and involves multiple processes such as console switch, process freeze, CPU hotplug, and wakeup.
[0061] There are two ways to enter SR (Signal Retention) testing during the system phase: 1) repeatedly entering and exiting SR through a separate program; 2) standby testing. The first method, repeatedly entering and exiting SR through a separate program, tests the data retention capability of DRAM. When the system enters SR, if the DRAM data is not retained, some data changes will occur. Exiting SR and rereading / writing to DRAM will cause the program to crash if the erroneous data is in a code or data segment, preventing further entry into SR. For example, if the system is set to enter and exit SR 100 times, and the system crashes, the test log might only show a few dozen entries, indicating a potential problem with SR and allowing for further troubleshooting (debugging) to identify the specific cause. The second method utilizes Android's own power-saving algorithms, such as blacking out the screen after 15 seconds of inactivity and entering sleep mode after 30 minutes of inactivity. In these cases, DRAM enters SR mode, but this algorithm is time-consuming.
[0062] Entering SR during the system phase also involves a Kernel layer dormancy process (see...). Figure 6 The following disadvantages exist in performing SR testing in these two stages in related technologies: 1) The system pressure is insufficient. At this time, there is a lot of idle DRAM in the system. Problems can only be discovered when timing issues or errors in the DRAM segment content of the running program cause the system to freeze or panic. The probability of detecting errors is relatively small, and multiple tests may be required, which takes a long time overall.
[0063] Therefore, this disclosure provides a system-level SR testing method. It involves executing an "enter self-refresh" command to put the memory under test into a self-refresh state, executing an "exit self-refresh" command to leave the self-refresh state, then running the test program corresponding to a pre-selected module to test the address segments allocated to the pre-selected module in the memory under test. Next, it reads data from unallocated address segments in the memory under test to test these unallocated address segments. If the test termination condition is not met, it returns to the step of executing the "enter self-refresh" command to perform SR testing on the memory under test. This allows for simultaneous SR testing and stress testing, improving testing efficiency.
[0064] Figure 3 This is a flowchart illustrating a memory testing method according to an exemplary embodiment. Figure 3 The method shown can be applied, for example, to test the DRAM running the Android system.
[0065] refer to Figure 3 The method 30 provided in this embodiment may include the following steps.
[0066] In step S302, a self-refresh command is executed to put the memory under test into a self-refresh state.
[0067] In step S304, a leave self-refresh command is executed to cause the memory under test to leave the self-refresh state.
[0068] In some embodiments, SR can be entered and exited during the system phase by executing corresponding commands. Specific implementation details can be found in [reference needed]. Figure 4 and Figure 5 .
[0069] In some embodiments, entering SR during the system phase can be achieved by executing a command to put the system into hibernation. Implementation methods for entering hibernation during the system phase can be found in [reference needed]. Figure 6 and Figure 7 .
[0070] In step S306, the test program corresponding to the preselected module is run to test the address segment allocated to the preselected module in the memory to be tested.
[0071] In some embodiments, the entire DRAM is divided into many segments, and some address segments are assigned to specific modules at power-on. When performing suspend (repeatedly entering and exiting the SR) or idle standby tests, many modules of the system are not running, such as the USB (Universal Serial Bus) module, GPU (Graphics Processing Unit) module, etc. Therefore, before entering and exiting the SR, a pre-selected module can be determined from multiple device modules whose address segments of the memory to be tested have been assigned. After each exit from the SR, the test program for the pre-selected module is run. For specific implementation details, please refer to [reference needed]. Figure 8 The testing process and Figure 9 A schematic diagram of DRAM access implementation.
[0072] In step S308, data on the unallocated address segment in the space of the memory to be tested is read to test the unallocated address segment of the memory to be tested.
[0073] In some embodiments, the unallocated address segment may include a padding address segment and a reserved address segment. Data on the padding address segment of the memory under test is read, the data read result is obtained, and then the data read result is compared with preset test data. The test result of the padding address segment of the memory under test is obtained based on the comparison result.
[0074] In some embodiments, before step S302, the operation of writing preset test data into the fill address segment of the memory under test can be performed. This can be done by first obtaining the space size of the memory under test, then obtaining the memory space size corresponding to the fill address segment and the memory space size corresponding to the reserved address segment based on the space size of the memory under test, and then writing the preset test data into the fill address segment.
[0075] In step S310, if it is determined that the test termination condition is not met, the process returns to the step of executing the self-refresh command to test the memory to be tested.
[0076] In some embodiments, for example, the test termination condition may be reaching a preset number of self-refreshes. Another example is reaching a preset test duration.
[0077] In some embodiments, test results for the memory under test can be obtained at the end of the test. These results may include data retention capability obtained through input / output of the SR (Search Server), gold data alignment results, and module operation test results. Then, the memory space size corresponding to the filled address segment and the memory space size corresponding to the reserved address segment are adjusted based on the memory space size under test and the test results.
[0078] According to the memory testing method provided in this disclosure, the memory under test is put into a self-refresh state by executing an enter self-refresh command, and then put out of the self-refresh state by executing an exit self-refresh command. Then, the test program corresponding to the pre-selected module is run to test the address segment allocated to the pre-selected module in the memory under test. Then, data on the unallocated address segment in the space of the memory under test is read to test the unallocated address segment of the memory under test. When it is determined that the test termination condition is not met, the step of executing the enter self-refresh command is returned to perform SR test on the memory under test. Thus, stress test can be carried out at the same time as SR test, thereby improving the efficiency of test.
[0079] Figure 4 It shows Figure 3 The steps S302 to S304 and S310 shown are schematic diagrams of the processing procedure in one embodiment. (See diagram for reference.) Figure 4 As shown in the embodiments of this disclosure, the SR testing process may further include the following steps.
[0080] Step S402: Set the hibernation recovery time.
[0081] Step S404: Execute the self-refresh command to put the memory under test into a self-refresh state.
[0082] Step S406: The timer is set based on the time it takes for the memory under test to enter the self-refresh state and the hibernation recovery time. When the timer expires, the exit self-refresh command is executed to make the memory under test leave the self-refresh state.
[0083] Step S408: Obtain the current self-refresh count.
[0084] Step S410: If the current number of self-refreshes is less than the preset number of self-refreshes, it is determined that the test termination condition is not met, and the process returns to the step of executing the self-refresh command.
[0085] Figure 5 It is based on Figure 4 This diagram illustrates an SR (Real-Time Memory) testing process. DRAM can be tested using devices running the Android operating system, such as mobile phones or other terminal devices. Figure 5 As shown, after the test starts (S502), the device enters a screen-on countdown (S504), and enters SR (S506) when the countdown ends. The test program counts down the SR state according to the set sleep recovery time (S508), and exits SR when the countdown ends (S510). After exiting SR, the number of times SR has been entered and exited is obtained, and the remaining number of times is calculated compared with the preset self-refresh number (S512). If the remaining number of times is 0, the test ends (S514). If the remaining number of times is not 0, the SR test data is saved (S516), and then the process returns to step S504 to prepare for the next entry and exit of SR.
[0086] Figure 6 This is a schematic diagram illustrating the process of a system entering hibernation according to an exemplary embodiment. Figure 6 The sleep-wake process is illustrated using the early suspend mechanism in the Android system as an example. Figure 6As shown, in the application layer, the application (App) (e.g., App A) can create, request, and release a wake lock (S602). In the framework layer, the power manager requests to enter sleep mode (S604), checks the reason for screen shutdown, determines whether to directly enter sleep mode (S606), checks the system status, sends a broadcast (S608), and updates the system status (S610). In the Java Native Interface (JNI) layer, when the PowerManagerService checks that the system no longer has a wake lock, it receives a notification and initiates sleep processing (S612). Then, in the Hardware Abstraction Layer (HAL), the access from user space to kernel space hardware devices is abstracted. It determines whether to perform an early suspend, passes the wake lock information to kernel space, and performs a system call (S614). The hibernation (S616) and wake-up process in the kernel layer can be found in [reference needed]. Figure 2 For steps S204 to S230, the module implementing this process in the kernel layer can be found here. Figure 7 .
[0087] Figure 7 It is based on Figure 6 This diagram illustrates the kernel-level implementation of an early hibernation mechanism. Figure 7 As shown, the HAL system calls the kernel-level Early Suspend Manager module 702 and Wake_Lock Manager module 704. The Early Suspend Manager module 702 includes an Early Suspend module 7022 and a Late Resume module 7024, managing the screen and backlight driver 7062, touchscreen driver 7064, and camera driver 706, controlling these drivers to hibernate and resume. The Wake_Lock Manager module 704, through the Linux hibernation manager module 7042, manages the CPU driver 7082, Wi-Fi (wireless communication technology) driver 7084, and Bluetooth (BT) driver 7086, controlling these drivers to hibernate and resume.
[0088] Figure 8 It is based on Figures 3 to 5 A schematic diagram of a memory testing process is shown. Figure 8As shown, the Android system starts (S802), obtains device system permissions, and first sets the hibernation / resume time (S804). For example, the time to enter SR (hibernation time) and the time to exit SR (resume time) can be set separately, or the time to enter SR and the duration of SR state can be set. Then, the module to be run is selected (S806), and the selected module is the pre-selected module for this test. Then, the space size of the memory to be tested is obtained, and the memory space size corresponding to the filled address segment and the memory space size corresponding to the reserved address segment (also known as free space) are obtained according to the space size of the memory to be tested (S808). Then, the preset test data is written to the filled address segment of the memory to be tested (i.e., the... Figure 8 The process begins with the operation of the gold data in step S806 (S810). Then, the test program corresponding to the pre-selected module selected in step S806 is run (S812). Next, a self-refresh command is executed according to a preset time (S814) to put the memory under test into a self-refresh state. The test program pauses when the memory under test enters the self-refresh state. Timing is performed based on the time the memory under test enters the self-refresh state and the sleep recovery time. At the end of the timing, a self-refresh exit command is executed (S816) to exit the self-refresh state. The test program resumes operation when the memory under test exits the self-refresh state (S818), and the test results of the address segment allocated to the pre-selected module in the memory under test are obtained based on the test program's execution. Timing can be based on the time the memory under test enters the self-refresh state and the sleep recovery time. For example, the sleep and wake-up times of a timer can be set at the upper layer and then passed down to the lower layer for execution by the timer. At the end of the timing, data is read from the filled address segment of the memory under test to obtain the data read result. The data read result is compared with the preset test data (S820), and the test result of the filled address segment of the memory under test is obtained based on the comparison result. The test result of the address segment allocated to the pre-selected module, the test result of the filled address segment, and the SR test result obtained according to the self-refresh state are obtained as the test result of this test in the loop test (S822). If the loop has not ended (e.g., the current self-refresh count is less than the preset self-refresh count), the test returns to step S814 of entering the self-refresh command. If the loop ends (e.g., the current self-refresh count is not less than the preset self-refresh count), the test ends (S824).
[0089] Figure 9 It is based on Figures 3 to 8 This diagram illustrates a DRAM access implementation during a DRAM test. Figure 9As shown, taking Low Power Double Data Rate (LPDDR) Synchronous Dynamic Random-Access Memory (LPDDR4) as an example, the entire DRAM address range is divided into many intervals, including system segment 902, USB segment 904, Wi-Fi / BT segment 906, OSD (On Screen Display) segment 908, GPU segment 910, and free segment 912. Their sizes are as follows: system segment 902 is 0M(B) to 128M(B), USB segment 904 is 128M(B) to 256M(B), etc. Some of these are allocated to specific modules when the system is booted up, and the remaining free segments can be temporarily requested by the CPU after the system starts up. The commands sent to the DRAM by these external modules of the device, such as the CPU, USB, Wi-Fi / BT, etc., are first sent to the management module EMI (External Memory Interface) for processing via the corresponding bus (e.g., the CPU uses the Advanced High-performance Bus (AHB) or the Advanced eXtensible Interface (AXI), while other modules use the Advanced Peripheral Bus). The EMI includes multiple ports corresponding to the external modules and can manage the priority and access order of commands sent from the external modules. Then, the EMI sends the commands to the controller for execution. The controller accesses the address segment corresponding to the DRAM through the physical layer (PHY) and performs the specific DRAM access actions.
[0090] Reference Figure 8 During the test, in step S806, for example, it can be obtained from... Figure 9 Select one of the USB module and GPU module to run in step S810. Figure 9The size of the free segment 912 is prepared to fill with data based on the DRAM size and the size of the free segment 912 portion (e.g., 1.5GB to 4GB). The DRAM space required for running the pre-selected module (i.e., the memory space corresponding to the reserved address segment) needs to be estimated. The reserved size cannot be too large or too small; too small a reservation will result in insufficient system operating space, while too large a reservation will degrade test performance. Filling the fill address segment with fixed data can largely fill the free segment 912. Each time suspend is exited, for the allocated space, in step S818, these modules are run in turn to check if the system hangs or runs normally, thus determining if the DRAM data is corrupted. For example, if the pre-selected module for this test is USB, then the next pre-selected module will be GPU, and the DRAM space allocated to that module can be tested. In step S820, the data in the free segment is read and compared with the golden data to check for errors. The top layer needs to be well-designed with the bottom layer interface, and the module operation test and the bottom layer golden data detection are performed simultaneously. For example, a method can be used... Figure 8 The timing method involves pausing the underlying modules when the system enters SR and restarting them when the system exits SR. The underlying modules can be set with timers to perform data comparison when the timer expires.
[0091] According to the memory testing method provided in this disclosure, a certain amount of data is filled into the unallocated address segment of the memory to be tested. The data of the segment is read each time the memory is entered or exited, and the module with allocated memory is run. This increases the pressure of the SR test, makes the test closer to the user's usage scenario, and improves the test efficiency.
[0092] Figure 10 This is a block diagram illustrating a memory testing apparatus according to an exemplary embodiment. Figure 10 The device shown can, for example, be used to test DRAM running the Android system.
[0093] refer to Figure 10 The apparatus 100 provided in this embodiment may include an entry self-refresh command execution module 1002, an exit self-refresh command execution module 1004, a test program running module 1006, a data reading test module 1008, and a test end judgment module 1010.
[0094] The self-refresh command execution module 1002 can be used to execute the self-refresh command to put the memory under test into a self-refresh state.
[0095] The exit self-refresh command execution module 1004 can be used to execute the exit self-refresh command to cause the memory under test to exit the self-refresh state.
[0096] The test program execution module 1006 can be used to run the test program corresponding to the preselected module to test the address segment allocated to the preselected module in the memory to be tested.
[0097] The data reading test module 1008 can be used to read data from the unallocated address segment in the space of the memory under test, so as to test the unallocated address segment of the memory under test.
[0098] The test end judgment module 1010 can be used to return to the step of executing the self-refresh command when the test end condition is not met, so as to test the memory to be tested.
[0099] Figure 11 This is a block diagram illustrating another memory testing apparatus according to an exemplary embodiment. Figure 11 The device shown can, for example, be used to test DRAM running the Android system.
[0100] refer to Figure 11 The apparatus 110 provided in this embodiment may include a hibernation recovery time setting module 1101, an entry self-refresh command execution module 1102, an exit self-refresh command execution module 1104, a pre-selection module determination module 1105, a test program running module 1106, a memory space size acquisition module 11072, a reserved space size acquisition module 11074, a test data writing module 11076, a data reading test module 1108, a test end judgment module 1110, a test result acquisition module 1112, and a reserved space size adjustment module 1114. The data reading test module 1108 may include a data reading module 11082 and a data reading test result acquisition module 11084, and the test end judgment module 1110 may include a self-refresh count acquisition module 11102.
[0101] The hibernation recovery time setting module 1101 can be used to set the hibernation recovery time.
[0102] The self-refresh command execution module 1102 can be used to execute the self-refresh command to put the memory under test into a self-refresh state.
[0103] The self-refresh command execution module 1102 can also be used to execute the self-refresh command to put the memory under test into a self-refresh state, and the test program will pause when the memory under test enters the self-refresh state.
[0104] The exit self-refresh command execution module 1104 can be used to execute the exit self-refresh command to cause the memory under test to exit the self-refresh state.
[0105] The exit self-refresh command execution module 1104 can also be used to time the time when the memory under test enters the self-refresh state and the hibernation recovery time, and execute the exit self-refresh command when the time ends.
[0106] The self-refresh command execution module 1104 can also be used to execute a self-refresh command to cause the memory under test to leave the self-refresh state, and the test program resumes operation when the memory under test leaves the self-refresh state.
[0107] The preselection module determination module 1105 can be used to determine a preselection module from multiple device modules of an address segment of the memory to be tested that has been allocated.
[0108] The test program execution module 1106 can be used to run the test program corresponding to the preselected module to test the address segment allocated to the preselected module in the memory to be tested.
[0109] The test program execution module 1106 can also be used to run the test program corresponding to the pre-selected module before executing the self-refresh command.
[0110] The test program execution module 1106 can also be used to run the test program corresponding to the preselected module, and obtain the test results of the address segment allocated to the preselected module in the memory under test based on the running status of the test program.
[0111] The memory space size acquisition module 11072 can be used to acquire the space size of the memory to be tested.
[0112] The reserved space size acquisition module 11074 can be used to obtain the memory space size corresponding to the filled address segment and the memory space size corresponding to the reserved address segment based on the space size of the memory to be tested.
[0113] The test data writing module 11076 can be used to perform the operation of writing preset test data into the fill address segment of the memory under test.
[0114] The data read test module 1108 can be used to read data from the unallocated address segments of the memory under test for testing the unallocated address segments. The unallocated address segments include padding address segments and reserved address segments.
[0115] The data reading test module 1108 can also be used to time the time when the memory under test enters the self-refresh state and the hibernation recovery time, and read the data on the unallocated address segment in the space of the memory under test when the time ends.
[0116] The data reading module 11082 can be used to read data on the filled address segment of the memory under test and obtain the data reading results.
[0117] The data read test result acquisition module 11084 can be used to compare the data read result with preset test data, and obtain the test result of the filled address segment of the memory under test based on the comparison result.
[0118] The test end judgment module 1110 can be used to return to the step of executing the self-refresh command when the test end condition is not met, so as to test the memory to be tested.
[0119] The self-refresh count acquisition module 11102 can be used to obtain the current self-refresh count.
[0120] The test end judgment module 1110 can also be used to determine that the test end condition is not met when the current self-refresh count is less than the preset self-refresh count, and return to the step of executing the self-refresh command.
[0121] The test result acquisition module 1112 can be used to obtain the test results of the memory under test.
[0122] The test result acquisition module 1112 can also be used to return to the step of executing the self-refresh command when it is determined that the test termination condition is not met, and obtain the test result of the memory under test according to the self-refresh state.
[0123] The reserved space size adjustment module 1114 can be used to adjust the memory space size corresponding to the filled address segment and the memory space size corresponding to the reserved address segment according to the space size of the memory to be tested and the test results.
[0124] The specific implementation of each module in the device provided in this embodiment can be referred to the content of the above method, and will not be repeated here.
[0125] Figure 12 A schematic diagram of the structure of an electronic device according to an embodiment of this disclosure is shown. It should be noted that... Figure 12 The devices shown are merely examples of computer systems and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.
[0126] like Figure 12 As shown, device 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1202 or a program loaded from storage section 1208 into random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for the operation of device 1200. CPU 1201, ROM 1202, and RAM 1203 are interconnected via bus 1204. Input / output (I / O) interface 1205 is also connected to bus 1204.
[0127] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.
[0128] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs the functions defined above in the system of this disclosure.
[0129] It should be noted that the computer-readable medium disclosed herein may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0130] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0131] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor can be described as including an entry self-refresh command execution module, an exit self-refresh command execution module, a test program execution module, a data reading test module, and a test end determination module. The names of these modules do not necessarily limit the module itself; for example, a data acquisition module can also be described as a "module that executes the entry self-refresh command".
[0132] In another aspect, this disclosure also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include:
[0133] Execute the enter self-refresh command to put the memory under test into the self-refresh state; execute the exit self-refresh command to exit the self-refresh state; run the test program corresponding to the pre-selected module to test the address segment allocated to the pre-selected module in the memory under test; read data from the unallocated address segment in the memory under test to test the unallocated address segment; if the test termination condition is not met, return to the step of executing the enter self-refresh command to test the memory under test.
[0134] Exemplary embodiments of this disclosure have been specifically shown and described above. It should be understood that this disclosure is not limited to the detailed structures, arrangements, or implementations described herein; rather, this disclosure is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.
Claims
1. A memory test method characterized by, The method comprises the following steps: executing an entering self-refresh command to make the to-be-tested memory enter a self-refresh state; executing a leaving self-refresh command to make the to-be-tested memory leave the self-refresh state; running a test program corresponding to a preselected module to test an address segment of the to-be-tested memory allocated to the preselected module; reading data on an unallocated address segment in the to-be-tested memory to test the unallocated address segment of the to-be-tested memory; returning to the step of executing the entering self-refresh command to test the to-be-tested memory when it is determined that the test end condition is not met.
2. The method of claim 1, wherein, The unallocated address segment comprises a padding address segment and a reserved address segment; The reading data on the unallocated address segment of the to-be-tested memory to test the unallocated address segment of the to-be-tested memory comprises: reading data on the padding address segment of the to-be-tested memory to obtain a data reading result; comparing the data reading result with preset test data to obtain a test result of the padding address segment of the to-be-tested memory according to a comparison result.
3. The method of claim 2, wherein, The method further comprises the following steps: executing an operation of writing the preset test data on the padding address segment of the to-be-tested memory.
4. The method of claim 2, wherein, The method further comprises the following steps: obtaining a space size of the to-be-tested memory; obtaining a memory space size corresponding to the padding address segment and a memory space size corresponding to the reserved address segment according to the space size of the to-be-tested memory.
5. The method of claim 4, wherein, The method further comprises the following steps: obtaining a test result of the to-be-tested memory; adjusting the memory space size corresponding to the padding address segment and the memory space size corresponding to the reserved address segment according to the space size of the to-be-tested memory and the test result.
6. The method of claim 1, wherein, The method further comprises the following steps: determining the preselected module from a plurality of device modules whose address segments of the to-be-tested memory have been allocated.
7. The method of claim 1, wherein, The running the test program corresponding to the preselected module to test the address segment of the to-be-tested memory allocated to the preselected module comprises: running the test program corresponding to the preselected module to obtain a test result of the address segment of the to-be-tested memory allocated to the preselected module according to a running condition of the test program.
8. The method of claim 1, wherein, The method further comprises the following steps: setting a hibernation recovery time; The executing the leaving self-refresh command comprises: counting according to a time when the to-be-tested memory enters the self-refresh state and the hibernation recovery time, and executing the leaving self-refresh command when the counting ends.
9. The method of claim 8, wherein, The reading data on the unallocated address segment in the to-be-tested memory comprises: counting according to a time when the to-be-tested memory enters the self-refresh state and the hibernation recovery time, and reading data on the unallocated address segment in the to-be-tested memory when the counting ends.
10. The method of claim 1, wherein, The running the test program corresponding to the preselected module to test the address segment of the to-be-tested memory allocated to the preselected module comprises: running the test program corresponding to the preselected module before the executing the entering self-refresh command; The executing the entering self-refresh command to make the to-be-tested memory enter the self-refresh state comprises: executing the entering self-refresh command to make the to-be-tested memory enter a self-refresh state, the test program being paused when the to-be-tested memory enters the self-refresh state; the executing the exiting self-refresh command to make the to-be-tested memory exit the self-refresh state comprises: executing the exiting self-refresh command to make the to-be-tested memory exit the self-refresh state, the test program being resumed when the to-be-tested memory exits the self-refresh state.
11. The method of claim 1, wherein, the returning to the step of executing the entering self-refresh command to test the to-be-tested memory when it is determined that the test end condition is not met comprises: the returning to the step of executing the entering self-refresh command to test the to-be-tested memory when it is determined that the test end condition is not met comprises:
12. The method of claim 1, wherein, the returning to the step of executing the entering self-refresh command when it is determined that the test end condition is not met comprises: obtaining a current self-refresh number; determining that the test end condition is not met when the current self-refresh number is less than a preset self-refresh number, and returning to the step of executing the entering self-refresh command.
13. A memory testing apparatus, characterized by comprising: comprise: an entering self-refresh command executing module configured to execute an entering self-refresh command to make a to-be-tested memory enter a self-refresh state; an exiting self-refresh command executing module configured to execute an exiting self-refresh command to make the to-be-tested memory exit the self-refresh state; a test program running module configured to run a test program corresponding to a preselected module to test an address segment allocated to the preselected module in the to-be-tested memory; a data reading test module configured to read data on an unallocated address segment in the to-be-tested memory to test the unallocated address segment in the to-be-tested memory; a test end determining module configured to return to the step of executing the entering self-refresh command to test the to-be-tested memory when it is determined that a test end condition is not met.
14. An apparatus comprising: A memory, a processor, and executable instructions stored in the memory and executable in the processor, wherein the processor executes the executable instructions to implement the method in any one of claims 1-12.
15. A computer-readable storage medium having stored thereon computer- executable instructions, wherein, The executable instructions are executed by the processor to implement the method in any one of claims 1-12.
Citation Information
Patent Citations
Memory device specific self-refresh entry and exit
CN107533509A
Linux-based automatic operation performance test method and device, and medium
CN109901982A